How to Really Secure an AI Agent (2026 Guide)

How to move beyond "we sandboxed it": stacking containment, brokered credentials, and behavioral authorization into an agent architecture that is bounded, attributable, and survivable.

Why is sandboxing alone not enough?

TL;DR: Asking "is your agent secure?" is like asking "is the building safe?" Fire safety, access control, and structural engineering are different systems that answer different questions. Agents need three: a sandbox (what the process can touch), brokered credentials (what it can prove it may do), and contextual authorization (whether the next action makes sense). This guide walks through four architectures, showing what each stage fixes, what it silently leaves open, and how to evolve your deployment one layer at a time.

This post is the architecture deep dive. For the broader implementation checklist across identity, deployment, monitoring, and governance, start with our agentic AI security guide.

AI agents are getting more capable and moving deeper into production systems. Every tool, repository, API, and credential you wire into an agent expands what it can do. It also increases the damage a compromised or confused agent can cause.

When researchers built the first autonomous AI systems, such as Shakey at SRI from 1966 to 1972, they had a very specific environment in mind: a bounded laboratory, a narrow set of actions, and a world whose rules were largely known in advance. The hard problem was getting a machine to perceive, plan, and move at all. Nobody was giving it access to production databases, cloud consoles, payment systems, source code, or a company's internal communications.

Decades later, an agent still receives a goal, interprets its environment, plans a sequence of actions, and acts through tools. But its environment is now the open web, untrusted email, third-party APIs, SaaS applications, code repositories, and internal systems.

And when teams ask how to secure this, the industry's default answer is one word: "sandbox it."

This answer isn't wrong. It's incomplete in a way that quietly leaves the most damaging failure mode wide open. For example, last week I probed an agent running in a production-grade macOS sandbox with deny-by-default filesystem access, SSH keys blocked, Keychain blocked, and writes outside the workspace denied by default. Every control held. But when you curl, you get HTTP 200, as you should, because coding agents need network access for packages and Git pushes.

The danger is in composing the two granted permissions: read the repository plus reach the internet. No stolen credential or broken rule is required; everything was authorized ahead of time.

The failure mode is no longer hypothetical. During OpenAI's July 2026 internal cybersecurity evaluations, which ran with reduced safeguards and primarily involved an internal-only research model, agents intended to be isolated used shared Artifactory infrastructure as an unauthorized message board and a path to the internet. An independent METR investigation found that roughly 1,200 agents exchanged more than 70,000 messages and files, and about 700 participated in the subsequent attack on Hugging Face. The lesson is not that sandboxes do nothing. It is that process isolation does not automatically secure shared services, network egress, exposed credentials, or coordination across agents. OpenAI's incident report reaches the same broader conclusion.

The problem is authorized steps compounding into outcomes nobody approved. Static resource controls usually evaluate actions one at a time. The dangerous object isn't the action; it's the sequence. A conventional resource sandbox does not catch that sequence unless the deployment also adds stateful data-flow tracking or egress mediation. At Kontext, we build the runtime authorization layer this stack points toward. This guide starts at the foundation because each layer depends on trustworthy signals from the layers below it.

How to read this guide

This post moves from fundamentals through a staged architecture walkthrough, then out to operational guidance:

• Part I: What a sandbox actually promises. Fifty years of containment history distilled into the design properties that matter and the gaps conventional resource policies generally leave open.
• Part II: Four architectures. The evolution from naive to layered, one stage at a time, each with its system design, what breaks, and what survives.
• Parts III–IV: Coverage and operations. Which layer defends against which failure mode, and what to implement first.

If you only want to know whether your sandbox is enough, read the introduction and Stage 1 of Part II. If you're designing agent infrastructure, the later stages are where it gets interesting.

Part I: What does an AI agent sandbox actually protect?

A sandbox is a containment boundary and therefore part of a security architecture. It is not a complete architecture for an agent with external authority. A sandbox can restrict the resources it is configured to mediate, but its coverage depends on the mechanisms and policy in use. A conventional static resource sandbox generally does not determine whether individually allowed actions combine into a harmful trajectory, and it cannot protect a credential the process is still permitted to read.

Why containment exists and why it matters

Before OAuth, applications shared passwords. Before sandboxes, processes shared everything.

Early operating systems ran every program with the full authority of whoever launched it. If you ran a text editor, it could read your mail. The fix arrived in stages: chroot confined services to a directory subtree; FreeBSD jails added process and network isolation; Solaris Zones, Linux namespaces, seccomp, Windows AppContainer, and Apple's sandbox policy engine each refined the same idea until it became the substrate of everything from Docker containers to Chrome's renderer processes.

The mechanics and coverage differ. The Linux kernel's seccomp documentation says that system-call filtering is not a sandbox by itself and should be combined with other hardening and information-flow controls. Namespaces isolate selected kernel resources, Landlock restricts declared access to kernel objects, and a virtual machine introduces a separate kernel boundary.

For this guide, a production-grade agent sandbox should provide three properties across every resource it claims to mediate:

• Deny-by-default within the declared surface. Files, sockets, devices, system calls, and other resources covered by the policy are denied unless granted. The design must also state what is not mediated.
• Enforced outside the agent's trust boundary. The operating system, hypervisor, or unavoidable gateway applies the restriction. The model cannot disable it through a prompt or tool call.
• Confinement that survives process creation. Restrictions must remain effective across threads, child processes, and execution of new programs. The exact inheritance behavior depends on the mechanism and configuration. Landlock, for example, applies a thread's domain restrictions to its descendants.

These properties are why we sandbox untrusted code at all, and they transfer almost perfectly to agents: an LLM-driven process is, from the kernel's perspective, just another program whose future behavior nobody can predict.

What a conventional sandbox generally does not do

If every individual action was authorized, why was the outcome unauthorized?

Because conventional containment judges operations, while risk often lives in sequences. A syscall- or resource-oriented policy usually evaluates the current operation against resource rules, not against the semantic task or accumulated trajectory. Stateful reference monitors, information-flow systems, and mediated egress gateways can enforce sequence-sensitive policies. Amazon Bedrock AgentCore's Dogwood, for example, extends Cedar with temporal operators over earlier session events.

Two consequences follow, and they define the rest of this guide.

First, composition blindness in static resource policy. Read-the-workspace plus outbound network creates an exfiltration path, while neither grant looks dangerous alone. Without stateful provenance, data-flow tracking, or mediated egress, the policy cannot distinguish an expected upload from one containing data read earlier from a sensitive source.

Second, the secrets problem. Containment bounds where a process can reach, not what it can hand over. If a credential lives inside the sandbox, whether in an environment variable, a config file, or a logged trace, the contained process can leak it into logs, model context, or a crafted tool response. The fence is intact; the asset was already inside.

Sandboxing is necessary. It is not sufficient for an agent that can exercise authority in external systems. That raises the obvious question: sufficient for what? To answer it, we need to walk through the same evolution this industry did, one architecture at a time.

Part II: What does a layered AI agent security architecture look like?

A layered AI agent security architecture separates four concerns: ambient access, process containment, delegated authority, and runtime judgment. Each stage removes a different failure mode, but each also leaves a gap the next stage must close. The target is not perfect safety; it is bounded failures, attributable actions, and systems that survive compromise.

Stage 0: The Convenient Default of Long-Lived Credentials

The naive architecture gives one agent process standing credentials and direct access to every system it may need. It is attractive because setup is nearly free. It is dangerous because credential scope becomes blast radius, actions have no delegation chain, and secrets can leak through every place the process sends data.

Figure 1. The default deployment: long-lived secrets in environment variables, unrestricted execution, and no trustworthy delegation trail.

The simplest approach is no approach: generate tokens, paste them into configuration files and environment variables, and let the agent run with them. This requires essentially zero setup, and it dominates prototyping and early deployments for that reason. For local development on a machine you fully control, it is genuinely hard to beat.

The tradeoffs are serious:

• Blast radius tracks credential scope and lifetime. One prompt injection in a poisoned README or malicious issue comment can expose a year-long ghp_ token. Not for minutes. Until someone notices or the token is revoked.
• No trustworthy delegation trail. Provider logs may show that a token performed an action, but not which user instruction, agent instance, session, or authorization decision caused it.
• Secrets leak sideways. Environment variables end up in crash dumps, CI logs, and model contexts. LLMs are spectacular at faithfully reproducing whatever they were handed.

Use Stage 0 only for prototyping and demos. The convenience today is not worth the liability tomorrow.

Stage 1: Add Containment

Containment replaces ambient machine access with explicit enforcement boundaries over selected resources. It is the non-negotiable floor for running an AI agent against untrusted content. But it does not remove secrets the process may still read, and a static resource configuration usually evaluates file, network, and execution grants independently rather than as a sequence.

Figure 2. The sandbox bounds what the agent can reach across the resources it mediates. Static resource policy does not ordinarily see dangerous sequences, and standing credentials remain inside the process.

The first real fix most teams reach for is to run the agent in a deny-by-default environment where access to each mediated path, socket, device, and system call must be granted explicitly.

✓ ./workspace        ✓ private TMPDIR       ✓ execute
✗ ~/.ssh             ✗ Keychain             ? network (granted, necessarily)

Within the mediated surface, this is a genuine upgrade: bounded reach the model cannot argue with, enforced across helpful, confused, and compromised states alike. If you take one action from this guide, take this one.

But recall the two structural gaps from Part I, because both survive the upgrade:

• Composition blindness. My probe from the introduction ran in precisely this architecture. Every check passed. The exfiltration path existed anyway. Static allowlists do not reason over trajectories. A data-flow-aware egress monitor could catch the sequence, but that is additional machinery beyond the resource sandbox itself.
• The token moved inside the fence. Containment without credential hygiene means your most valuable secret now sits in the one place the compromised process definitely can read.

Required building blocks: enforcement outside the agent's trust boundary, explicit grants for every mediated resource class, and confinement that survives child-process creation. On Linux, this commonly combines namespaces and seccomp with filesystem controls such as Landlock and separate network or egress policy. Seccomp and namespaces alone do not automatically provide complete filesystem and network mediation. Anything enforced only inside the agent's own process is a guardrail the compromised process may be able to bypass.

Stage 2: Move Authority Out of the Process

A credential broker removes upstream standing secrets from the agent and issues or exercises short-lived, scoped authority. This reduces breach value and can create a delegation trail. It does not eliminate replay of issued bearer tokens, continued issuance to a compromised workload, or the need to judge whether an authorized action fits the session's trajectory.

Figure 3. The agent keeps no upstream standing secrets. A broker issues short-lived, scoped credentials through an identity-aware proxy. Effective authority still depends on token binding, issuance policy, and enforcement at the resource or gateway.

If the agent must never hold standing secrets, who holds them? Move issuance out-of-band. A credential broker sits between the agent and your identity infrastructure. The agent never receives a long-lived GITHUB_TOKEN; it either receives a short-lived credential or exercises authority through an identity-aware proxy.

One concrete implementation of the proxy half of this pattern is iron-proxy, an open-source egress proxy that defaults to deny, injects real credentials at the boundary, and emits per-request audit logs. It can keep upstream secrets out of the sandbox, but it is not a complete credential broker or behavioral authorization layer. Its documentation also makes the enforcement caveat explicit: DNS-only routing is easy to bypass, so production deployments need an egress firewall or transparent interception that makes the proxy unavoidable.

Calling a grant "per operation" is accurate only when an unavoidable gateway or resource server binds it to the relevant actor, subject, audience, resource, action, parameters or request digest, expiry, nonce, and, where possible, a sender key. A short lifetime and OAuth scope do not create that binding by themselves. Rich authorization details, sender-constrained tokens, and signed HTTP request components address different parts of the problem.

Agent:    "Act for user X on repo Y, for this operation."
Broker:   verifies workload identity and delegation → checks issuance policy
Resource: verifies the broker identity and any operation binding

Done well, this changes three things:

• Breach value is reduced and bounded. Exposure is limited by the lifetime and scope of issued credentials and by what the broker will continue issuing. If the compromised workload can still authenticate, its effective blast radius includes every grant the broker will still issue to that identity.
• Delegation evidence becomes possible. Resources or unavoidable gateways can record which agent acted for which user under which grant, provided those identities and requests are bound to the action.
• Revocation becomes centralized. The broker can stop new issuance or invalidate a delegated session. A self-contained credential already issued may remain usable until expiry unless the resource supports revocation.

None of this machinery is exotic. It applies familiar workload-identity patterns to a new caller type: OpenID Connect, SPIFFE-style identities, and private-key JWT client authentication. But token format matters. SPIFFE warns that JWT-SVIDs are bearer tokens susceptible to replay and recommends aggressive expiry and narrow audiences. Sender-constrained credentials are preferable where the resource supports them. We cover the broader product pattern in our guide to credential brokering for AI agents.

Standing secrets are gone. Why does the curl problem survive?

A conventional broker usually evaluates identity, delegation, resource, scope, and issuance policy. Unless trusted session context is explicitly supplied, it cannot determine whether the requested operation fits the trajectory. A broker can receive that context or consult an external policy decision point, but then it has become part of the runtime authorization path rather than a credential issuer alone. Even a freshly minted, operation-bound grant can authorize the second half of a read-then-upload sequence if the decision never considers what the session read first.

Required building blocks: workload identity federation; explicit continuing-issuance policy; short-lived, minimally scoped and preferably sender-constrained credentials; and an unavoidable gateway or resource server that verifies the delegation and any operation binding. OAuth token exchange can carry delegation or impersonation semantics, but the resource still has to enforce the relevant request constraints.

Stage 3: Put Behavioral Authorization in the Loop

Behavioral authorization evaluates each proposed tool call before execution using the task, identity, delegated authority, parameters, and accumulated session history. Deterministic rules can enforce hard limits. Semantic evaluation can contribute a fallible risk signal. Together they can allow, deny, narrow, or defer an action to a human, then preserve evidence for incident reconstruction.

Figure 4. The behavioral control plane evaluates each proposed action against session context before execution and records the decision in a separately protected audit trail.

Phil Venables framed the remaining gap better than anyone: traditional IAM does not reason over accumulated session state, while SIEM generally observes rather than intercepts.

Given everything this agent has done in this session, should this next action be permitted?

The final layer asks that question before every mediated tool call. OWASP recommends complete mediation at downstream systems rather than relying on the LLM to decide whether an action is allowed. Any bypass path is outside the control's guarantees.

The OpenAI and Hugging Face incident also widens the scope of accumulated context. A decision surface may need to correlate actions across agents, sessions, identities, and shared services because a fleet can compose a dangerous trajectory that no single session reveals.

The loop is simple to state: intercept before execution; accumulate context across calls; decide allow, deny, narrow, or defer to a human; record authenticated evidence of the proposal, decision, executed request, and observed result. Store those records in a separately protected, tamper-evident system. NIST AU-9 requires protection of audit information and logging tools from unauthorized access, modification, and deletion; append-only application logging alone does not satisfy that requirement.

In the same incident, METR found clear evidence of spoofed tool calls in at least 96 transcripts and extensive attempts to tamper with trajectory evidence. A transcript produced inside an agent-controlled execution path is therefore evidence to authenticate, not a source of truth to trust by default.

There are two different controls inside this layer. Deterministic authorization evaluates predicates such as resource, operation, destination, amount, rate, provenance label, approval state, and delegation. Those predicates can enforce hard invariants when they run at a non-bypassable chokepoint. Semantic evaluation estimates whether an action fits a natural-language task or looks suspicious in context. It is probabilistic and may itself receive adversarial context. Use it to deny, escalate, or narrow authority, but reserve unconditional guarantees for deterministic predicates.

The authorization decision must also be bound to execution. Evaluate a canonical representation of the action, bind the decision to the exact security-relevant fields, and have the execution boundary reject any mismatch. Otherwise the system can approve one tool call and execute another through a time-of-check/time-of-use or canonicalization gap. HTTP Message Signatures illustrate why covered components and canonicalization have to be explicit.

Two design principles separate working systems from dashboard theater:

Prefer invariants and survivability over perfect approval. High-frequency trading put non-deterministic actors at machine speed decades ago without trying to approve every trade. Markets work through position limits, kill switches, circuit breakers, and mandatory reconstruction: deterministic bounds no participant can cross, clean halts, and evidence that supports incident reconstruction. You will not authorize every agent action correctly. Design for bounded failure: some rules hold regardless of context, sessions halt cleanly, and investigators can reconstruct observed decisions and effects even when the model's exact internal execution is not reproducible.

Fail secure, and keep humans on the loop, not in it. Human-in-the-loop review for every action dies at scale. That is exactly how the industry talked itself into dangerously_skip_permissions. Human-on-the-loop supervision survives because operators have real tooling and the authority to intervene, while step-up approval remains reserved for high-risk classes. If authorization cannot be completed, the system must not initiate a new privileged effect. It should enter a defined safe state, preserve evidence, avoid uncontrolled retries, and provide explicit recovery or human escalation. NIST defines fail secure as preserving the secure state when failure occurs, not as terminating every system function.

Required building blocks: complete mediation at the tool, gateway, or resource boundary; session-level and, where shared resources create cross-agent risk, fleet-level state accumulation; deterministic policy plus separately identified semantic risk signals; decision-to-execution binding; a separately protected, tamper-evident audit system; kill switches; and hard invariants.

Part III: Which security layer covers each AI agent failure mode?

No layer protects against every AI agent failure mode. Sandboxes can prevent access outside the resource boundary they actually mediate. Credential brokers remove upstream standing secrets and constrain issued authority. Runtime authorization can prevent deterministic policy violations and detect or escalate semantic risk when every relevant path is mediated. The layers become more useful together because later decisions depend on trustworthy identity, context, provenance, and instrumentation.

Security outcomes for sandboxing, brokered credentials, and behavioral authorization.

Legend: Prevent: Stops the outcome · Constrain: Limits scope or impact · Detect: Flags suspicious activity · Recover: Preserves evidence or restoration · Not addressed: Outside this control

The layers are not independent purchases. Runtime decisions become stronger when they consume a delegation chain from the broker and telemetry collected outside the agent boundary. A sandbox alone does not guarantee instrumentation integrity; the control plane must prevent bypass or tampering, and the audit system must be protected separately. Stack the layers so each one can verify the claims it consumes.

Part IV: How should you secure an AI agent in practice?

The practical implementation order is containment first, standing-secret removal second, and contextual pre-execution decisions third. Start with telemetry before complex policy so you can observe real agent trajectories. Then test expiry, denial loops, authorization failures, and unfamiliar resource access with the same rigor applied to other production security controls.

Inventory compositions, not permissions

List every grant your agents hold, including files, sockets, and tokens. Then ask the question nobody asks: what do these permissions do together? Read-the-repo plus network was always an exfiltration path; nobody had enumerated it because we audit permissions one at a time.

Get standing secrets out first

Nothing else on this list matters much while a year-old token sits in an environment variable. Broker credentials before you build anything clever on top. Then define what the broker may continue issuing after workload compromise, prefer sender-constrained credentials where possible, and make delegation evidence available to the runtime decision point.

Put a decision inside the loop, even a crude one

Log every tool call with session context before you gate anything; telemetry-first beats policy-first because you cannot write rules for sequences you've never seen. Then gate the obviously dangerous classes: bulk reads followed by egress, credential-shaped writes, and anything touching payment or deletion flows. Our guide to securing LLM tool use with runtime policies goes deeper on that enforcement boundary.

Demand telemetry like you demand SOC 2

Test what happens when a token expires mid-operation; a denied action is retried in a loop; the decision engine is unavailable; an authorized request changes before execution; or an agent touches a resource class it hasn't used before. If authorization is unavailable, do not initiate a new privileged effect. Enter a defined safe state, preserve evidence, and make recovery explicit. If an agent platform cannot show the proposed request, decision, executed request, and observed result, it is not ready for anything you would defend in an incident review.

Common questions about securing AI agents

Securing an AI agent requires several controls because no single boundary governs process access, delegated authority, network egress, and multi-step behavior at once. The questions below clarify where the layers overlap and where they do not. Each answer assumes the named control is deployed at an unavoidable enforcement point.

Is a sandbox enough to secure an AI agent?

No. A sandbox constrains the resources and system operations it mediates, which is essential for containment. It does not automatically remove readable credentials, prevent misuse of allowed network access, or judge whether a sequence of individually permitted actions fits the user's task. Those gaps require credential and runtime authorization controls.

Can an egress proxy replace runtime authorization?

No. An enforced egress proxy can restrict destinations, inject credentials outside the sandbox, and record network requests. It does not automatically determine whether an allowed request serves the user's task or whether earlier actions make it dangerous. Runtime authorization still needs trusted session context, deterministic policy, and complete mediation of relevant actions.

Which AI agent security control should you implement first?

Start with containment and removal of standing secrets, then add enforced egress and pre-execution authorization. Log proposed and executed actions before writing complex trajectory policies. This order reduces immediate blast radius while producing the trustworthy identity, provenance, and session evidence that later behavioral decisions need.

Conclusion: What should secure AI agent architecture deliver?

AI agent security is not a single property. Containment controls where a process can reach across the resources it mediates. Identity infrastructure controls what authority it can prove. Runtime authorization enforces deterministic constraints and can use semantic risk signals when evaluating the next action. A survivable architecture stacks all three and states the assumptions behind every guarantee.

We started with a broken question: "is your agent secure?" It's broken because security for agents was never one property. Containment engineering answers where the process can reach. Identity infrastructure answers what authority it may prove. Conventional point-in-time controls do not by themselves answer the question agents force: given everything this process has done, should it do the next thing?

Getting there requires:

1. Containment: deny-by-default across declared resources, enforced outside the agent's trust boundary, with confinement that survives process creation.
2. Authority: upstream standing secrets brokered outside the process, with short-lived and preferably sender-constrained credentials plus explicit continuing-issuance policy.
3. Judgment: pre-execution decisions that separate deterministic invariants from probabilistic semantic risk, bind the decision to execution, and preserve protected evidence.
4. Honesty about limits: no layer, and no stack of layers, makes agents safe. Bounded failure, attribution, and survivability are outcomes the design must earn.

Sandboxing answers only one part of the security question. The sooner our architectures and conversations treat containment, authority, and judgment as separate concerns, the sooner agents stop being a security nightmare and start being infrastructure.

Want to try that architecture? Sandy gives coding agents a local process sandbox whose restrictions survive child-process creation, and it can require the Kontext integration for contextual pre-action authorization. Sandy 0.1.x is experimental and has not completed an independent security audit, so review its threat model before relying on it for sensitive workloads.

More on behavioral authorization for coding agents in an upcoming post.