High-Assurance Agent Control Envelope

Introduction High-consequence agent deployments combine several independently useful mechanisms: workload identity, delegated authorization, evidence or attestation, policy evaluation, revocation, software-assurance evidence, human oversight, and execution logging. A recurring systems failure occurs when one valid artifact is silently treated as sufficient for a stronger conclusion. For example, a valid identity does not prove that an action is authorized; a valid authorization does not prove that the underlying software meets a deployment assurance requirement; and invalidating a credential does not prove that stale delegated authority can no longer reach a consequential effect. HAACE defines a narrow execution-gate profile. A relying party declares an Assurance Requirement Profile (ARP). An agent or intermediary presents an Action Request Record (ARR) plus references to the required evidence. An independent Action Control Point (ACP) evaluates the request. The ACP emits a non-bearer Action Decision Receipt (ADR). If an effect is attempted, the enforcement point emits a separate Action Execution Receipt (AER). No receipt defined by this document is itself a bearer credential. This document is intended for deployments that need stronger action-time assurance, including government, critical-infrastructure, regulated, and enterprise systems. It is not a U.S. Government standard and does not imply endorsement by any government agency.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals.

Design Principles

Identity is not authorization. A valid identity result MUST NOT by itself authorize an action.
Evidence is not authority. Evidence artifacts MAY influence an authorization decision but MUST NOT be accepted as bearer authorization.
Authorization is not execution. An authorization decision MUST be bound to the exact action, resource, policy, audience, and authority epoch evaluated.
Unknown is not allow. Missing, stale, unverifiable, contradictory, or indeterminate required premises MUST NOT produce ALLOW.
Revocation request is not closure. When an ARP requires closure evidence for a superseded authority epoch, an unresolved closure state MUST NOT be treated as closed.
Software assurance does not self-promote. A local conformance result MUST NOT satisfy an ARP that requires independent reproduction or security testing.
Agent self-approval is invalid. A principal or agent MUST NOT satisfy an ARP requirement for independent authorization or independent human approval by issuing the required approval to itself.
Decision receipts are non-bearer records. Possession of an ADR or AER MUST NOT confer permission to execute another action.

Terminology

Action Request Record (ARR): A canonical description of the proposed action and its security-relevant bindings.
Assurance Requirement Profile (ARP): A relying-party policy object stating which identity, authorization, evidence, software-assurance, revocation, and oversight predicates are required for a class of actions.
Action Control Point (ACP): An enforcement-adjacent component that evaluates an ARR against an ARP and current authority state.
Action Decision Receipt (ADR): An integrity-protected, non-bearer record of an ACP decision and the inputs evaluated.
Action Execution Receipt (AER): An integrity-protected record describing whether the authorized action was attempted, completed, failed, or remained indeterminate at the effect boundary.
Authority Epoch: A monotonically distinguishable authorization generation used to prevent stale or superseded authority from being accepted as current.
Assurance Stage: One of REGISTERED, SPEC_VALIDATED, LOCAL_CONFORMANT, INDEPENDENTLY_REPRODUCED, SECURITY_TESTED, or RELEASE_ELIGIBLE.
High-Impact Action: An action classified by the relying party as requiring heightened assurance or oversight because of potential consequence. This document does not define a universal legal or regulatory classification.

Assurance Requirement Profile An ARP is controlled by the relying party, not by the agent whose action is being evaluated. The ARP identifies a profile identifier and version, covered resources or action classes, accepted identity methods, minimum software-assurance stage, evidence requirements, required policy digest, authority-epoch behavior, revocation checks, human-oversight requirements, freshness limits, and receipt-retention requirements. An ARP MAY distinguish low-impact and high-impact actions. A deployment MAY require stronger assurance stages, independent approval, shorter freshness bounds, or prior-epoch closure evidence for higher-impact actions.

Action Request Record An ARR MUST bind the following security-relevant values: profile version, request identifier, agent identifier, principal identifier when applicable, target resource, operation, action digest, requested audience, authorization identifier, authority epoch, policy digest expected by the requester, and references to evidence artifacts. An ARR MAY carry context that is explicitly declared non-authoritative. The action digest MUST cover all parameters whose substitution could change the security-relevant meaning of the action. A relying party MUST reject an ARR if the action presented at enforcement time does not reproduce the registered action digest.

Action-Time Decision Algorithm The ACP evaluates an ARR using current relying-party state. A conforming implementation performs the following checks in order:

Validate ARR syntax, required fields, and canonical digest.
Verify the agent identity result using a deployment-selected identity mechanism. INVALID or UNKNOWN identity MUST NOT produce ALLOW.
Verify an authorization artifact issued by an authority independent of the requesting agent. The authorization MUST bind the agent or principal, resource, operation, audience, scope, validity interval, and authority epoch required by the ARP.
Compare the authorization epoch with the current epoch for the resource. A stale epoch MUST be denied.
If the ARP requires closure evidence for a superseded epoch, verify an applicable closure result. UNKNOWN, PARTIAL, FAILED, or unresolved closure MUST NOT satisfy a CLOSED requirement.
Verify that the software-assurance stage meets or exceeds the ARP minimum. A local PASS MUST NOT satisfy an independent-reproduction requirement.
Verify each required evidence predicate. FAIL, UNKNOWN, stale, contradictory, or missing required evidence MUST NOT produce ALLOW.
Verify that the current policy digest equals the ARP-pinned policy digest, unless the ARP explicitly defines an allowed successor policy.
If human approval is required, verify that the approval was issued by an eligible approver independent of the requesting agent and is bound to the exact action digest and current authority epoch.
Verify that the action presented to the effect boundary still matches the evaluated resource, operation, action digest, and audience.
Return ALLOW only if every required predicate is satisfied. Return DENY for a known failing predicate. Return INDETERMINATE when a required predicate cannot be established.

Decision and Execution Receipts An ADR records the request identifier, action digest, agent identifier, principal identifier when applicable, resource, operation, authority epoch, ARP identifier and version, policy digest, identity result digest, authorization digest, evidence digests, software-assurance stage, revocation or closure state used, oversight state, decision, decision time, enforcement-point identifier, and predecessor receipt digests when applicable. An AER records the ADR digest plus one of NOT_ATTEMPTED, ATTEMPTED, COMPLETED, FAILED, or INDETERMINATE. An AER MUST NOT be used to infer that the underlying authorization was valid merely because an action completed successfully. For interoperable JSON digests, implementations SHOULD use JSON Canonicalization Scheme (JCS) and an approved digest algorithm. Deployments requiring specific cryptographic algorithms SHOULD select them through an external cryptographic policy rather than redefining algorithm suites in this document.

Conformance and Falsification A HAACE implementation claiming conformance MUST reproduce the companion positive and negative vectors. The vector set includes valid identity with missing authorization, missing evidence, stale authority epoch, unresolved revocation closure, insufficient software-assurance stage, absent required human approval, policy-digest mismatch, action substitution, self-issued authorization, and receipt-integrity failure. The central falsifiers are direct. If a valid identity alone produces ALLOW, the implementation is non-conformant. If an UNKNOWN required premise produces ALLOW, the implementation is non-conformant. If a stale authority epoch is accepted, the implementation is non-conformant. If a local conformance result satisfies an ARP that requires independent reproduction, the implementation is non-conformant. If an agent satisfies an independent-approval requirement with its own approval, the implementation is non-conformant.

High-Assurance and Government Deployment Considerations HAACE is vendor-neutral. It can be used to express action-time controls in environments that follow zero-trust principles, workload-identity policy, secure-software-development practices, or agency-specific AI governance. NIST SP 800-207 separates authentication and authorization and focuses protection on resources; NIST SP 800-207A extends identity-oriented access control to cloud-native and multi-cloud applications. NIST AI 800-5 reports broad agreement that AI-agent security requires adaptation of existing cybersecurity practices and that standards and implementation guidance can support secure adoption. These sources motivate the profile but do not make HAACE a NIST or U.S. Government standard. U.S. Executive Branch deployments may also have obligations under current OMB AI governance and acquisition policy. Those obligations are external to this protocol and can change independently. A federal deployment profile SHOULD therefore pin the applicable policy identifiers and versions outside the HAACE core.

Relationship to Existing Work Agent Operation Authorization defines structured authorization for specific agent operations . Authorization Evidence Chains compose heterogeneous evidence artifacts . WIMSE authorization-evidence work defines signed evidence records for authorized agent actions . HAACE does not replace these mechanisms; it defines a relying-party execution-gate profile that evaluates identity, authorization, evidence, software-assurance stage, revocation state, policy state, oversight, and the exact action together. Revocation Closure for Agentic Authorization Systems distinguishes invalidation from closure and defines closure states and receipts . Agent Authority Transition Receipts record authority-state transitions . Non-Collapse Semantics separates evidence, authorization, and execution state . HAACE composes these ideas into action-time relying-party requirements and does not treat any one artifact as sufficient by itself.

Security Considerations Threats include action substitution after authorization, stale authority replay, agent self-authorization, evidence substitution, policy downgrade, confused-deputy behavior, delegation laundering, clock skew, forged or replayed approval, unresolved queued effects after revocation, and circular testing in which the implementation under test generates its own expected values. The ACP and effect boundary SHOULD be controlled independently of the agent. The agent MUST NOT be able to advance its software-assurance stage, change the relying-party ARP, redefine the current authority epoch, rewrite prior receipts, or mark an unresolved revocation state as CLOSED. HAACE receipts preserve what was evaluated; they do not prove that external evidence was true, that a model was safe, or that a deployment is secure. Implementations require independent conformance testing, fault injection, authorized penetration testing, provenance, and release governance appropriate to the deployment. Privacy-sensitive deployments SHOULD minimize the contents of receipts and prefer digests or references where full evidence disclosure is unnecessary. Receipt retention and disclosure MUST comply with applicable law and local policy.

IANA Considerations This document has no IANA actions.