Ory Agent Security Is Expanding to 11 Harnesses and 13 Agent SDKs
Secure AI agents across LangChain, CrewAI, Claude Code, and more. Ory delivers fine-grained authorization and audit trails to close the agent blind spot.


Product Technologist
Secure AI agents across LangChain, CrewAI, Claude Code, and more. Ory delivers fine-grained authorization and audit trails to close the agent blind spot.


Product Technologist
AI agents have quietly become some of the most privileged actors in modern engineering organizations. They read repositories, run shell commands, edit production code, call internal APIs, and open pull requests — all under a developer's credentials, and almost always outside the reach of a traditional security gateway. That's the blind spot Ory Agent Security was built to close, and today we're closing a lot more of it at once.
Until now, Ory Agent Security covered five AI coding agent harnesses in production: Claude Code, Gemini CLI, OpenAI Codex, OpenClaw, and OpenCode. Today that coverage expands on two fronts at once. Six more harness integrations are shipping — Continue, Goose, Cline, Amp, Pi, and Google Antigravity — bringing coverage to eleven harnesses total. And we're launching an entirely new product line alongside them: thirteen Agent SDK integrations, bringing the same identity, authorization, and audit model to teams building their own agents on frameworks like LangChain, CrewAI, Mastra, and AWS Strands, rather than using an off-the-shelf coding harness. Between the harness plugins and the SDK integrations, Ory now secures agents across eleven coding harnesses and thirteen frameworks from a single policy model.
The problem with agent security isn't a lack of good intentions. It's that agents act inside developer environments, not at the network edge. A gateway or API proxy can't see a shell command an agent runs locally, a file it edits on disk, or a local MCP tool call that never crosses a network boundary. By the time an action shows up in a log, if it shows up at all, it has often already happened.
Ory's approach is to enforce in the loop, at the point where the agent actually decides to act. Every agent and sub-agent authenticates with its own credentials before it can do anything. The delegation chain back to the human user or the upstream agent that spawned it is recorded before the first tool call runs, not reconstructed afterward. Every allowed, denied, deferred, or approved action gets written to an audit trail that survives even after the underlying credentials expire.
That model only matters if it works everywhere agents actually run, whether that's a developer's terminal or a custom multi-agent pipeline your team built in-house. That's the gap this expansion closes.
Already running in production:
New with this release:
All eleven ship the same session auth, per-tool authorization, and tracing model.
Agent SDK integrations — a brand new product line for developers building their own agents on top of an Agent SDK rather than running a packaged harness.
Thirteen integrations are launching at once:
That's thirteen frameworks covered from day one of the product line.
All of this sits on one shared core: @ory/argus in TypeScript and its Python sibling ory-argus, which own the actual Ory logic — session auth, per-tool authorization, tracing, and sub-agent identity — behind a small set of adapter primitives (sessionStart, gate, complete, registerSubagent, wrapTool). Every harness plugin or SDK integration is a thin translation of that harness's or framework's own hook contract onto those primitives, not a rewrite of the security model. That's also how we shipped six new harnesses and an entirely new lineup of thirteen SDK integrations in a single release: no new core logic, just new adapters.
Before a tool call executes anywhere in this ecosystem — a shell command, a file write, an MCP server connection, a downstream API call, a tool invoked from inside a LangChain agent or a CrewAI crew — Ory checks it against Ory Keto, the same Zanzibar-style fine-grained permissions model that already governs human access in most Ory deployments. Ory Kratos manages identities and Ory Hydra issues OAuth/OIDC tokens underneath that, so agent identity extends the stack teams already run instead of bolting on a parallel system.
MCP support gets particular attention across both product lines. Because MCP servers can expose external tools, resources, and prompts to an agent, Ory adds OAuth 2.1 authorization at the server level, with an option to enforce individual tools within a server too — so an agent authorized for one coding tool doesn't automatically inherit every tool an MCP server happens to bundle in.
Enforcement is designed to fit wherever a team is in its rollout. Organizations can start in observe mode to see what agents are actually doing, then tighten policies once they know what "normal" looks like. If Ory itself is unreachable, rate-limited, or unconfigured for a given policy, the system fails to open and logs the gap rather than silently blocking developer work.
A team brings in contractors who use Cline or Amp against the same repository as full-time engineers on Claude Code. Ory scopes what each contractor's agent session can do at the tool level — read and suggest, but not push, deploy, or call production APIs — using the same permission policies already defined for human contractor accounts, regardless of which harness the contractor prefers.
A planning agent — whether it's a Claude Code session spinning up sub-agents or a CrewAI crew delegating tasks between agents — gets each sub-agent its own credentials and audit trail. The delegation chain back to the original session is preserved even after any individual token expires, so when something breaks three steps into a pipeline, teams can trace exactly which agent acted and which policy allowed or blocked it.
One squad runs Codex, another has standardized on Goose, and a platform team is building a custom support-triage agent on LangGraph. Security teams don't want a different answer to "can this agent call our billing API" depending on which tool or framework asked. With Ory enforcing the same Keto policies across eleven harnesses and thirteen SDKs, the answer is identical everywhere.
A data team builds an internal research agent on Pydantic AI, or an ops team wires up a Mastra workflow that files tickets and queries internal APIs. These agents never touch a packaged coding harness, but they still act with real credentials against real systems — ory-pydantic-ai or @ory/mastra bring the same authorization and audit trail to that custom code with one small import, instead of leaving it as the one unmonitored corner of the stack.
Security teams increasingly need to answer "did an AI agent touch this system, and under whose authority" during incident reviews. Because Ory records allowed, denied, and approved actions as structured events exported through OpenTelemetry — across every harness and SDK, not just one — that question has an actual answer, no matter which team's agent is in question.
Every package announced today is published and installable now, the same way any other package would be: pull @ory/claude-code, @ory/gemini-cli, @ory/codex, @ory/openclaw, @ory/opencode, @ory/continue, @ory/goose, @ory/cline, @ory/amp, @ory/pi, @ory/antigravity, or any of the thirteen Agent SDK integrations from npm or PyPI. For Claude Code specifically, /plugin marketplace add ory/claude-plugins followed by /plugin install ory-agent-plugin@ory gets you there without leaving the terminal. Everything works whether you're self-hosting Ory or running on Ory Network, so there's no separate infrastructure to stand up just to get agent visibility online.
Wherever your engineers run agents — Claude Code, Codex, Goose, Cline, or a framework they built in-house on CrewAI or Strands — Ory Agent Security is built to meet them there. Join the conversation in the Ory Slack community and let us know what you're building next.