Network Working Group D. O. Watts Internet-Draft GoodShyt Group Inc. Intended status: Informational 30 October 2026 Expires: 3 May 2027 High-Assurance Agent Control Envelope draft-watts-high-assurance-agent-control-envelope-01 Abstract 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. Status of This Memo 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 3 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Watts Expires 3 May 2027 [Page 1] Internet-Draft High-Assurance Agent Control October 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Design Principles . . . . . . . . . . . . . . . . . . . . . . 3 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Assurance Requirement Profile . . . . . . . . . . . . . . . . 4 6. Action Request Record . . . . . . . . . . . . . . . . . . . . 5 7. Action-Time Decision Algorithm . . . . . . . . . . . . . . . 5 8. Decision and Execution Receipts . . . . . . . . . . . . . . . 6 9. Conformance and Falsification . . . . . . . . . . . . . . . . 7 10. High-Assurance and Government Deployment Considerations . . . 7 11. Relationship to Existing Work . . . . . . . . . . . . . . . . 7 12. Security Considerations . . . . . . . . . . . . . . . . . . . 8 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 14. Normative References . . . . . . . . . . . . . . . . . . . . 8 15. Informative References . . . . . . . . . . . . . . . . . . . 9 Appendix A. Changes since -00 . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. 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 Watts Expires 3 May 2027 [Page 2] Internet-Draft High-Assurance Agent Control October 2026 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. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Design Principles 1. Identity is not authorization. A valid identity result MUST NOT by itself authorize an action. 2. Evidence is not authority. Evidence artifacts MAY influence an authorization decision but MUST NOT be accepted as bearer authorization. 3. Authorization is not execution. An authorization decision MUST be bound to the exact action, resource, policy, audience, and authority epoch evaluated. 4. Unknown is not allow. Missing, stale, unverifiable, contradictory, or indeterminate required premises MUST NOT produce ALLOW. 5. 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. 6. Software assurance does not self-promote. A local conformance result MUST NOT satisfy an ARP that requires independent reproduction or security testing. 7. 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. Watts Expires 3 May 2027 [Page 3] Internet-Draft High-Assurance Agent Control October 2026 8. Decision receipts are non-bearer records. Possession of an ADR or AER MUST NOT confer permission to execute another action. 4. 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. 5. 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. Watts Expires 3 May 2027 [Page 4] Internet-Draft High-Assurance Agent Control October 2026 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. 6. 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. 7. Action-Time Decision Algorithm The ACP evaluates an ARR using current relying-party state. A conforming implementation performs the following checks in order: 1. Validate ARR syntax, required fields, and canonical digest. 2. Verify the agent identity result using a deployment-selected identity mechanism. INVALID or UNKNOWN identity MUST NOT produce ALLOW. 3. 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. 4. Compare the authorization epoch with the current epoch for the resource. A stale epoch MUST be denied. 5. 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. 6. Verify that the software-assurance stage meets or exceeds the ARP minimum. A local PASS MUST NOT satisfy an independent- reproduction requirement. Watts Expires 3 May 2027 [Page 5] Internet-Draft High-Assurance Agent Control October 2026 7. Verify each required evidence predicate. FAIL, UNKNOWN, stale, contradictory, or missing required evidence MUST NOT produce ALLOW. 8. Verify that the current policy digest equals the ARP-pinned policy digest, unless the ARP explicitly defines an allowed successor policy. 9. 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. 10. Verify that the action presented to the effect boundary still matches the evaluated resource, operation, action digest, and audience. 11. 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. 8. 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) [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. Watts Expires 3 May 2027 [Page 6] Internet-Draft High-Assurance Agent Control October 2026 9. 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. 10. 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. 11. Relationship to Existing Work 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 Watts Expires 3 May 2027 [Page 7] Internet-Draft High-Assurance Agent Control October 2026 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. 12. 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. 13. IANA Considerations This document has no IANA actions. 14. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997, . Watts Expires 3 May 2027 [Page 8] Internet-Draft High-Assurance Agent Control October 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, May 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erlandsson, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020, . 15. Informative References [I-D.agent-op-auth] Liu, C., "Agent Operation Authorization", Work in Progress, Internet-Draft, draft-liu-agent-operation- authorization-02, March 2026, . [I-D.aec] Schrock, I., "Authorization Evidence Chains: Composing Heterogeneous Agent-Action Evidence (EP-AEC)", Work in Progress, Internet-Draft, draft-schrock-ep-authorization- evidence-chain-08, October 2026, . [I-D.wimse-evidence] Munoz, M., "Signed Authorization-Evidence Records for WIMSE-Authorized AI Agent Actions", Work in Progress, Internet-Draft, draft-munoz-wimse-authorization-evidence- 01, July 2026, . [I-D.watts-closure] Watts, D. O., "Revocation Closure for Agentic Authorization Systems", Work in Progress, Internet-Draft, draft-watts-oauth-agent-revocation-closure-02, October 2026, . [I-D.watts-aatr] Watts, D. O., "Agent Authority Transition Receipts for Agentic Systems", Work in Progress, Internet-Draft, draft- watts-agent-authority-transition-receipts-00, September 2026, . [I-D.watts-nc] Watts, D. O., "Non-Collapse Semantics for Authorization, Evidence, and Execution State", Work in Progress, Watts Expires 3 May 2027 [Page 9] Internet-Draft High-Assurance Agent Control October 2026 Internet-Draft, draft-watts-authorization-noncollapse- semantics-00, October 2026, . Appendix A. Changes since -00 This section is to be removed before publishing as an RFC. Editorial and tooling-conformance changes only; no technical content was changed. * Replaced Requirements Language paragraph with the exact BCP 14 (RFC 8174) boilerplate (idnits) * Removed unreferenced bibliography entries (xml2rfc/idnits "unused reference"): NIST800207, NIST800207A, NISTAI8005 * Updated outdated reference draft-munoz-wimse-authorization- evidence-00 to current -01 * Updated outdated reference draft-schrock-ep-authorization- evidence-chain-07 to current -08 * Updated outdated reference draft-watts-oauth-agent-revocation- closure-01 to current -02 * Normalized author metadata (full name with ASCII form, initials, organization GoodShyt Group Inc., San Francisco CA postal, email, ORCID URI) * Updated document date and revision number. Author's Address Deonté O'dell Watts GoodShyt Group Inc. San Francisco, CA United States of America Email: deonte@goodshyt.fun URI: https://orcid.org/0009-0005-8586-3650 Watts Expires 3 May 2027 [Page 10]