High-Risk Agent Actions Need Proof of Their Runtime

An agent with a valid identity and a valid permission can still execute in the wrong runtime. Its orchestrator may be unpatched. The policy evaluator may have been replaced. A tool executor may be running outside the expected isolation boundary. A dependency or configuration may differ from the approved release. For a consequential action—releasing funds, issuing a credential, decrypting sensitive data, or changing a production system—this is not a minor implementation detail. It is a governance question.

Autonomous organizations should therefore ask a further question at the commitment point: can this action present fresh evidence of the runtime that is about to execute it? For high-risk effects, the answer should increasingly be a condition of release. The commitment gateway should not issue a transaction credential, decryption key, or tool capability solely because a principal is authenticated and authorized. It should also require an attestation verdict for the execution chain that will produce the effect.

Identity, permission and runtime evidence answer different questions

These controls are often collapsed into one vague idea of trust. They should not be. Authentication answers: which principal is requesting this action? Authorization answers: may that principal perform this action, under these constraints? Audit logs answer: what did the system record as having happened? Runtime attestation answers a narrower and distinct question: what measured software and hardware configuration was present when evidence was produced?

None of these answers makes the others unnecessary. An attested runtime can still make a poor decision. It can be authorized for an action that is inappropriate in the business context. Its logs can be incomplete, and its identity can be compromised. Conversely, a correct policy decision does not establish that the policy evaluator running at the time was the approved evaluator. Attestation is not evidence that an agent was safe, lawful, aligned, or correct. It is evidence about the measured environment in which a defined part of the system ran.

“For a high-risk effect, authorization should decide whether an action may occur; attestation should help decide whether this runtime may receive the means to make it occur.

Treat attestation as a gate, not a retrospective report

The architectural mistake is to collect runtime evidence after a payment, deployment, or disclosure has already occurred. At that point, attestation may improve incident analysis, but it cannot prevent a nonconforming environment from receiving the power to act. The useful placement is before the irreversible or costly business effect, at the same commitment gateway that controls effect-specific credentials and capabilities.

A practical gate has five steps. First, the agent run declares the intended effect through a stable effect identifier: for example, a particular vendor payment, production change, or customer-data export. Second, the relevant runtime components provide signed evidence. Third, a verifier appraises that evidence against approved reference values and produces a short-lived verdict. Fourth, the verdict is bound to the run identifier and effect identifier. Fifth, the commitment gateway evaluates the verdict alongside ordinary authorization, risk policy, and the business controls for that effect before releasing a narrowly scoped capability.

1. Declare the proposed business effect and its effect identifier.
2. Collect signed evidence from the relevant execution components.
3. Appraise measurements against approved reference values.
4. Bind a fresh verdict to the specific run and effect.
5. Release only the credential or capability required for that effect, if all gates pass.

Binding matters. A general statement that a workload was healthy earlier in the day should not be reusable to authorize an unrelated transfer or deployment. The verdict needs a short validity period and a clear association with the run and effect. Otherwise, runtime evidence becomes another portable token with a broader life than the control it was meant to support.

The execution chain is composite

Agent actions rarely originate in one executable. A consequential run may involve an orchestrator that schedules work, a policy engine that evaluates constraints, a model endpoint, a memory service, a tool executor, and a protected workload environment. The correct attestation boundary is therefore not necessarily “the agent.” It is the set of components whose state is material to the organization’s willingness to permit the specific effect.

The IETF Remote ATtestation Procedures architecture, RFC 9334, provides a useful model for this. It separates the attester that produces evidence, the verifier that appraises it, and the relying party that uses the attestation result in an application-specific decision. It also describes composite systems in which evidence from several sub-entities is collected by a lead attester. This maps naturally to a governed execution chain: the verifier assesses runtime state, while the commitment gateway is the relying party that decides whether to release power.

The evidence need not be flattened into one opaque claim. RFC 9711’s Entity Attestation Token framework supports nested submodules in evidence and attestation results, including nested tokens and detached submodule digests. RFC 10013 defines structures for measured components, including component identities and cryptographic measurements. Together, these are useful primitives for representing a layered runtime in which some components are measured directly and others are independently attested.

This does not mean every component will be observable at the same depth. A hosted model provider may not expose measurements for model weights or its full serving stack. The organization must define its attainable boundary honestly: perhaps its own orchestrator, policy evaluator, executor, and protected workload environment, while treating the external model service as a separately governed dependency. A missing measurement should be a consciously handled policy condition, not an implied assurance.

Reference values are a governance lifecycle

The verifier can only judge evidence against reference values that the organization has approved. That makes reference values operational governance, not static security metadata. New releases, emergency patches, configuration changes, revoked dependencies, and revised isolation requirements all change what the organization should accept. An approved measurement is never a permanent grant of trust.

NIST’s May 2026 initial public draft on confidential cloud workloads describes remote attestation as signed evidence of hardware and software configuration, with a relying party comparing measurements against expected values before granting access to secrets or keys. That pattern is directly applicable here, even where the organization uses assurance mechanisms other than specialized hardware. RATS permits a range of attestation approaches, from process isolation to specialized hardware. The governance requirement is evidence proportional to the risk, not a universal mandate for a hardware trusted execution environment.

Reference-value changes need the same discipline as policy changes. They require ownership, review, rollout rules, versioning, revocation, and a way to reappraise long-running work after a relevant runtime change. Without this lifecycle, the organization merely automates approval of an aging baseline.

Start where runtime deviation can create irreversible effects

Not every agent request deserves a remote-attestation round trip. Reading public information, drafting internal text, or producing a reversible recommendation may be governed adequately by ordinary identity, authorization, and logging. The first candidates for a runtime-proof gate are actions that release secrets, commit money, change production state, disclose regulated data, or invoke powerful external tools. These are the moments where a deviation in the control path has a material operating consequence.

Begin with a small, explicit execution chain. For example, require evidence for the orchestrator, policy evaluator, and tool executor before issuing a one-time payment credential. Define which measurements are required, who owns their reference values, how fresh a verdict must be, and what happens when a component is unavailable or not attestable. The safe default for a high-risk effect is usually to deny release, route the case for human review, or use a separately governed fallback—not to silently treat absent evidence as a pass.

The result is not a claim that the organization has solved agent safety. It is a more precise control boundary. The organization can say that a particular effect was authorized under policy, recorded in its evidence systems, and released only after the relevant measured runtime met the current acceptance rules. As autonomous systems acquire authority over consequential work, that is a distinction worth making before—not after—the action leaves the building.

Sources

• IETF RFC 9334, Remote ATtestation Procedures (RATS) Architecture.
• IETF RFC 9711, Entity Attestation Token (EAT).
• IETF RFC 10013, Reference Interaction Models for Remote Attestation Procedures.
• NIST IR 8320E, Confidential Cloud Workloads, initial public draft, May 2026.
• Confidential Containers, Attestation Architecture.