Your AI agents don't need a new identity stack. They need a new enforcement point.

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.

1. 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.
2. 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.
3. 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.