Ciroos vs Cleric

At a glance

	Ciroos	Cleric
Core idea	Federated investigation across the tools you already run	Read-only investigation with an auditable trail and accumulated memory
Telemetry handling	Not centralised. Works against existing tools in place	Vendor-hosted, with data never used for training
Default authority in production	Starts read-only, then specific write patterns as trust builds	Read-only by default
Learning across incidents	A knowledge graph as persistent memory, learning from each incident and from engineer feedback	Operational memory, so a resolved incident informs the next
Auditability	Named as a platform requirement, with repeatable resolutions	Every investigation auditable, and the product leads on this
Compliance posture	Federation itself is the data-residency answer	SOC 2 Type II
Named customers	Cisco, Lucid, DigiCert, DirecTV	Case studies rather than a named logo list
Published accuracy	Not published against a public benchmark	Not published against a public benchmark
Structural blind spot	Limited to what the federated tools expose	Limited to the signals it can read

How the two differ in practice

Both of these are answers to the same underlying anxiety, which is that adopting an AI investigation product means either handing over your telemetry or handing over control of production. They pick different halves of that to solve.

Ciroos solves the data half. Federation means the product works across the observability, logging and incident tools you already run rather than requiring telemetry to be copied into a central store first. That removes a data engineering project that, in most organisations, is measured in quarters and is the reason several of these evaluations never reach a trial at all. It also means Ciroos does not become another place your production data lives, which shortens a security review considerably.

Cleric solves the control half. Read-only by default means the agent cannot write to production, and that is a property of the product rather than a permissions matrix somebody has to keep correct. Every investigation being auditable extends the same posture into the review afterwards, and SOC 2 Type II with a statement that customer data is never used for training covers the residual data question.

The memory model is Cleric's second distinguishing feature and the one a short trial will undersell. Operational memory means a resolved incident informs later investigations rather than each one starting cold, which compounds with volume. A team having incidents weekly gets substantially more from it than a team having them quarterly.

On evidence of adoption, Ciroos is ahead in what it will say publicly. Naming Cisco, Lucid, DigiCert and DirecTV is a stronger signal than most vendors in this category will give, and for a buyer who needs to point at comparable organisations during an internal approval, that matters more than a feature.

Where each one is stronger

Ciroos is stronger where the estate is heterogeneous and the telemetry cannot practically be moved. Regulated environments, organisations that have already lost a year to a centralisation project, and companies whose observability spend is spread across three vendors all get a shorter path to a working trial. The named customer list is unusually concrete for this stage of the market and is worth using.

Cleric is stronger where the obstacle is organisational rather than technical. In a company with a change advisory process for humans, the question that stalls an AI rollout is authority, not accuracy, and read-only by default retires that question before it is raised. The auditable trail supports the same case with whoever has to sign off afterwards, and the memory model is the advantage that grows rather than the one that demos well.

Both share the limit that runs through this whole category. Each can only reason about what it can read: for Ciroos that means whatever the federated tools expose, and for Cleric whatever signals it is given. Neither publishes accuracy against a public benchmark, so their claims cannot be ranked against each other on published evidence, and any page that ranks them is doing so on something other than measurement.

How to choose

Work out which objection you will actually have to answer internally, because these two are built for different ones. If your security team's first question is where the telemetry goes, Ciroos answers it structurally. If the first question is what the agent can do to production, Cleric answers that one structurally. Most organisations find one of the two is a hard requirement rather than a preference.

Then weigh incident volume honestly. Memory pays in proportion to how often you have incidents, so a quiet estate should discount Cleric's strongest feature rather than pay for it.

Since neither publishes a comparable accuracy number, the only measurement available is one you take. Run whichever you shortlist against incidents whose true cause you already know, and score the first hypothesis rather than the eventual one.

Write the authority bound down before the trial rather than after. What governing an AI agent in production requires covers what a testable version of that looks like. The wider field, with where each tool is blind names the rest of the category on the same terms, including where we are blind.

NOFire AI as a third option

NOFire AI sells into the same evaluations and answers the authority question a third way. Cleric settles it by removing the ability to act. We kept the ability and moved the decision outside the agent.

• A policy gate checks every write before it runs, against the operations you allow and the action's predicted blast radius. It holds the action for a person, or refuses it.
• The gate records its verdict outside the agent. An auditor reads that record rather than the agent's own log.
• The production map is time-versioned. You can ask what the agent knew when it proposed an action, and what changed since. The Context and Control Model sets out why that matters.
• Coding agents run in a microVM through brig, our open-source sandbox. The control system watches the run from outside it and can stop it.

Write down one action you want the gate to refuse, then test it. Autonomy widens as the controls prove out, starting with evidence and bounded repeatable tasks with an engineer in the loop. NOFire AI vs Cleric covers that pairing in detail.