The Agent Security Solution Guide: Observe, Enforce, Build, and Deploy

Learn how Ory Agent Security helps teams understand agent behavior, apply least-privilege controls, secure custom agents, and carry trustworthy identity into production.

AI agents are moving from experiments into daily work. They edit files, run shell commands, call APIs, use MCP servers, and delegate tasks to other agents. That reach makes them useful, but it also creates a new identity and access problem: when an agent acts, who authorized it, what was it allowed to do, and can the action be traced back to a responsible human?

Traditional application security controls do not answer all of those questions. A shared service account can authenticate a workload, but it does not explain which user launched an agent session or which sub-agent made a particular tool call. A log may show that a command ran, but not whether policy evaluated it before execution. A model guardrail may influence an answer, but it does not provide an identity-aware authorization boundary around tools.

Ory Agent Security brings identity, authorization, and accountability to the point where agents act: the agent harness and SDK tool boundary. Its product lifecycle has four connected parts (click on links below to jump to that section):

• Observe agent activity and would-be policy denials without interrupting work.
• Enforce authorization decisions when a team is ready to block actions.
• Build identity and policy checks into custom agents through harness plugins and SDK integrations.
• Deploy agents with durable, revocable runtime identities and controlled credential delivery.

These are not four equivalent operating modes or a mandatory sequence. Observe and Enforce are runtime postures. Build and Deploy are the developer and operations workflows that carry the same security model into agents you create and run. Together, they support a practical path from discovery to production control.

Why agent security needs a lifecycle

An agent rarely performs one isolated action. A person starts a session, the agent plans work, tools touch systems, and sub-agents may take on specialized tasks. Security has to preserve that chain without reducing everything to one broad machine credential.

Ory Agent Security separates the principal types involved:

• The user is the human responsible for the work.
• The agent is the runtime or machine principal making requests.
• A sub-agent is a separately identified child runtime when the harness or SDK exposes a stable delegation boundary.

Ory associates successfully submitted delegation and lifecycle activity with centrally managed policy decisions. That creates an accountability chain from human to agent to sub-agent to action. It also lets teams adopt controls incrementally, instead of choosing between unrestricted agents and an immediate, disruptive lockdown.

Observe: establish visibility before blocking work

Most teams should not start an agent security program by guessing which commands and tools to deny. Agents are used differently across repositories, roles, and environments. A rule that is sensible for a production operations agent may be unnecessary for a developer working in a disposable sandbox.

Observe is the default posture in Ory Agent Security. The integration authenticates the runtime, checks permission at the tool boundary, and records the decision and lifecycle activity. If policy would deny an action, Ory Agent Security in Observe mode reports that result while allowing the supported tool call to continue.

This gives security and platform teams evidence for policy design:

• Which harnesses and agents are active?
• Which people are delegating work to them?
• Which tools and shell programs do they use?
• Where would a proposed policy interrupt legitimate work?
• Are unexpected tools, identities, or sub-agent patterns appearing?

Ory Agent Security stores privacy-conscious, structured audit activity rather than raw prompts, tool inputs, tool outputs, credentials, or command contents. For accepted activity and broker processing, Agent Security can emit server-side OpenTelemetry to existing observability workflows, while its database remains the durable audit source.

Observe use case: introducing coding-agent governance

Consider an engineering organization in which developers already use Claude Code, Codex, Cursor, OpenCode, and other coding harnesses. The security team wants oversight, but a company-wide blocking policy based on assumptions would create friction.

The organization can install the corresponding Ory Agent Plugins, connect them to its Ory project, and begin in Observe. The team can then identify common tools and program names, without collecting raw command text or arguments, understand differences between teams, and find high-risk outliers. A proposed block can be evaluated against real activity before enforcement is enabled.

The result is a rollout based on evidence, not a one-time questionnaire about how developers think they use agents.

Enforce: turn policy into a runtime decision

Visibility matters only if a team can act on it. Enforce applies the authorization decision at the location of an action before it occurs. An explicit denial then prevents execution instead of only recording what would have happened.

Policies can address broad categories such as destructive tools, editing tools, code generation, and HTTP tools. Teams can also target known plugin tools, categorized shell commands, custom executable words, and custom groups of tools. Scope can be broad or narrow, including the project, a human identity, a registered agent, or a sub-agent. Broader blocks are not silently overridden by narrower scopes.

Enforcement can also be introduced selectively. A project may remain in Observe while enforcement is enabled for a particular identity, harness, or sub-agent type. This is useful when a team wants to control a sensitive workflow without changing every agent interaction at once.

Enforcement depends on the interception capability of the harness or SDK. Ory uses the integration's native blocking mechanism where one exists. Tools that bypass that configured integration boundary are outside its control. For ordinary connectivity or rate-limit failures, published Ory integrations are designed to fail open so an unavailable policy service does not unexpectedly halt all agent work; authentication and untrusted credential failures are handled more strictly.

Enforce use case: least privilege for production support

Imagine a support engineering agent that can read diagnostics, query approved internal tools, and draft remediation steps. It should not edit source files, invoke destructive commands, or reach an unapproved MCP server.

After observing the agent's normal behavior, the team can enable enforcement for that agent and block the risky tool categories while leaving diagnostic access available. If the workflow later needs one additional tool, administrators can update the central policy, saving time rather than shipping a new prompt or asking every user to change local configuration.

Enforce use case: containing a compromised session

If a particular identity, registered agent, agent harness, or sub-agent type begins behaving unexpectedly, a team can narrow enforcement to that scope. Distinct agent identities and delegation records make this more precise than disabling a shared service credential used by unrelated workloads.

Build: put security inside the agent's action loop

Organizations do not only consume off-the-shelf coding agents. They build customer-support agents, operations copilots, research systems, CI automation, and multi-agent workflows. Those agents need the same identity and authorization model.

Build provides two integration paths:

• Harness plugins secure existing agent products whose control loop is owned by the harness.
• Agent SDK integrations attach Ory to an agent application a developer owns, usually through a before-tool hook, middleware, guardrail, callback, or tool wrapper.

The shared lifecycle is consistent even when framework APIs differ:

1. Start or resolve an agent session.
2. Authenticate the human and runtime as appropriate.
3. Record the root delegation and any supported sub-agent delegation.
4. Check permission before each intercepted tool call.
5. Record completion and, where the adapter lifecycle exposes it, failure after the call.

Ory publishes integrations for TypeScript and Python ecosystems, including popular agent SDKs and frameworks. The Build experience provides framework-specific quickstarts that show the correct interception point and an allow/deny verification flow. This lets developers work in the abstractions of their chosen framework instead of implementing the underlying identity and authorization protocol from scratch.

Build use case: protecting a customer-support agent

A team building a support agent with a Python framework might give it tools to read account status, issue credits, and change subscriptions. The team can wrap or intercept the complete tool map with the appropriate Ory integration.

Read-only account lookup may remain available to the agent, while a centrally configured policy can allow or block credit issuance and subscription changes for the responsible user and runtime. Delivered decisions and outcomes are associated with the delegation chain. If the agent later adds a specialist sub-agent, the child can receive its own identity rather than inheriting one indistinguishable credential.

Build use case: governing agentic CI

An agent in CI (continuous integration) may review code, run tests, and open a pull request. It should not gain unrestricted shell or network access simply because the workflow has a powerful token. Integrating Ory at the tool boundary allows the team to define what that agent type can do and preserve attribution to the deployment owner or automation sponsor.

Deploy: carry identity and policy into the runtime

A secure integration in source code is only part of the job. A production agent also needs a noninteractive runtime identity, protected credential delivery, a compatible runtime target, and a lifecycle for activation and revocation.

Deploy handles that Agent Security boundary. An Ory provided catalog describes supported agent types, runtime targets, package recipes, credential methods, and compatibility constraints. Operators can use the browser workflow or the ory-agent CLI to plan and create a deployment. The resulting package contains Agent Security registration and runtime configuration for the selected target, not the customer's application or infrastructure.

The first authenticated runtime request moves a deployment from ready to active. Revocation invalidates the deployment and its linked runtime credentials, including linked child credentials.

The deployment model deliberately keeps trust boundaries explicit. A trusted, operator-owned controller launches the workload without giving the agent permission to administer deployments. The infrastructure remains under the operator's control.

Deploy use case: a short-lived sandbox agent

A team may run an OpenAI Agents SDK application in an E2B sandbox. The sandbox template can remain immutable and free of credentials. An external controller creates or reuses the Agent Security deployment and supplies runtime values only when the workload starts.

The application starts with its Deploy-issued identity, resolves server-owned context, and makes guarded tool calls. The team gains the same attribution and policy behavior used during development without embedding a human login token or long-lived secret in the template.

Deploy use case: a durable Kubernetes workload

For a long-running agent on Kubernetes, an operator can select a compatible package recipe and authentication method, then connect the generated runtime configuration to its existing workload and secret-management process. Agent Security supplies the identity and authorization boundary while the organization continues to own workload scheduling, network policy, and application deployment.

Deploy use case: managed coding-agent rollout

Deploy also supports distributing approved harness plugins to managed endpoints through cataloged delivery targets. IT can create pinned, secret-free installation artifacts for supported device-management systems. Machine installation and inventory verification remain separate from user activation: each user still completes the approved browser login when starting a configured harness.

Putting the lifecycle together

A complete adoption path might look like this:

1. Observe existing harnesses. Connect coding-agent plugins and learn how teams actually use tools and commands.
2. Design policy from evidence. Group related capabilities and identify actions that should never run in particular contexts.
3. Enforce progressively. Start with a sensitive identity, harness, agent, or sub-agent type before expanding controls.
4. Build protected custom agents. Add the appropriate SDK integration at every tool execution path and test both allowed and denied actions.
5. Deploy with noninteractive identity. Select a catalog-compatible runtime and credential method, keep credentials out of images and source, and verify activation.
6. Operate continuously. Review activity, adjust policy, rotate or revoke deployments, and apply the same pattern to new agents and tools.

Other teams may enter elsewhere. A new custom agent will likely begin with Build, move to Deploy, and use Observe before Enforce. An organization with widespread coding-agent usage can begin with Observe immediately. The lifecycle is a control loop, not a waterfall.

Identity is the thread through every stage

Observe, Enforce, Build, and Deploy solve different parts of the problem, but identity connects them. The same core questions remain throughout:

• Which human or automation sponsor is responsible?
• Which runtime is acting?
• Was work delegated to a child agent?
• Which policy applied at the moment of action?
• What happened after the decision?
• Can access be revoked without disrupting unrelated agents?

By answering those questions at the tool boundary, Ory Agent Security gives teams a practical way to move from agent experimentation to governed production use. They can begin with visibility, introduce controls without a big-bang rollout, integrate security into the agents they build, and deploy those agents with identities designed for their actual runtime.

Get started with complimentary use for a limited time. Try out Ory Agent Security by creating an account and begin understanding how agents are being used in your environments. See our supporting documentation to learn more.