How we keep Hydra safe, and where we are

In place today

Hydra recommends. A person decides.

• Advice-only operation. Hydra does not isolate hosts, disable accounts, block addresses or change anything in your systems. A person approves any action it recommends and carries it out in your own tools.
• A global kill switch stops all actions at once.
• An optional triage feature can close routine alerts. It is off by default for evaluations and runs in a record-only mode first. It never closes an alert rated critical, has an hourly limit, and its decisions can be reversed.

How the AI is kept in check

• Every verdict must cite the evidence it relies on. Hydra's own detection rules check the model's answer, and Hydra answers "needs context" when it cannot decide.
• Alert content is treated as untrusted data. The AI is told not to follow any instruction found inside an alert, which protects against prompt injection.
• We do not train AI models on customer data, and we do not allow our model providers to.
• The AI service has its own read-only identity. It cannot approve or carry out anything.
• Analysts mark each verdict Agree or Disagree. During an evaluation we report agreement, and any attack Hydra dismissed, to you every week.

Who can do what

• Sign-in is handled by an identity provider, with multi-factor authentication available and enforceable for a whole workspace.
• Five roles (viewer, analyst, manager, admin, owner) separate reading, investigating, approving actions and changing configuration.

Protecting data

• Traffic to Hydra uses HTTPS only. Our database and storage encrypt data at rest.
• Credentials you store in Hydra to connect your tools are additionally encrypted by Hydra with AES-256-GCM.
• Keys and passwords are kept out of our source code and delivered to the services when they run.
• Hydra reads alert details. It does not read file contents, email contents, passwords or payment card data.
• When an agreement ends, we delete your data within 30 days, and from our backups within 90 days, and confirm in writing if you ask.

Infrastructure and software

• Services run in containers as non-root users, and a default-deny network policy blocks traffic between services unless it is explicitly allowed.
• Calls from Hydra to an address you configure are checked so they cannot be pointed at private networks or the cloud metadata service.
• Every change is made by pull request and tested before release. The code has more than 300 automated tests, including tests of customer separation and of the safeguards that stop Hydra acting on its own.
• Releases use fixed images and roll back automatically if the new version does not start. A database backup is taken before each release, and daily backups are kept for 14 days.

An audit trail

• Every action Hydra takes, every decision a person makes and every configuration change is recorded. Each entry includes the hash of the one before it, so a changed or deleted entry can be detected. You can see your workspace's audit trail.

In progress

• Separation between customers. Every record belongs to a workspace and every query is scoped to it. We apply database row-level security and are confirming it is enforced under the application's database account. We will report the result.
• A formal access review for our own staff's access to production.
• An incident response procedure, covering how we detect, contain and investigate an incident and how we notify customers and regulators.
• Alerts and monitoring for crashes, failed sign-ins and unusual traffic, with a rota for who responds.
• Recovery drills. We will test a restore from backup into a clean database at least twice a year. The first drill is scheduled.
• Mandatory second review of every code change, and automated checks on every pull request.
• Dependency updates. We audit dependencies on each release and are completing an update of our main framework and database packages.
• Our licence. We are preparing our application to Ghana's Cyber Security Authority for the licence to provide managed cybersecurity services, because we plan to run Hydra for customers ourselves. Company registration is in progress, and the application follows it.

Planned, not yet started

• An independent penetration test, during the first evaluations.
• ISO 27001 and SOC 2. We are scoping both. We have not started, and we do not hold either.
• A web application firewall and shared rate limiting at the network edge. Rate limiting is applied in the application today.
• High availability, point-in-time recovery and agreed recovery targets, before we offer a service level. During an evaluation we do not promise one.

Where your data goes

We do not use Google Vertex AI. When model processing is enabled, the model runs inside Radiant's Google Cloud environment. We will tell you 14 days before we add another provider that handles your data.

Licensing, stated plainly

We plan to run Hydra for customers ourselves, under a licence from Ghana's Cyber Security Authority for managed cybersecurity services. As we read the Bank of Ghana's 2026 directive, the security monitoring system an institution subscribes to must be run by a company accredited by the Authority and owned mostly by Ghanaians. That is why we will be the operator and not only the software maker. This is our reading, and a Ghanaian lawyer has not checked it yet.

Where we are: company registration is in progress, and the licence application follows it. We do not hold the licence. We will not provide Hydra to a customer until we are licensed or the Authority has confirmed in writing that the activity does not need a licence. Today we do not run anyone's security operations centre.

Report a problem

To report a vulnerability or ask a security question, write to security@radiantinnovatech.com. We reply within two business days and will not take action against anyone who reports in good faith.

Last reviewed: 21 October 2026 by Samuel Maclar.