Agents Don't Need a New Identity Stack — They Need a New Enforcement Point

Why the enforcement point matters

An AI agent is a loop: the model proposes an action, a runtime (the harness) executes it, the result returns to the model as context, and the loop turns again. The harness is the actor — the model only makes suggestions. Effective control must sit directly inside the harness event loop where actions execute. Traditional defenses — gateways, sandboxes, SIEMs, and directories — each cover a different slice of the system, but none reach the loop where real-time decisions occur.

Ory enforces inside that 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's read or written, the HTTP method and host, the named tool inside an MCP server. That's the difference between recording risk and preventing it.

How the components work together

Follow one action through the stack — an agent attempting to call an internal API. Ory Kratos resolves identity first, and 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. A sub-agent that lives for ninety seconds never passes through a provisioning workflow; Kratos issues it identity anyway and records the delegation link back to the human.

Ory Hydra — Ory's OAuth2/OIDC server, in production for close to a decade — issues the credential the agent carries: scoped, short-lived, and revocable with a single API call. Ory Keto then decides whether the action is permitted, using Zanzibar-style relationship-based permissions rather than roles, because agent authorization needs to be specific: this binary with these arguments, this file path read-but-not-written, this HTTP method against this host, this table with this statement.

Past the harness boundary, Oathkeeper enforces on network traffic, Talos replaces long-lived API keys with short-lived, chain-of-custody credentials for enterprise endpoints, and Polis covers B2B and partner-facing access. Every decision — allowed, denied, escalated, approved — is emitted as a structured OpenTelemetry event into the SIEM a team already runs, with the delegation chain persisting after the credential expires.

What this doesn't do, and what to ask instead

Ory doesn't inspect prompt or context contents — a prompt-injection payload hidden in retrieved data is a different control class, and vendors working on content inspection are complementary rather than competitive here. There's also a deliberate failure-behavior choice: when a policy decision can't be reached, the default is fail-open, so a misconfigured or unreachable control plane can't lock an engineer out of their own machine mid-task. For a high-assurance environment, that's the wrong default, and choosing it deliberately belongs in any rollout plan.

Three questions cut through most agent-security pitches fast: Where does enforcement actually happen — and what covers the actions that never leave the machine? Is it the same authorization engine that already governs your people, or a second policy model that will eventually disagree with the first? And what happens, specifically, when the control plane can't be reached? For any team running an agent SDK, a custom pipeline, or an internal automation with standing credentials, the practical starting point is observe mode: evaluate and log every action without blocking anything. Within minutes, that produces the inventory of humans, agents, and sub-agents most organizations can't currently produce — then policy gets written from what agents actually did, on the team's own schedule.

Want to see it on your own agents? Ory is offering a free, full-featured trial of Ory Agent Security.