The numbers are in for the first full year of enterprise AI agents, and they are not reassuring. In a survey of enterprise security leaders published in April 2026 by the Cloud Security Alliance and Token Security, 65% of organisations reported at least one cybersecurity incident in the past year caused by an AI agent operating on their network. Of those incidents, 61% involved sensitive data exposure, 43% caused operational disruption, and 82% of organisations found agents running in their environment that they did not know about. This is not the failure rate of an emerging technology finding its feet. It is the signature of a capability that arrived faster than the discipline to run it.
The instinct, on reading a statistic like that, is to reach for more security. More monitoring. More scanning. A dedicated agent-security tool to sit alongside the agents and watch them. That instinct is understandable, and it is wrong, or at least, it is aimed at the wrong layer. The organisations in that two-thirds did not fail because they lacked a security product. They failed because they deployed something new, an autonomous actor with credentials, tool access, and reach across their systems, and secured it the way they would secure an app.
An agent is not an app. This is the distinction that the incident numbers keep making, and it is worth stating plainly.
An actor, not an application
An application waits to be told what to do. It exposes endpoints; a human or another system calls them; it responds. Its blast radius is defined by its interface. You secure it by securing that interface, authentication at the door, validation on the inputs, rate limits on the traffic.
An agent does not wait. It is given a goal and the latitude to pursue it, which means it decides, at runtime, without a human in the loop for each step, which tools to call, which data to read, which actions to take. It carries credentials so it can act on your behalf. It moves across systems that were never designed to be traversed by a single automated identity at machine speed. Its blast radius is not its interface. Its blast radius is everything it can reach.
Bolt-on security cannot govern that. A scanner that inspects an agent's output after the fact is reading the smoke, not managing the fire. A monitoring layer that watches an agent's traffic can tell you a breach happened; it cannot make the breach architecturally impossible. You cannot perimeter-secure an actor that has already been handed the keys and told to go be useful. By the time your security layer sees the problem, the agent has already read the data, called the tool, and moved on.
Securing an agent after it acts is a different discipline from building an agent that cannot act outside its governance. The first is a product you buy. The second is an architecture you build, and it has to be built in from the first line, because you cannot retrofit a substrate.
Governance in the substrate
We did not arrive at this view by watching the incident numbers. We arrived at it because we built an agent platform, and building one forces the question early: what stops this thing from doing something you did not intend? If the honest answer is "we trust it" or "we watch it closely," you have already lost. The only durable answer is that the agent runs inside a substrate it cannot escape.
ORCA is built that way, on purpose, from day one. The governance is not a feature layered on top of the agents. It is the ground they stand on.
Authentication is not optional and never was. There is no anonymous access to anything, not for a user, not for an agent, not for testing, not for convenience. Every request that reaches the system carries an identity, and every identity carries a scope. An agent cannot act as no one. It cannot widen its own permissions unnoticed. The door is locked from the first commit, and there is no configuration that unlocks it.
Every action is provenance-stamped. When an agent reads knowledge, writes knowledge, or calls a model, the event is recorded with its lineage, which agent, under which identity, against which store, at which time, producing which result. This is not a log you switch on. It is the write path. The question "what has this agent actually done?" has an answer that is queryable, permanent, and complete, because there was never a code path that let the agent act without leaving the record.
Every write passes a gate. Knowledge does not enter a store because an agent decided it should. It enters because it cleared a write gate that checks structure, confidence, freshness, classification, and personal data, in code, with no override and no admin bypass. An agent that tries to store raw personal information does not store it; the PII pipeline tokenises identifiers before anything touches the knowledge base, and the raw values live in a separate, encrypted store with their own controls. The agent's good intentions are irrelevant. So are its bad ones. The gate runs the same either way.
Scope is enforced, not requested. Knowledge is partitioned into isolated brains, personal, practice, engagement, governance, and an agent sees only what its identity is entitled to see. Engagement-specific intelligence for one client cannot leak into another's scope, because the isolation is a property of the architecture, not a policy the agent is asked to respect. An agent cannot read across a boundary it was never granted, no matter how it is prompted.
You cannot monitor what you did not design to be observed
There is a reason "add monitoring" is the reflexive fix, and a reason it disappoints. Monitoring bolted onto a system after the fact can only observe what that system happened to expose. If an agent can take an action that leaves no trace, no amount of downstream monitoring will surface it, the event simply is not there to be seen.
"Observability is not something you add to an agent. It is something you design into the moment the agent is provisioned, or it is something you spend the next year wishing you had."
ORCA's discipline is that nothing is created until it can be monitored. An agent is not provisioned and then, later, instrumented. Its telemetry, its provenance, its scope, and its guardrails exist at the moment it exists. This is the difference between knowing what your agents are doing and hoping to find out. The two-thirds who had an incident this year were, in most cases, in the second category, running agents they could not fully see, discovering the reach of an agent only after it had reached somewhere it should not have.
The real category of the problem
It is tempting to file this year's incidents under "AI security" and wait for the security industry to ship a fix. That framing will cost the organisations that adopt it another year.
The 65% did not have an agent-security problem in the sense that a firewall or a scanner would have solved. They had an agent-governance problem. Security was downstream of an architecture that never governed the agent in the first place, that granted autonomy without scope, credentials without provenance, reach without gates. The incident was not the failure. The incident was the symptom. The failure was upstream, in the decision to deploy an actor into a substrate that could not contain it.
This is not a counsel of despair, and it is emphatically not an argument against agents. Agents are worth deploying; the productivity is real and the direction of travel is not reversing. It is an argument about sequence. Govern first, then grant autonomy, because an agent inside a governed substrate is an asset, and the same agent inside an ungoverned one is a liability that has not surfaced yet.
The organisations that stay out of next year's statistic will not be the ones who bought the best agent-security tool. They will be the ones who never needed it, because the agent could not act outside its governance in the first place. Security you can buy. A substrate you have to build, and you have to build it before the agent, not after the incident.