| Internet-Draft | High-Assurance Agent Control | October 2026 |
| Watts | Expires 17 April 2027 | [Page] |
Agentic systems can authenticate successfully, hold a valid authorization object, and still be unsafe to execute because required evidence is missing, the software has not reached a required assurance stage, the authority epoch is stale, a prior revocation is unresolved, or a human-approval requirement is unsatisfied. This document defines the High-Assurance Agent Control Envelope (HAACE), a protocol-neutral profile that binds an exact agent action to identity status, authorization state, policy, assurance stage, evidence state, authority epoch, revocation state, oversight requirements, and an action-time decision. HAACE requires fail-closed treatment of missing or indeterminate prerequisites, separates authorization from execution, and produces non-bearer decision and execution receipts. The profile composes with OAuth, workload identity, attestation, transparency, and agent-authorization mechanisms rather than replacing them.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 17 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals.¶
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.¶
A canonical description of the proposed action and its security-relevant bindings.¶
A relying-party policy object stating which identity, authorization, evidence, software-assurance, revocation, and oversight predicates are required for a class of actions.¶
An enforcement-adjacent component that evaluates an ARR against an ARP and current authority state.¶
An integrity-protected, non-bearer record of an ACP decision and the inputs evaluated.¶
An integrity-protected record describing whether the authorized action was attempted, completed, failed, or remained indeterminate at the effect boundary.¶
A monotonically distinguishable authorization generation used to prevent stale or superseded authority from being accepted as current.¶
One of REGISTERED, SPEC_VALIDATED, LOCAL_CONFORMANT, INDEPENDENTLY_REPRODUCED, SECURITY_TESTED, or RELEASE_ELIGIBLE.¶
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.¶
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.¶
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.¶
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.¶
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) [RFC8785] 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.¶
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.¶
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.¶
Agent Operation Authorization defines structured authorization for specific agent operations [I-D.agent-op-auth]. Authorization Evidence Chains compose heterogeneous evidence artifacts [I-D.aec]. WIMSE authorization-evidence work defines signed evidence records for authorized agent actions [I-D.wimse-evidence]. 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 [I-D.watts-closure]. Agent Authority Transition Receipts record authority-state transitions [I-D.watts-aatr]. Non-Collapse Semantics separates evidence, authorization, and execution state [I-D.watts-nc]. HAACE composes these ideas into action-time relying-party requirements and does not treat any one artifact as sufficient by itself.¶
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.¶
This document has no IANA actions.¶