Securing AI Agents Takes Two Layers: the Tool Call and the Runtime
Prompt filters and borrowed human tokens don't hold up once agents reach production. Ory Agent Security splits the problem in two: authorize every tool call inside the agent loop, and give every deployed runtime its own machine identity.
- Ory Agent Security introduces a two-layer framework — "Build" (authorizing tool calls within the agent loop) and "Deploy" (assigning machine identities to agent runtimes) — to address security gaps left by prompt filtering and shared OAuth credentials.
- The Build layer intercepts tool calls between decision and execution via plugins for Claude Code, Cursor, and Gemini CLI, plus SDK wrappers for OpenAI Agents SDK, LangChain, LlamaIndex, Vercel AI SDK, and CrewAI.
- Ory Talos replaces static API keys with actor-bound, single-use macaroon tokens in a parent-child hierarchy, where revoking a parent key instantly invalidates all derived child tokens.
- Tool policy evaluation fails open to prevent control-plane outages from halting agents, while runtime identity verification fails closed, blocking any invalid, expired, or revoked credentials.
- Audit logs capture payload hashes rather than raw prompts or model inputs, preventing the logs themselves from becoming a vector for sensitive data leakage.
Takeaways
- Most agent security today stops at prompt filtering or reuses a human's OAuth credentials. Neither survives the move to production.
- Ory Agent Security works on two layers: Build, which authorizes tool calls inside the agent loop, and Deploy, which assigns identities to the runtimes agents run in.
- Tool calls are checked after the agent picks an action and before it executes, via harness plugins (Claude Code, Cursor, Gemini CLI) or SDK wrappers (OpenAI Agents SDK, LangChain, LlamaIndex, Vercel AI SDK, CrewAI).
- Ory Talos replaces static API keys with actor-bound, single-use, narrowing-only tokens, where revoking a parent key kills every child token.
- Tool policies fail open to avoid outages; runtime identity fails closed against invalid, expired, or revoked credentials.
Why one layer isn't enough
When agents move from prototype to production, the usual controls fall short. Prompt filtering inspects what goes into the model but not what the agent does next. Copying a developer's OAuth token into an agent gives it a human's full access with none of the accountability. Ory's argument is that production agents need control in two places: inside the application, where the agent decides to call a tool, and inside the infrastructure, where that agent actually runs.
Ory calls these Build and Deploy. Build governs the action loop with identity-aware authorization policies. Deploy gives each execution environment a noninteractive machine identity and handles secret rotation, activation, and revocation. Every guarded action traces back through the same chain: the human or automation that sponsored the work, the root agent runtime, any sub-agent it spawned, and finally the tool call itself.
Build: checking the action before it runs
Agents cause side effects through tools: reading files, running shell commands, querying databases. Ory Agent Security sits at the boundary between choosing an action and executing it, and can allow or block the call. Teams plug it in two ways: harness plugins that use the native hooks in Claude Code, Cursor, and Gemini CLI, or TypeScript and Python wrappers for the OpenAI Agents SDK, LangChain, LlamaIndex, Vercel AI SDK, and CrewAI.
Each guarded call follows the same sequence. A headless workload first presents a proof issued by the Deploy layer and gets server-owned context back, so the agent can't invent the identity it claims to act for. The policy is then evaluated before execution. In Observe posture, denials are logged and the call goes through; in Enforce posture, the framework's own blocking signal stops the tool from dispatching. Finally, an audit event records whether the call completed or failed, using payload hashes rather than raw prompts or model inputs, so the logs don't become a new place for sensitive context to leak.
Deploy: identities for runtimes, not people
A deployed agent can't click through a browser login, and it shouldn't carry a developer's static credentials. The Deploy layer registers each runtime's identity ahead of time along four dimensions: agent type, runtime (Docker, Kubernetes, E2B), package recipe, and credential method. A deployment is declared in a short spec:
api_version: agent-security.ory.sh/v1
kind: AgentDeployment
name: support-agent
agent_type: openai-agents
runtime_id: e2b
package_recipe: e2b-sandbox
package_recipe_version: v1
credential_method: talos_api_keyThe credential itself comes from Ory Talos, which issues actor-bound, single-use keys built for short-lived sandboxes. Talos uses macaroon tokens, whose permissions can be narrowed but never expanded, and derives keys in a hierarchy, so revoking a parent instantly invalidates every child token. IP allowlists and time-to-live limits make a stolen key useless outside the network or after it expires, and token prefixes let secret scanners spot leaked keys automatically.
The handoff is designed to keep admin secrets away from the agent. The operator CLI passes runtime credentials to trusted runner processes over standard input. The agent receives proof that its runtime is authenticated, while the administrative deployment keys never enter the workload's memory.
When things go wrong
Ory makes a deliberate split in failure behavior. Tool evaluation policies fail open when upstream connectivity drops, so a control-plane outage doesn't take every agent down with it. Runtime identity does the opposite and fails closed: an invalid, expired, or revoked credential gets no access. When a workload is retired or compromised, an explicit revocation invalidates the root agent and all of its sub-agents at once, closing the loop from code to runtime.
For a closer look at how the Build and Deploy layers fit together, Ory has published a technical deep dive on building and deploying secure AI agents.
Comments
