Attestation Is Not the Control Plane

Attestation and Provenance Are Evidence Mechanisms

The separation between authorization and evidence predates agentic AI.

The in-toto software-supply-chain framework requires a project owner to define a layout describing the steps in a supply chain and the functionaries authorized to perform them. When an authorized functionary performs a step, in-toto records the command and related artifacts in signed link metadata that can later be verified against the layout. Authorization is established in the expected process; the resulting metadata provides evidence about what occurred. [1]

SLSA uses a similarly bounded definition of provenance: verifiable information describing where, when, and how a software artifact was produced. Provenance makes production inspectable. It does not itself grant permission to perform the production step. [2]

That distinction matters for AI systems because richer agent telemetry can create the illusion that evidence and authority are interchangeable. They are not. A complete trace can show that an action occurred. A signed attestation can preserve facts about the process. A validation record can support an assurance claim. None of those artifacts retroactively creates permission for an action that was outside the authorized boundary.

Architecturally, attestation belongs on the evidence side of the system. It strengthens the record available for assurance. It does not replace the authority model governing execution.

Verification Uses Different Kinds of Mechanisms

Evidence is not one homogeneous class either.

Birgitta Böckeler’s harness-engineering model separates guides from sensors and computational mechanisms from inferential ones. Guides operate as feedforward controls intended to steer an agent before it acts; sensors provide feedback after action. Computational mechanisms such as tests, linters, type checkers, and structural analysis are deterministic. Inferential mechanisms such as semantic review and LLM-based evaluation provide richer judgment but remain nondeterministic. [3]

That taxonomy is useful beyond coding agents because it prevents several different architectural jobs from collapsing into one confidence score.

A deterministic test result is not the same thing as a semantic judgment. A behavioral instruction is not the same thing as an enforced boundary. An approval decision is not the same thing as telemetry. A provenance record is not the same thing as authorization.

Enterprise assurance therefore needs to preserve the mechanism underneath each claim. If the mechanism is inferential, the claim should remain inferential. If the mechanism is observational, it should not be described as preventive. If the mechanism is an execution boundary, it should not be reduced to another weighted signal.

Frontier Providers Expose Execution Controls, Not Enterprise Authority

Current frontier platforms independently expose this separation through different implementation patterns.

OpenAI’s Codex safety guidance describes a sandbox as the technical execution boundary governing where Codex can write, whether it can reach the network, and which paths remain protected. Approval policy separately determines when an action must stop for a decision. Managed network policy constrains outbound reach, rules can allow, require approval for, or block command patterns, and agent-native logs preserve surrounding request, tool, approval, result, and network-policy information. [4]

The OpenAI Agents SDK reinforces that separation. Its human-in-the-loop flow evaluates whether a tool call requires approval, pauses execution when approval is required and no decision is stored, preserves the interrupted run in RunState, and resumes only after an approval or rejection decision is applied. [5] Blocking input guardrails can complete before an agent starts and prevent the agent from executing; tool guardrails can validate or block function-tool calls immediately before execution. [6] Tracing separately records generations, tool calls, handoffs, guardrails, and custom events across a workflow. [7]

Anthropic exposes a different but architecturally compatible pattern. Managed Agents permission policies govern when an enabled server-executed tool runs: automatically, after approval, or after server evaluation. Under auto, a call can resolve to allow, ask, or deny. Anthropic explicitly separates enabled-tool state from permission policy, and custom tools remain application-owned: the application receives the tool-use event and decides whether to execute it. [11]

Claude Code sandboxing similarly defines filesystem and network boundaries inside which the agent can operate more freely. Anthropic describes these as operating-system-level constraints on what Claude can access or modify and which servers it can reach. [12] Anthropic’s broader containment guidance makes the distinction even more explicit: behavioral supervision is probabilistic, while process sandboxes, virtual machines, filesystem boundaries, and egress controls establish hard limits on what an agent is able to reach. [13]

The providers use different products, mechanisms, and terminology. The architectural implication is the same:

provider/runtime controls implement portions of the enterprise authority decision; they do not become the enterprise authority model by themselves.

The enterprise still has to determine whether a capability is permitted for this workflow, identity, environment, data, toolchain, and moment.

Capability, Authority, and Evidence Must Remain Distinct

The durable distinction is:

Capability ≠ Authority ≠ Evidence.

Capability describes what the agent can technically do. Authority describes what the agent is permitted to do. Evidence describes what supports a claim about what occurred.

The three interact, but they should not collapse into one another. Authority bounds usable capability. Authorized execution produces evidence. Evidence can later inform whether authority should remain, contract, or expand, but evidence does not retroactively create permission.

OpenAI’s Codex Security provides a concrete worked example. Codex Security analyzes a repository, builds a codebase-specific threat model, discovers candidate vulnerabilities, validates findings in an isolated environment, and generates proposed patches. The patch does not automatically modify the repository; it is surfaced for human review and can be raised into the normal pull-request workflow. [8]

That sequence matters. Discovery is not validation. Validation is not remediation. Remediation proposal is not approval. Approval is not the same thing as authority to apply a change to a production system.

Anthropic’s custom-tool model independently supports the general principle from another direction: a model can request a custom tool, but Anthropic’s permission policy does not execute that application-owned tool. The application remains responsible for deciding whether the action should occur. [11]

The architectural rule is broader than either implementation:

verification does not automatically confer authority to remediate.

Some Controls Cannot Be Averaged

The difference between computational and inferential mechanisms becomes especially important when authority is involved.

A confidence score can accumulate with other evidence. A hard authority boundary should not.

OpenAI documents controls that can prevent or suspend action: blocking input guardrails can stop the agent before execution, tool guardrails can block function-tool calls, sandbox boundaries restrict filesystem and network reach, and approval policy can interrupt execution before an action proceeds. [4][5][6]

Anthropic documents the same architectural category through different mechanisms. Claude Code sandboxing constrains filesystem and network access. Anthropic’s containment architecture uses sandboxes, virtual machines, filesystem boundaries, and egress controls specifically to establish hard limits on reach rather than depending only on probabilistic behavioral supervision. [12][13]

The implementation evidence supports those documented boundaries. OpenAI’s Agents SDK runtime-boundary reference separates the outer Runner responsibilities—including approvals, handoffs, tracing, session history, and RunState—from the sandbox session that owns the execution environment, workspace, processes, mounts, and provider-specific connection state. [9] OpenAI’s Codex configuration requirements expose sandbox and approval configuration as explicit constrained surfaces. [10]

Anthropic’s open-source Sandbox Runtime uses operating-system primitives and proxy-mediated network filtering to enforce filesystem and network restrictions, with default-deny network behavior and violation monitoring. [14] Claude Code’s repository separately exposes sandbox enablement, managed permission-rule posture, unsandboxed-command policy, and network/socket restrictions in configuration. [15]

These mechanisms should not be treated as points on the same confidence scale as semantic review.

That leads to a durable rule:

Evidence can accumulate. Authority boundaries do not average.

A strong test suite, favorable inferential evaluation, or clean attestation record should not compensate for an action that exceeded the authority boundary. A boundary violation is a control failure, not a low-confidence success.

Attestation Belongs Inside Continuous Assurance

Attestation becomes most useful when it is placed inside a larger assurance loop rather than treated as the loop itself.

Execution can generate traces, provenance, approval decisions, test results, validation evidence, guardrail outcomes, sandbox violations, and human review. OpenAI tracing provides one implementation of this evidence layer; Anthropic permission events and sandbox violation monitoring provide another. [7][11][14]

The enterprise can use that evidence to support an assurance judgment. The result of that assurance process can then inform a new authority decision.

The sequence should be:

Evidence → Assurance → Governed Authority Decision

not:

Evidence → automatic authority expansion

A workflow that repeatedly produces strong evidence may justify maintaining its existing authority. It may justify reducing oversight for one bounded low-risk action. It may justify expanding a specific permission. A failed control, changed environment, changed data sensitivity, or new risk may justify contracting authority instead.

The governing question is therefore not only, Was the last execution acceptable?

It is also, Should the next execution occur under the same authority boundary?

That is continuous assurance: evidence informs the next governed decision without becoming the decision itself.

Boundaries and Limits

This architecture should not be read as claiming that attestation, provenance, provider controls, or enterprise governance are sufficient independently.

in-toto and SLSA establish useful authorization, provenance, and evidence lineage for software supply chains; they are not agentic-AI control-plane standards. [1][2] Böckeler’s harness-engineering model provides a useful computational/inferential and feedforward/feedback taxonomy; it is not an enterprise authorization model. [3]

OpenAI and Anthropic also expose different controls across different products. A mechanism documented for one runtime should not be generalized automatically to every product or connected downstream system. Repository evidence demonstrates concrete implementation behavior; it does not establish a universal enterprise-governance guarantee. [9][10][14][15]

Anthropic’s Sandbox Runtime is explicitly a beta research preview, and its configuration semantics may evolve. [14] Anthropic Managed Agents permission policies do not govern custom tools; application-owned execution remains the application’s responsibility. [11]

Instructions are not deterministic enforcement. Approval is not universal authorization. Telemetry, traces, provenance, validation artifacts, and Audit Trails are related evidence mechanisms but should not be treated as interchangeable. OpenAI’s Agents SDK tracing documentation also notes configuration and retention boundaries, including that tracing is unavailable for organizations using the API under Zero Data Retention policy. [7]

Attestation itself can also fail. Specifications may be incomplete. Inferential evaluation can be poorly calibrated. Human review can be superficial. Provenance can be incomplete. Execution boundaries can be misconfigured or too broad.

Governed execution therefore does not eliminate execution risk or make outcomes automatic, universal, or guaranteed. It means that intent, authority, provider controls, execution, evidence, and assurance are designed as distinct but connected architectural concerns.

The Durable Architectural Claim

Attestation is part of the assurance architecture. It is not the control plane.

Enterprise AI delivery requires an enterprise-owned authority model that defines what may happen before and during execution. Provider/runtime controls enforce relevant portions of that decision. Execution then produces evidence that can support assurance. Continuous assurance connects the evidence back to a governed decision about whether authority should remain, contract, or expand.