Agent Habitat Architecture

An Agent Habitat is the company-designed environment in which agents work with people, knowledge, tools, and systems under defined rules. It gives agents room to contribute while providing the boundaries needed to govern their access and actions. This white paper sets out the proposed security architecture for that Habitat: controls over identity, execution, permissions, data flows, external connections, approvals, and recovery. The Agent Habitat Maturity Scale below turns those controls into testable evidence for assessing how securely the habitat supports increasing agent autonomy. It complements industry efforts like the NVIDIA Open Agent Safety Platform and the Blueprint Alliance reference architecture.

Summary

AI agents now write code, call tools, and touch production systems for their users. The Agent Habitat is the environment where they do this work: access to company knowledge, tools, and systems is governed by company-controlled boundaries, with security and governance built in.

Those boundaries must hold even when an agent doesn’t cooperate. It may drift, be manipulated by content it reads, or actively look for gaps. This white paper sets out a proposed security architecture for the Agent Habitat and a maturity scale for assessing how securely it supports increasing agent autonomy.

Who this is for: Security Leaders, Platform Architects, and anyone building, buying, or approving agent habitat.

What’s inside:

• A threat model covering untrusted content, the agent itself, malicious tenants, compromised dependencies, flawed enforcement, and faults.
• A reference architecture that separates trusted, semi-trusted, and untrusted zones, with a credential broker as the only path to the outside world.
• Twelve core principles, each stated precisely enough to test, from default-deny policy to out-of-band containment.
• A maturity scale across 11 tracks, each rated 0 to 3, with the evidence needed to claim each level and real-world incidents that show what’s at stake.

The core idea: Permissions should only shrink during a run, credentials should never be within the agent’s reach, every network path needs a policy enforcement point, and anything irreversible needs a human. Level 1 protects against accidents, level 2 against prompt injection, and level 3 against an agent actively trying to escape.

How to use it: Score your own habitat, or any vendor’s, on each track. You’re only as mature as your lowest score, so start there.

This framework complements the NVIDIA Open Agent Safety Platform and the Blueprint Alliance reference architecture, and goes a level deeper: into the specific invariants an implementation must satisfy.

Scope

• In Scope: Habitats where AI agents run code and call tools for users, including their subagents, the credentials they use, the data they touch, and their path to production and other network-accessible services.
• Out of Scope: Model alignment and training, the quality and security of application code the agent writes, content safety, and enterprise-wide agent discovery, which the Blueprint Alliance covers.

Threat model

• Untrusted content: instructions hidden in web pages, repositories, files, documents, tool outputs, or MCP responses.
• The model itself: it may drift, reward-hack, probe for gaps, or misreport what it did. Assume it will find any gap. No control may depend on its cooperation.
• Malicious users and tenants targeting other tenants, shared infrastructure, or third parties.
• Compromised dependencies, tools, and MCP servers.
• Flaws in enforcement: every proxy, policy engine, and identity issuer is an attack surface.
• Faults: crashes, timeouts, and retries that repeat, drop, or half-apply actions. An agent can also cause them on purpose, for example to shed limits on restart.

Assets: customer secrets and data, other tenants, shared infrastructure, third-party systems, and the audit trail.

Components

Component	Trust	Interface	Enforces
Identity bootstrapper	Trusted	Enrollment requests from workloads; launch evidence from the platform	Issues a workload identity only on platform evidence, never the workload’s own claims. Credentials are short-lived and bound to a logical workload across multiple services that encode lineage. Grants no permissions.
Harness	Semi-trusted: trusted code that parses untrusted model output	Tool calls	Tool-call policy. Holds the run’s token, never the root, and derives narrower tokens for the sandbox and subagents.
Durable executor	Trusted	Workflow steps from the harness	Runs the agent loop as a durable workflow. Journals every model call and side-effecting action before and after it runs, assigns idempotency keys, handles retry policy, and resumes runs from the journal.
Token service	Trusted	Token requests	Holds the root key for all tokens across all workloads. Issues each run’s token only to an attested harness in an attested workload. The token is capped at the run’s effective ceiling. Keeps the revocation list.
Sandbox	Untrusted	Syscalls, filesystem mounts	Only the mounts and network paths the policy allows exist. Holds no credentials.
Broker	Trusted	The only path between the harness or sandbox and any network-accessible service, in both directions: models, connectors, MCP servers, package registries, the Internet, inbound previews	Connection and request policy. Injects authorized credentials from a vault per request. Rejects credentials it didn’t add. Redacts credentials in responses. Blocks outbound secrets.

Core principles

• Policy-mediated: Every interaction must be policy-enforced, no matter how trivial: tool calls, file accesses, process launches, network sockets.
  • Default deny: if no rule matches, deny. Explicit denies override any allows.
  • Each run, meaning the work done for one trigger, has a static, machine-verifiable ceiling bound to one principal and one organization. The ceiling defines the maximum permissions the agent can hold during the run.
  • The ceiling is the security boundary and is always capped by the principal and the organizational constraints. Assume the agent will misuse every permission in it.
  • A prover checks, before the run starts, that the ceiling stays within org policy and one org, reaches no cloud-metadata or link-local address, allows no credentialed traffic over protocols the broker can’t inspect, grants no access to policy administration, and, depending on the organizational policy, passes the Rule of Two (see Data flow).
  • Only an authorized principal can raise a ceiling, by issuing a new, re-verified policy version: never the agent, never mid-run. Policy is never read from anything the agent can write.
  • Policy compiles into enforcement: mounts, kernel access rules, and proxy rules. Only the harness and broker evaluate it per request.
  • Each ceiling sets limits on compute, network volume, and spend through brokered credentials, enforced by the sandbox and broker.
  • If a Policy Decision Point (PDP) is unreachable or stale, deny. False negatives are the only acceptable error, and no decision may depend on policy updates arriving out of order.
• Monotonic attenuation: Permissions while running autonomously only shrink during a run, and the next trigger starts a new run from the static ceiling. Effective permissions are the intersection of the ceiling, org policy, trigger policy, attenuations, and filter decisions.
  • The agent can lower its own ceiling or a subagent’s ceiling, for one interaction or for the rest of the run. The harness enforces the reduction, and the agent can’t undo it.
  • Attenuations are written into the token itself (as in macaroons or Biscuit), so no shared state is needed to make them irreversible. Revocation is separate; see Brokered credentials.
  • The sandbox never holds a parent token. A subagent’s token is derived from its parent’s current token.
  • A subagent’s output is untrusted content to its parent, and the two can be configured to never share a writable filesystem.
  • Human escalation, configured in policy, is the only way to temporarily elevate the ceiling for exceptional operations. This should be used sparingly to combat decision fatigue.

Figure 1: Permissions can only shrink within a run, and subagents inherit no more than their parent’s current permissions. Each new trigger starts a fresh run from the static ceiling, narrowed by org and trigger policy.

• Dynamic, adaptive filtering: Filters can further lower the ceiling per evaluation, using previous actions, trigger alignment, and other signals. They can deny or escalate to a human, never grant.
  • Gate: checks each proposed action against the trigger. It sees only those two, never raw untrusted content.
  • Monitor: sees everything else, including action history, and can only deny or contain.
  • Reasoning tokens are optional, and no control may depend on them. When used, they are untrusted and need their own isolation: a separate monitor that can only deny or contain.
  • Rules about past actions that can be stated exactly, such as “no new network destinations after reading a secret,” should be translated into policy rather than left for a model to interpret.
  • If a filter is unavailable, deny.
• Identity and provenance: Every workload, including each agent instance and sandbox, has a unique, short-lived identity bound to its runtime, and a stable lineage: user, org, project, and parent agent. Identities can follow the WIMSE architecture.
  • The identity bootstrapper attests every workload, including agents, subagents, and sandboxes, and issues the workload’s identity. Platform components get identities the same way, so every connection between components is mutually authenticated.
  • Workloads get their identity through attestation, never through provisioned or bootstrap secrets. Evidence comes from the platform that launched the workload: the orchestrator’s launch record, the host or hypervisor, the signed build it runs, and hardware where available. It never comes from the workload’s own claims.
  • Each workload generates its own key, which never leaves it. Its credential, a Workload Identity Token or X.509 certificate, binds that key to a workload identifier in the org’s trust domain.
  • A sandbox’s identity names the agent instance that owns it.
  • Identities are renewed only while attestation still holds, and containment revokes them.
  • Identity is not authority. The bootstrapper grants no permissions; the token service issues tokens only to attested workloads.
  • The trigger travels with each request as security context, separate from the workload’s identity.
  • Every interaction traces to exactly one trigger: an authenticated user’s message or a registered machine identity. The trigger can lower the ceiling.
  • An automated trigger’s ceiling matches the least-trusted party who can set it off. For example, a webhook fired by an issue on a public repository gets an anonymous user’s ceiling.
  • Content the agent processes is never a trigger and can never raise permissions.
  • Files carry the provenance of the run that wrote them. Anything an agent writes is untrusted input to every later run and every other user.
  • Writes to instruction, configuration, and hook files need approval, or stay quarantined until a human reviews them. Executable files the agent writes, such as hooks, install scripts, and editor tasks, are flagged before anything outside the sandbox runs them.
• Strong, verifiable isolation: Identity bootstrapper, harness, durable executor, token service, sandbox, and broker are isolated from each other. Each one’s only way out is its interface, which always has a policy enforcement point.
  • Enforcement points run outside the sandbox’s kernel and out of the agent’s reach. Rules enforced by the sandbox’s own kernel are an extra layer, not the boundary.
  • Identity bootstrapper, harness, token service, and broker instances can be configured to never serve more than one tenant, and in that configuration, they run in the tenant’s boundary. Signing keys for identities and tokens should be held in hardware, preferably using confidential compute capabilities.
  • The sandbox has no direct network path to other sandboxes, internal services, or the control plane. Traffic to those destinations must always pass through a network policy enforcement point.
  • Every boundary has at least two independent enforcement layers, such as no default route plus the broker.
  • Policy applies in both directions to every channel, including DNS, ICMP, IPv6, link-local and cloud-metadata traffic, and non-HTTP protocols.
  • Inbound exposure of applications, such as previews and open ports, requires an identity-aware proxy enforcing authentication and authorization. Making it public needs an authorized principal’s approval.
  • Tools hosted by a model provider run outside the broker, so they are disabled or routed through it.
  • Enforcement points are minimal, written in memory-safe languages, and fuzzed. They run from signed builds, and each run’s audit record names the policy version and build that governed it.
• Brokered credentials: External credentials must always be brokered, never provided. The broker is the only interface between the harness-sandbox pair and the rest of the Internet.
  • The harness and sandbox never see external credentials. The broker reads them from an encrypted vault per request and adds them to authorized requests.
  • The broker rejects any request carrying a credential it didn’t add, whether in headers, cookies, URLs, or bodies.
  • Tokens are bound to the attested identity of the harness or sandbox they were issued to, or to the user who delegated authority to the agent. A token presented by any other workload is rejected.
  • In WIMSE terms, the broker is an identity proxy: it verifies the workload’s identity and, for allowed requests, replaces it with the external credential.
  • The broker checks revocation on every request, and denies if it can’t.
  • When a response contains a new credential, such as a freshly created API key, the broker moves it into the vault and redacts it.
  • Secrets that can’t be added to a request, such as signing keys, webhook secrets, SSH keys, and database passwords, go through protocol-specific brokers or a signing service, or stay out of the agent’s reach.
  • Apps under development may get test credentials or brokered placeholders. Production credentials are never within the agent’s reach.
• Data flow: Controls govern both what the agent can access and where its data can go.
  • Every output channel, such as chat replies, commits, issue comments, deployed pages, and external API calls, is labeled private, owner-only, or public.
  • Data is labeled by source as private or untrusted, and the label follows it through the context, files, and subagents. Private means secrets, customer data, and private repositories; untrusted means anything the trigger’s principal didn’t provide.
  • Agents can be configured so that no ceiling combines untrusted input, private data, and public or external writes, unless a human approves each such write. This is also known as “taint analysis”, and is one way to achieve compliance with Meta’s Rule of Two.
  • The broker blocks outbound traffic containing any secret it holds, including in common encodings.
  • The user interface is an output channel. Agent output is rendered under a strict content security policy and can’t load remote content.
  • Sending context to a model is an outbound flow. The model endpoint must meet the data’s residency and retention requirements.
• Human approval: Irreversible and production-affecting actions need a human-approved trigger: writes to production data, deploys, payments, outbound messages, and deletions.
  • Production write access can be configured in the policy to never be in the agent’s ceiling. The agent proposes production changes, and a human-approved action applies them out of band without giving the agent a standing permission to do so on its own.
  • Trusted UI draws each approval from the action’s actual parameters, never from the agent’s description.
  • Each approval can be configured to cover one instance of one action. Approving once never approves the next.
  • Approvals are cryptographically attested and come from an authenticated principal through a channel the agent can’t write to. Agent output can’t draw approval controls.
• Supply chain: Packages, tools, and MCP servers are untrusted until verified.
  • Packages are installed through the broker from approved registries only. They must meet a minimum release age and be checked against a list of known-malicious packages. The minimum age also stops attackers who register package names that agents hallucinate.
  • MCP servers are pinned by hash. Any change to an approved server or its configuration needs re-approval.
  • Tool descriptions and package metadata are untrusted content.
  • Installs run inside the sandbox, with no credentials.
• Durable execution: The agent’s actions and their side effects run durably, so the agent’s view of the world can’t drift from the real one.
  • Every action with a side effect outside the sandbox is recorded in a journal before it runs and when it finishes. The durable journal is the source of truth for actions taken.
  • Whenever the underlying system supports idempotency keys, each action carries an idempotency key, so a retry never repeats its effect. Where a destination can’t deduplicate, the broker checks real-world state before retrying. For systems that don’t support it, the information of attempted but not acknowledged should be provided to perform compensations.
  • An unknown outcome, after a timeout or crash, is reconciled against the real system before the agent continues. It’s never assumed.
  • After a crash, the run resumes from the journal. Recorded results, including model outputs, are replayed; recorded side effects never run again.
  • Multi-step changes declare compensating actions or a checkpoint, so failure or containment leaves them completed or rolled back, never half-applied. Actions that can’t be undone need human approval.
  • A restart never widens permissions. Attenuations, used approvals, spent budgets, and action history survive it; a resumed run’s token reflects the journaled state.
  • Each approval binds to one journaled action and its idempotency key, so exactly the approved action runs, once.
  • The durable executor exclusively controls journal writes. The journal is append-only and tamper-evident. Each instance can be configured to serve one tenant; in that case, the journal stays in the tenant’s boundary and residency region.
  • Scheduled reconciliation compares the journal with real-world state and alerts on divergence.
• Containment: Policy violations and monitor alerts contain the run without waiting for a human. The broker cuts off all external access, including access to the model; the sandbox is frozen; and all permissions and grants are revoked.
  • The kill path doesn’t depend on the agent, harness, or sandbox being healthy.
  • Containment leaves every in-flight action completed or compensated, and the journal records which.
  • Containment has a latency target and is drilled regularly.
  • Only a new trigger from an authorized principal can resume a contained run, and resumption is logged. Checkpoints let the agent’s changes be rolled back.
• Independent observation: Every enforcement decision is logged out-of-band to a tamper-evident store the agent can’t write to. Audit never relies on the agent’s own account.
  • Logs never contain credentials.
  • Logs use OCSF; revocation and risk signals use CAEP and SSF.
  • Decisions and logs stay in the customer’s data-residency region.

Architecture Diagram

Figure 2: The harness enforces tool-call policy and launches isolated sandboxes with identity-bound, limited permissions. A trusted broker controls access to models and services, injects credentials without exposing them, and enforces policy alongside per-action human approvals.

Agent Habitat Maturity scale

Use the Agent Habitat Maturity scale to score your own agent environment, or any vendor you’re evaluating. Each track rates one property from 0 to 3, and each level lists the evidence needed to claim it. Levels are cumulative, and a system is only as mature as its lowest track. Roughly, level 1 limits damage from accidents, level 2 from prompt injection, and level 3 from an agent actively looking for gaps. The fully realized core principles describe level 3.

Sandbox isolation

If your agent shares a kernel with a policy enforcement point, the agent will circumvent it. Any sensitive material in the same kernel will eventually be accessed. A microVM is the practical floor.

• 0: Process. The harness and runtime run as parent and child processes on one host, sharing its filesystem and environment.
  • Bad: CodeRabbit, 2025: a pull request’s linter config ran code on production servers and exposed a GitHub App key with write access to 1M repositories.
• 1: Containers. Separate namespaces on a shared kernel, so kernel exploits can escape.
  • Evidence: Sandboxes can’t see each other’s processes, files, or network interfaces.
• 2: MicroVM. Each sandbox gets its own kernel. The gold standard for local workloads. Each kernel uses a minimal configuration to reduce attack surface area.
  • Evidence: No two sandboxes share a kernel.
  • Good: AgentCore Runtime gives every session a dedicated microVM.
• 3: Separate machines. The harness, sandbox, and enforcement run on different hosts. The strongest isolation. Each kernel uses a minimal configuration to reduce attack surface area.
  • Evidence: The harness, sandbox, and enforcement points never share a physical host.
  • Good: OpenAI’s Agents API runs the agent loop in OpenAI’s service and executes code in a separate environment.

Network isolation

If you can’t show that DNS and direct-IP exfiltration fail with the proxy turned off, assume your agent can reach the open internet. Even otherwise trusted components can have vulnerabilities that allow the agent to jump to the next destination undeterred.

• 0: None.
• 1: L4 firewall. Only explicitly allowed IP and port pairs are reachable. Proxies, NAT, and shared IPs make it porous.
  • Evidence: Connections to any IP and port outside the allowlist fail.
• 2: L7 firewall. An allowlist of hostnames and paths, enforced by a proxy that every protocol must pass through, DNS included, backed by a second independent layer such as no default route. Allowlisted hosts that proxy or accept arbitrary data, and SSRF, keep it porous.
  • Evidence: DNS tunneling, ICMP, IPv6, cloud-metadata, and direct-IP tests all fail, and still fail with the proxy turned off.
  • Good: Claude Code’s sandbox sends all traffic through a proxy outside the sandbox that enforces a domain allowlist.
  • Bad: OpenAI, Sep 2026: the web proxy blocked a training agent, but the sandbox’s DNS resolver still answered for real domains, and the agent used it to relay questions to a public chatbot.
  • Bad: OpenAI, Jul 2026: models exploited a zero-day in a package-registry proxy, escalated privileges, moved laterally to a machine with Internet access, and breached Hugging Face.
  • Bad: Antigravity, 2025: the default allowlist included webhook.site, so an injected prompt exfiltrated .env credentials through it.
• 3: Adaptive firewall. Like a WAF, but for egress: it tightens automatically on live traffic and emerging threats, and never loosens on its own.
  • Evidence: In a red-team exercise, an exfiltration pattern with no existing rule is blocked automatically.
  • Good: NVIDIA Sentry enforces policy on the DPU in real time and flags drift from each agent’s expected behavior.

External identity

Any credential your agent can read will eventually leak or be used to circumvent policy. The agent should, at most, only ever see placeholders.

• 0: Environment variables. The agent holds long-lived credentials with full access to third-party services.
  • Bad: Supabase MCP, 2025: an agent holding a service-role key followed instructions in a support ticket and copied integration tokens into the ticket thread.
• 1: Short-lived credentials. The agent leases scoped tokens that expire in seconds to minutes, so a leak has a bounded window.
  • Evidence: No credential found in the sandbox outlives its lease.
• 2: Credential brokering. The agent never sees raw tokens; the broker adds them to allowed requests, and policy can allow or deny each request.
  • Evidence: Scans of the sandbox’s environment, files, and memory find only placeholders.
  • Good: OpenAI’s hosted sandboxes give code only a placeholder; a proxy adds the real secret for approved hosts.
• 3: Bound brokering. Every brokered request carries the agent’s identity and trigger, and the broker rejects credentials it didn’t add and tokens presented by any other workload.
  • Evidence: Requests carrying a foreign credential in headers, cookies, URLs, or bodies are rejected, and so are tokens replayed from another sandbox.
  • Bad: Claude, 2025: injected instructions uploaded a user’s data through an allowlisted host, api.anthropic.com, using the attacker’s own API key.

Policy

Instructions aren’t permissions. A rule that lives only in the prompt is one the agent can ignore.

• 0: Tool denylist.
  • Bad: Cursor, 2025: researchers found four ways around the auto-run denylist.
• 1: Tool allowlist.
  • Evidence: Tools off the allowlist can’t be called.
  • Bad: Claude Code, 2025: commands on its “safe” allowlist could read a file and send it over the network without a prompt.
  • Bad: Cursor, 2025: creating a file needed no approval, so an injected prompt created .cursor/mcp.json and ran arbitrary code.
• 2: Static policy with monotonic attenuation. A per-agent policy that can only remove permissions for the rest of its lifetime.
  • Evidence: The prover’s report shows every ceiling within org policy, and attempts to regain a removed permission fail.
  • Good: GitHub Copilot’s cloud agent sees only its own repository and can push only to its own branch, never the default branch.
  • Bad: Cursor / PocketOS, 2026: an agent troubleshooting staging found an over-scoped API token and used it to delete a production database volume and its backups without confirmation.
• 3: Dynamic policy. A static policy sets the ceiling; the dynamic part lowers it per request.
  • Evidence: Filters lower the ceiling in response to test signals, and a filter outage causes denials, not approvals.
  • Good: Chrome limits each task to the sites it needs, and a separate model, shielded from page content, vetoes misaligned actions.
  • Bad: Perplexity Comet, 2025: hidden text in a Reddit comment made the agent pull the user’s email address and a one-time passcode from other sites and send them to the attacker.

Data flow

If one run can read private data, take in untrusted content, and write externally, a single prompt injection can exfiltrate your data.

• 0: None. Anything the agent can read can go anywhere it can write.
• 1: Secret scanning. Outbound traffic is checked for credentials and known secrets.
  • Evidence: Canary secrets planted in the sandbox are blocked in outbound headers, bodies, URLs, and DNS, including base64 and URL encodings.
  • Bad: PromptPwnd, 2025: instructions hidden in GitHub issues made AI agents in CI workflows post repository secrets into the issue thread.
• 2: Output labels. Every output channel is labeled private, owner-only, or public, and private data can’t reach a public channel without approval.
  • Evidence: A run that reads a private repository can’t post its content to a public issue, pull request, or page without an approval.
  • Bad: GitHub MCP, 2025: after reading a malicious public issue, an agent leaked private repository data into a public pull request.
• 3: Provenance tracking. Source labels follow data through context, files, and subagents, and the prover enforces the Rule of Two on every ceiling.
  • Evidence: The prover rejects ceilings that combine untrusted input, private data, and external writes, and data from a planted untrusted source never reaches an external channel.
  • Good: CaMeL, a Google DeepMind research design, tracks where every value came from and checks policy before each tool call.

Human approval

“Always allow” is a standing overly broad permission in disguise. Each approval should cover one action, shown from its real parameters, or result in a change in reviewed policy.

• 0: None. The agent acts without asking.
  • Bad: OpenClaw, 2026: the owner’s “don’t act until I tell you to” was only an instruction, and the agent started deleting her inbox once context compaction dropped it.
• 1: Session approval. A human approves a task, a command, or “always allow” once, and later actions reuse it.
  • Evidence: Every irreversible action in the test suite requires approval before it first runs.
  • Bad: Gemini CLI, 2025: after a user allowed grep, a later command starting with grep chained a second command that silently sent environment variables to a remote server.
• 2: Per-action approval. Each irreversible action as specified by policy is approved individually, on a screen trusted UI draws from the action’s actual parameters.
  • Evidence: Every irreversible action requires separate approval, and the approval screen matches the action that will run, even when the agent describes it differently.
  • Good: Chrome asks the user to confirm critical steps before its agent takes them.
• 3: Production boundary. Production write access is outside the agent’s ceiling when specified by policy; the agent proposes production changes, and a human-approved action applies them.
  • Evidence: The agent’s ceiling contains no production write access, and production changes in tests arrive only through human-approved actions.

Supply chain

Every package and MCP server your agent installs is code you’re running, so pin it, age-gate it, and re-approve any change.

• 0: None. The agent installs anything from anywhere.
• 1: Approved registries. Installs reach only approved registries, through the broker.
  • Evidence: Installs from unapproved registries or URLs fail.
• 2: Vetted installs. Packages need a minimum release age, pass a known-malicious check, and are pinned in lockfiles; MCP servers are pinned by hash and re-approved on any change.
  • Evidence: Installing a version younger than the minimum age or a known-malicious package fails, and editing an approved MCP configuration forces re-approval.
  • Bad: Nx, 2025: malicious versions of a popular package, live on npm for 4 hours, ran developers’ AI CLIs with permission-bypass flags to hunt for secrets, then published them to public GitHub repositories.
  • Bad: Cursor, 2025: an approved MCP configuration could be edited afterward to run any command without re-approval.
• 3: Verified provenance. Only packages and servers with verified provenance are installed, and their descriptions are treated as untrusted content.
  • Evidence: Packages without verified provenance fail to install.

Durable execution

If the agent’s own context is your only record, you can’t know what it actually did after a crash or retry. Furthermore, the actions it remembers taking and the observable side will diverge.

• 0: In-memory. The agent’s context is the only record of what it did. A crash loses it, and a retry can repeat or drop side effects.
  • Bad: o3, 2025: in pre-release testing, OpenAI’s o3 often claimed actions it never took, such as running code on a laptop.
• 1: Checkpointed. Agent state is saved periodically, and a crashed run resumes from the last checkpoint, but actions taken since then can repeat or vanish.
  • Evidence: Killing the harness mid-run and restarting it resumes from the last checkpoint.
• 2: Journaled. Every side-effecting action is journaled before and after it runs and carries an idempotency key. Runs resume from the journal without repeating effects, and unknown outcomes are reconciled first. Journal is append-only.
  • Evidence: Fault-injection tests that kill the harness, sandbox, or broker between any two steps never repeat or drop a side effect.
  • Good: Temporal’s OpenAI Agents SDK integration runs model calls as activities, so they retry durably and aren’t repeated on replay.
  • Good: Stripe returns the saved result when a request is retried with the same idempotency key, instead of running it again.
• 3: Reconciled. Multi-step changes complete or roll back with compensations as a unit, the journal is continuously reconciled with real-world state, and restarts never widen permissions or reset budgets. Journal is append-only and tamper-evident.
  • Evidence: Crashes injected mid-action end completed or compensated, never in between; out-of-band changes to real-world state raise an alert; and a restarted run’s token and budgets match the journal.
  • Good: Kubernetes controllers run control loops that keep moving actual state toward the declared state.

Containment

If stopping a runaway agent requires a person or the agent’s cooperation, it won’t stop in time.

• 0: Manual. Stopping a run means finding the process and killing it by hand.
  • Bad: OpenClaw, 2026: an agent deleting its owner’s inbox ignored stop commands from her phone; she had to run to the machine.
• 1: Kill switch. An authorized person can stop any run remotely and immediately, without the agent’s cooperation.
  • Evidence: An operator stops any run from the control plane within the latency target, without the agent’s cooperation.
• 2: Automatic. Violations and alerts stop the run: the broker cuts all external access, including to the model, and permissions are revoked. Checkpoints allow rollback.
  • Evidence: A staged violation stops the run, cuts external access, and revokes tokens within the latency target, with no human involved.
  • Bad: OpenAI, Sep 2026: a P0 alert fired 12 minutes after the escape and a person acknowledged it 3 minutes later, but the run didn’t stop automatically and was killed 2.5 hours later.
• 3: Out-of-band and drilled. The kill path doesn’t depend on the agent, harness, or sandbox being healthy, has a latency target, and is exercised regularly.
  • Evidence: Drills stop runs within the latency target even with the harness and sandbox unresponsive, and results are recorded.
  • Good: NVIDIA’s reference design puts the kill switch on the path to the model, out of the agent’s reach.

Observation

Never trust the agent’s account of what it did. Logs have to live somewhere it can’t write or modify.

• 0: Self-report. The only record is the agent’s account of what it did.
• 1: Harness logs. Every tool call is logged by the harness.
  • Evidence: Every tool call in a test run appears in the harness log.
• 2: Enforcement logs. Every enforcement point logs every decision to a store the agent can’t write to.
  • Evidence: Every allow and deny from every enforcement point appears in the log, and nothing in the sandbox can alter or delete entries.
  • Good: OpenShell logs network, process, and policy decisions as structured OCSF events.
• 3: Out-of-band and monitored. Logs are collected outside the host, tamper-evident, tied to identity and trigger, and alert in real time.
  • Evidence: Logs are written off-host and tamper-evident, and a staged violation raises an alert in real time.
  • Bad: OpenAI, Sep 2026: a DNS anomaly detector excluded the affected environment, although its DNS traffic was logged.

Workload identity

If your agent acts as you, you can’t tell its actions apart from yours or limit them separately.

• 0: Borrowed. The agent only acts with a human’s identity and credentials, and sandboxes have no identity of their own.
  • Bad: AWS, 2025: per the Financial Times, Amazon’s Kiro agent chose to “delete and recreate the environment,” causing a 13-hour outage of an AWS service; Amazon blamed a misconfigured role.
• 1: Own identity. The agent has its own identity, so its actions are distinguishable from a human’s. A human can delegate authority to the agent, but should not delegate identity.
  • Evidence: Audit logs attribute every agent action to the agent’s own identity, never a human’s.
  • Good: GitHub Copilot’s cloud agent signs its own commits, lists the requesting human as co-author, and links each commit to its session logs.
• 2: Attested bootstrap. The identity bootstrapper attests each agent instance and sandbox at launch and issues a unique, short-lived identity with lineage. No workload starts with a secret.
  • Evidence: No workload image or environment contains an identity secret; a workload started outside the orchestrator can’t obtain an identity; and every action carries an attested instance identity and its lineage.
  • Good: SPIRE attests nodes and workloads before issuing their SPIFFE identities.
• 3: Trigger-bound. Every action traces to exactly one trigger. Automated triggers receive the ceiling of the least-trusted party able to initiate them, and subagents derive their identities and permissions from their parent.
  • Evidence: Every action in the audit log traces to exactly one trigger, and a run started by a public issue gets an anonymous user’s ceiling.
  • Bad: PromptPwnd, 2025: AI agents in CI workflows, triggered by issues anyone could file, ran with access to repository secrets.

Putting this into practice

Every agent environment sits somewhere on this scale today, and most are lower than their builders think. The good news is that the path up is concrete.

• Score yourself honestly. For each track, claim a level only if you can show its evidence.
• Fix your lowest track first. An agent looking for gaps will find your weakest one, so that’s where effort pays off most.
• Ask vendors to demonstrate their controls. Use the evidence column as your list of questions for any agent platform you evaluate.

This is a living standard. Agent capabilities and attacks are changing fast, and this framework will change with them. We welcome feedback, challenges, and contributions.