Most identity vendors have announced an agent security product in the last nine months. Nearly all of them are new systems, built alongside the identity infrastructure their customers already run.
That approach carries a cost. It puts your most autonomous workloads on your least proven infrastructure, and it leaves you maintaining two policy models that have to agree with each other.
Ory's position is that agents need the identity primitives you already operate. What they need, that is genuinely new, is a different place to enforce them.
Why the enforcement point matters
An AI agent is a loop. The model proposes an action, the runtime executes it, the result returns to the model as context, and the loop turns again. That runtime is usually called the harness.
The harness is the actor. The model only makes suggestions.
This tells you where control has to sit, because the established controls all sit somewhere else.
| Control | What it covers | What it misses |
|---|
| Gateway | Traffic you route through it | Local shell commands and file edits never reach it |
| Sandbox | The environment as a whole | Constrains reach, not individual actions |
| SIEM | A record of what occurred | Reports after the action completed |
| Directory | That an agent exists | What the agent did with that existence |
Ory enforces inside the harness event loop, using the hook the runtime already fires before and after every action. At that moment the system has the specific action in hand before it executes: the binary and its arguments, the file path and whether it is read or written, the HTTP method and host, the named tool inside an MCP server.
This is the difference between recording risk and preventing it.
How the components work together
The clearest way to explain the architecture is to follow one action through it. Take an agent attempting to call an internal API.
Establishing identity
Ory Kratos resolves identity before the agent runs anything. It resolves a chain rather than a single subject: the human who started the session, the agent process acting for them, and any sub-agents that agent spawns.
Agent identity differs from workforce identity in one important way. A directory entry assumes a long-lived subject you provision once. Many agents are the opposite. They are short-lived, started on demand, and capable of creating other agents.
A sub-agent that exists for ninety seconds will never pass through a provisioning workflow. If it runs as an unmanaged process, attribution breaks at exactly the point you need it. Kratos issues identity for the short-lived case and records the delegation relationship, so the link from human to sub-agent holds after the session ends.
Issuing the credential
Ory Hydra issues the credential the agent will carry. Hydra is Ory's OAuth2 and OpenID Connect server, in production use for close to a decade, and the agent case fits what it already does: scoped, short-lived, revocable credentials for a client that is not a person.
Revocation is the property that matters most here. When an agent holds a credential you can withdraw with a single API call, a kill switch becomes an operational control rather than a claim.
Authorizing the action
Ory Keto decides whether the action is permitted. Keto implements Zanzibar-style relationship-based permissions, which suits agent authorization better than roles do.
Roles are coarse. Agent permissions need to be specific:
- this binary, with these arguments
- this file path, read but not written
- this HTTP method against this host
- this named tool inside this MCP server
- this table, this statement
Those are relationships between subjects and objects, not a list of roles. Keto is built for that model, and it is the same engine already governing application access for organizations running it in production. Agents inherit the existing policy model instead of getting a second one.
Note: Running one authorization engine for humans and agents has a practical benefit. A permission change applies to both at once, rather than drifting between two systems that were never designed to stay in sync.
Enforcing beyond the harness
An agent's action often continues past the harness boundary, and the stack continues with it.
Ory Oathkeeper is the identity and access proxy for the network path. It sits in front of services that need to know who is calling, and enforces on traffic that does travel over HTTP.
Ory Talos covers enterprise endpoints and gateways, and specifically the long-lived API key. Static keys are among the most persistent credential problems in most organizations, and giving them to autonomous software increases the exposure. Talos uses token exchange to replace them with short-lived credentials that can be narrowed in scope and carry a full chain of custody.
Ory Polis handles B2B endpoints and enterprise connections, which is where agent access begins crossing partner and customer boundaries rather than internal ones.
Recording the decision
Every decision is emitted as a structured event through OpenTelemetry: allowed, denied, escalated, or approved. The format is open and the destination is the SIEM you already operate, not a separate dashboard.
The delegation chain persists after the credential expires. That is what allows the record to answer a question months later. Most organizations today cannot say which human authorized the agent that touched a given system in July.
Three consequences of building it this way
Harness coverage is a property of the design
Ory integrates against the agentic turn, the common event lifecycle every agent runtime implements, rather than against any single vendor's API. The same enforcement framework therefore covers 11 coding harnesses and 14 agent SDKs, and supporting a new one is incremental work rather than a new product.
For an organization running several models, the effect is that adopting a new model or harness does not restart the security review. One policy set and one audit trail apply regardless of which runtime a team chose.
Every vendor claims broad support, so it is worth being specific about why this holds. No harness is privileged in the integration. There is no first-class runtime and no second-class one.
Scale comes from the existing components
Agent Security did not have to establish its own scalability. Kratos, Hydra, and Keto currently manage more than 3.5 billion identities across more than 34,000 production deployments, handling upward of 4.4 billion transactions per day.
Agents change the volume profile. They generate machine-speed request rates against fine-grained authorization checks. They do not change the underlying operation. A permission check for an agent is the same check as for a human, on the same engine, on infrastructure already running at that volume.
Deployment remains the customer's choice
About half of Ory's enterprise business is self-managed, which is uncommon in this category and directly relevant to agent workloads. The organizations least willing to trust autonomous software are generally the ones under the strictest data-handling obligations.
Agent Security runs self-managed or on the Ory Network. Moving between the two does not require re-architecting.
What Ory Agent Security does not do
Ory does not inspect prompt or context contents. If your concern is a prompt-injection payload hidden in retrieved data, that is a different control class. Vendors working on content inspection are complementary to this approach rather than competitive with it. Ory's scope is actions, not intent.
There is also a failure-behavior decision to make before production. When a policy decision cannot be reached, because Ory is unreachable, rate-limited, or unconfigured, the default is fail-open: the action proceeds, and the failure is recorded as an explicit gap in the audit trail rather than passing silently.
That default exists so installing the plugin cannot lock an engineer out of their own machine mid-task. For a high-assurance environment it is the wrong default, and choosing failure behavior deliberately belongs in any production rollout plan.
A control plane whose limits you cannot describe is a control plane that will not survive a security review.
How this fits into an AI platform
The teams making these decisions are increasingly not security teams alone. They are AI platform teams, assembling GPUs, models, vector databases, orchestration, and evaluation tooling, with identity and access management as a component of the platform rather than an afterthought.
That team has a requirement that follows from its mandate. The identity layer cannot be the thing that ties the organization to one model vendor. Governance also stays their responsibility no matter which third parties they buy from, which makes owning the audit trail more useful than renting a dashboard.
Ory DX is the adoption path. It puts the stack inside the coding agent an engineer already works in, combining MCP servers, plugins, the CLI, and Ory Elements in a conversational workflow. A best-practices implementation of identity, authorization, and permissions takes minutes rather than the days teams currently spend assembling one by hand.
The full architecture:
| Layer | Concern | Component |
|---|
| Agent development | Best practices by default | Ory DX |
| Agent runtimes | Enforcement in the event loop | Ory Agent Plugins |
| Agent identities | Human, agent, sub-agent, delegation | Ory Kratos |
| Agent authorizations | Scoped, revocable credentials | Ory Hydra |
| Agent permissions | Allow or deny per action | Ory Keto |
| Enterprise endpoints | Short-lived credentials, chain of custody | Ory Talos |
| Identity proxies | Network-path enforcement | Ory Oathkeeper |
| B2B endpoints | Partner and customer boundaries | Ory Polis |
| Observability | Structured audit events | OpenTelemetry |
Nine layers, one identity model, and no component in the middle that had to be invented for this moment.
What to ask when evaluating agent security
Three questions separate the field quickly.
- Where does enforcement happen? If the answer is a gateway, a proxy, or a log pipeline, ask what covers the agent actions that never leave the machine.
- Is it the same authorization engine that governs your people? Two policy systems will eventually disagree, and the disagreement tends to surface during an incident.
- What happens when the control plane cannot be reached? Every product has an answer. Few publish it.
Bottom line
Agent Security is not a new category of infrastructure. It is identity, authorization, and audit applied at a new enforcement point, inside the runtime where agents actually act.
Organizations that already operate these primitives should be extending them rather than buying a parallel stack. Start in observe mode, where every action is evaluated and logged but nothing is blocked. Within minutes you have the inventory of humans, agents, and sub-agents that most organizations cannot currently produce. Write policy from what your agents did, then decide what to enforce on your own schedule.
