Network Working Group M. McPhillips Internet-Draft BlackBox Engineering Intended status: Informational 31 August 2026 Expires: 4 March 2027 AgentEnvelope: Derived Authority and Legitimacy for Autonomous Systems draft-mcphillips-agentenvelope-derived-authority-01 Abstract AgentEnvelope defines a deterministic derived-authority model for autonomous and action-performing systems. Instead of issuing bearer credentials from a central authority, AgentEnvelope derives scoped action capabilities from customer-held custody material and canonical action envelopes. A verifier can check an action signature against a public action record without receiving roots, seeds, private keys, mint material, or hosted service access. This revision extends the model with legitimacy: a governance state that records whether a cryptographically valid authority remains admissible under current policy, evidence, time, and operating context. Legitimacy separates provenance from present-tense authorization. A command can remain signed and verifiable while becoming illegitimate because operating facts, policy, or evidence changed. For autonomous-system deployments, derived authority and legitimacy support an IAM model concerned with authority, admissibility, accountability, and audit for actors that perform actions, including AI agents, workflows, bots, microservices, devices, robots, serverless workers, and multi-agent systems. 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." McPhillips Expires 4 March 2027 [Page 1] Internet-Draft AgentEnvelope Authority and Legitimacy August 2026 This Internet-Draft will expire on 4 March 2027. Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Applicability to Autonomous-System IAM . . . . . . . . . . . 6 4.1. Intent and Orchestration Boundaries . . . . . . . . . . . 7 5. Authority and Governance . . . . . . . . . . . . . . . . . . 7 6. Relationship to the -00 Derived-Authority Model . . . . . . . 8 7. Legitimacy Model . . . . . . . . . . . . . . . . . . . . . . 9 8. Legitimacy Evaluation . . . . . . . . . . . . . . . . . . . . 10 9. Legitimacy Profiles . . . . . . . . . . . . . . . . . . . . . 10 10. Legitimacy State . . . . . . . . . . . . . . . . . . . . . . 11 11. Evidence Statements . . . . . . . . . . . . . . . . . . . . . 13 12. Legitimacy Decisions . . . . . . . . . . . . . . . . . . . . 14 13. Legitimacy Events . . . . . . . . . . . . . . . . . . . . . . 15 14. Governance Reports and Receipts . . . . . . . . . . . . . . . 16 15. Mint Delegation and Legitimacy . . . . . . . . . . . . . . . 16 16. Public Action Records and Legitimacy . . . . . . . . . . . . 17 17. Hosted Governance Boundary . . . . . . . . . . . . . . . . . 18 18. Verification with Legitimacy . . . . . . . . . . . . . . . . 18 19. Executor Non-Self-Authorization . . . . . . . . . . . . . . . 19 20. Relationship to Issued Authorization Containers . . . . . . . 20 21. Security Considerations . . . . . . . . . . . . . . . . . . . 21 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 23. Normative References . . . . . . . . . . . . . . . . . . . . 22 24. Informative References . . . . . . . . . . . . . . . . . . . 22 Appendix A. Manufacturing Legitimacy Example . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24 McPhillips Expires 4 March 2027 [Page 2] Internet-Draft AgentEnvelope Authority and Legitimacy August 2026 1. Introduction Autonomous software agents, workflow steps, backend workers, bots, devices, robots, and other action-performing systems increasingly need narrowly scoped authority to act without receiving long-lived shared secrets. Existing authorization systems commonly answer this by issuing credentials, tokens, assertions, certificates, or signed authorization containers. AgentEnvelope specifies a different model: authority is derived, not issued. A customer-held root deterministically derives domain authority; a canonical action envelope then derives a leaf action capability. The same inputs produce the same public action identity. A child capability does not reveal its parent or siblings. The -00 draft specified this v1 authority substrate. This revision introduces an additive v1 governance layer: legitimacy. Derived authority answers whether an actor could have signed for a given action envelope. Legitimacy answers whether that action remains admissible under current reality, policy, and evidence. The substrate is not limited to autonomous agents. The same SDK primitives can support permissioned links, timestamped media, delegated workflow actions, controlled downloads, signed handoffs, device permissions, service operations, and other scoped-authority use cases. Hosted governance can govern AgentEnvelope usage through records, delegates, legitimacy, receipts, ledgers, and audit; it does not define or constrain every possible application built with the SDK. This distinction is relevant for autonomous systems. A robot may hold a signed instruction to pick up a trolley at a bay. The signature may remain valid even after the trolley moves. Traditional signature verification can prove that the instruction was issued and unchanged; it cannot prove that execution remains safe or permitted. Legitimacy provides a separate present-tense admissibility check. This document describes AgentEnvelope v1 with additive legitimacy extensions. It is informational and records an implemented protocol surface and a governance model. It does not require any particular AI framework, transport, blockchain, hosted service, identity provider, policy language, evidence source, or trust registry. McPhillips Expires 4 March 2027 [Page 3] Internet-Draft AgentEnvelope Authority and Legitimacy August 2026 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. Action Envelope The complete canonical permission input for one action capability. Action Seed Private 32-byte signing material derived for one action envelope. Agent Address The public address derived from an action seed. Authority The ability to produce a valid signature for a scoped action. Capability Private action authority held by a worker, bot, device, or autonomous actor. Domain A stable authority branch scoped to a class of work. Evidence Statement A signed or otherwise attributable statement about external state, policy, observation, or context used by legitimacy evaluation. Executor The actor attempting to perform the action. Governance Evaluator A distinct policy/evaluation actor or service that determines legitimacy from state, policy, and evidence. Legitimacy Governance admissibility for an authority under current state, policy, evidence, and time. Legitimacy Event A signed or attributable event that updates legitimacy state. Legitimacy State Versioned governance state that records status, scope, assumptions, policy, evidence, and a state hash for an authority or record. McPhillips Expires 4 March 2027 [Page 4] Internet-Draft AgentEnvelope Authority and Legitimacy August 2026 Mint Delegate A signed permit from domain authority that allows a bot or service to request bounded action capabilities without receiving the root or domain seed. Mint Request A bot-signed request for one bounded action capability under a mint delegate. Public Action Record Verifier-safe metadata binding an agent address to a domain projection and action envelope. Sovereign Verification Offline verification of a payload signature against a public action record. 3. Design Goals AgentEnvelope v1 is designed to: * derive authority rather than issue bearer credentials; * keep roots, seeds, mint material, and private action material inside customer custody boundaries; * bind action authority to a complete canonical action envelope; * allow stateless signature verification from public action records; * keep hosted governance additive, never required for sovereign verification; * preserve isolation between domains, actions, and delegated mint capabilities; * separate authority from legitimacy; * preserve declared action intent across orchestration boundaries; * prevent an executor from being the sole arbiter of its own renewed legitimacy; * support verification of authority boundaries under adversarial prompt or workflow pressure; * support evidence-based governance without requiring any single evidence transport or policy engine; McPhillips Expires 4 March 2027 [Page 5] Internet-Draft AgentEnvelope Authority and Legitimacy August 2026 * provide audit-friendly receipts, records, and state transitions; * preserve the reference SDK as a general-purpose derived-authority tool usable outside hosted governance and autonomous-agent scenarios. 4. Applicability to Autonomous-System IAM The term IAM for Autonomous Systems is used descriptively in this document for deployments in which autonomous actors require scoped authority, present-tense admissibility checks, and auditability for actions they perform. IAM for Autonomous Systems is concerned with the following questions: * What may this actor do? * Under which domain, operation, resource, time window, and use limit? * Which authority path produced the signer? * Is the authority still admissible under current policy and evidence? * Who evaluated that admissibility? * Which records, receipts, and events allow later verification and audit? Existing IAM systems commonly center on identity, roles, sessions, issued credentials, and bearer tokens. AgentEnvelope provides mechanisms for action authority: derived capability, deterministic scope, public action records, legitimacy state, and verifier-safe audit. For this document, the relevant deployment pattern is: IAM for Autonomous Systems = derived authority + legitimacy + accountability for actors that perform actions. This term is descriptive. AgentEnvelope does not replace identity providers, policy engines, workflow engines, robotics safety systems, cloud IAM systems, link-permission systems, or timestamping systems. It defines a substrate and governance boundary that those systems can use when actors, objects, links, records, or autonomous systems need scoped, verifiable, non-bearer authority. McPhillips Expires 4 March 2027 [Page 6] Internet-Draft AgentEnvelope Authority and Legitimacy August 2026 4.1. Intent and Orchestration Boundaries Autonomous-system deployments require more than actor identification. Autonomous actors often express intent through prompts, plans, workflow steps, tool calls, queues, retries, and delegated services. That intent can fragment as it crosses orchestration boundaries. AgentEnvelope does not attempt to infer hidden intent. It binds declared action intent to canonical action envelopes: operation, resources, domain, time window, action index, and limits. A verifier can then test whether the resulting signature and public record match the declared authority boundary. Legitimacy adds a present-tense governance check over that declared intent. A system can distinguish a cryptographically valid signer from an action that remains admissible under current evidence, policy, and state. This property is relevant under sustained adversarial pressure. A prompt, workflow, or operator may try to induce an autonomous actor to exceed its role. The authority boundary should hold even when the language around the actor attempts escalation, policy override, data export, or unsafe correction. 5. Authority and Governance AgentEnvelope separates authority from governance. Authority is the ability to sign an action. It comes from custody material such as: * identity roots; * domain seeds; * action seeds; * bot keys; * mint material. Governance is shared admissibility and accountability. It comes from records and state such as: * public action records; * stored delegates; McPhillips Expires 4 March 2027 [Page 7] Internet-Draft AgentEnvelope Authority and Legitimacy August 2026 * mint receipts; * nonce ledgers; * revocation state; * legitimacy state; * evidence statements; * audit events; * verification events. The operational rule is: Offline authority, hosted accountability. Hosted governance MAY verify, record, meter, and audit use of the SDK. It MUST NOT create authority by receiving or deriving roots, seeds, mint material, action seeds, or private keys. Hosted governance governs records, delegates, receipts, ledgers, legitimacy state, and service usage; it does not define what all SDK users may build. 6. Relationship to the -00 Derived-Authority Model This revision preserves the -00 model: identityRoot -> domainSeed -> actionEnvelope -> actionSeed -> agentAddress It also preserves the public projection: domain public summary + action envelope + action envelope hash + agent address Legitimacy does not alter the v1 cryptographic derivation path and does not create a v2 authority tree. Instead, it adds v1 governance state adjacent to public records and mint delegation for applications that need present-tense admissibility. Legitimacy MUST NOT alter derived seeds, agent addresses, canonical action envelopes, or the v1 authority tree. A signature MAY be valid while legitimacy is denied. A signature MUST NOT be treated as legitimate solely because it is valid. McPhillips Expires 4 March 2027 [Page 8] Internet-Draft AgentEnvelope Authority and Legitimacy August 2026 A public action record MAY carry a legitimacyRef. A mint delegate MAY carry a legitimacyRef. A mint request MAY carry a legitimacyId. When a delegate marks legitimacy as required, the mint verifier or hosted governance layer MUST require the bot-signed mint request to reference the matching legitimacy state. 7. Legitimacy Model Legitimacy is governance admissibility, not cryptographic authority. Authority can remain cryptographically valid while legitimacy changes. A signature over a command can remain valid after: * a real-world precondition changes; * a policy changes; * a resource becomes unavailable; * an approval expires; * a safety assumption is contradicted; * a delegate is revoked; * evidence becomes stale; * usage limits are exhausted in governed state. A legitimacy evaluator produces decisions such as: allowed denied Legitimacy state commonly uses statuses such as: suspended invalid closed compromised The exact decision and status vocabulary MAY be profile-specific. Implementations that expose interoperable legitimacy state SHOULD use the base vocabulary above or publish a profile describing additional values. McPhillips Expires 4 March 2027 [Page 9] Internet-Draft AgentEnvelope Authority and Legitimacy August 2026 8. Legitimacy Evaluation Legitimacy evaluation SHOULD be deterministic. Given the same legitimacy state, evidence set, policy reference, and evaluation time, a governed evaluator SHOULD produce the same decision. Deterministic legitimacy makes governance auditable, reproducible, and resistant to evaluator drift. A legitimacy decision SHOULD be a pure function of: canonical legitimacy state + canonical evidence set + canonical policy reference + evaluation time Evaluators SHOULD NOT introduce non-deterministic factors such as local heuristics, hidden configuration, evaluator-specific randomness, hosted configuration drift, or implicit policy. Implementations MAY add evaluator signatures, attestations, reports, or receipts. These additions MUST NOT alter the deterministic decision. 9. Legitimacy Profiles A legitimacy profile defines how legitimacy is evaluated for a particular domain, application, or safety context. Profiles describe: * evidence independence rules; * evidence freshness requirements; * conflict-resolution rules; * evaluator roles; * reason-code vocabulary; * state-transition rules; * expiry rules; * audit requirements. Profiles MAY be domain-specific, such as: * manufacturing safety profiles; McPhillips Expires 4 March 2027 [Page 10] Internet-Draft AgentEnvelope Authority and Legitimacy August 2026 * robotics operation profiles; * workflow governance profiles; * financial-operation profiles; * autonomous-agent profiles. A legitimacy profile SHOULD define the evidence sources, independence assumptions, and policy references required for admissibility. Profiles SHOULD be published by interoperable deployments but are not required by the v1 substrate. Profiles MUST NOT alter the v1 authority substrate. 10. Legitimacy State A legitimacy state is versioned governance state for an authority, record, or action context. An example legitimacy state: McPhillips Expires 4 March 2027 [Page 11] Internet-Draft AgentEnvelope Authority and Legitimacy August 2026 { "type": "agentenvelope.legitimacyState", "version": 1, "legitimacyId": "ae-legit-...", "ownerUserId": "user-...", "status": "legitimate", "stateVersion": 1, "stateHash": "0x...", "scope": { "kind": "record", "id": "ae-action-..." }, "policyRef": { "policyId": "manufacturing-location-precondition", "policyVersion": 2, "policyHash": "0x..." }, "assumptions": [ { "assumptionId": "trolley4-location", "assumptionVersion": 1, "assumptionHash": "0x...", "label": "trolley4 is at bay7" } ], "evidence": [ { "kind": "sensor", "uri": "agentenvelope:evidence:ae-evidence-...", "sha256": "0x...", "label": "WarehouseFeed reports trolley4", "metadata": { "producer": "WarehouseFeed", "observedAt": "2026-08-26T18:28:45.000Z" } } ], "createdBy": "GovernanceEvaluator", "createdAt": "2026-08-26T18:28:45.000Z", "updatedAt": "2026-08-26T18:28:45.000Z", "expiresAt": "2026-08-26T18:33:45.000Z" } Implementations SHOULD compute stateHash over the canonical state object with stateHash omitted. Legitimacy state MUST NOT contain private signing material. McPhillips Expires 4 March 2027 [Page 12] Internet-Draft AgentEnvelope Authority and Legitimacy August 2026 11. Evidence Statements An evidence statement describes a fact or observation used by legitimacy evaluation. Evidence can come from sensors, workflow systems, supervisors, controllers, policy engines, inventory systems, logs, attestations, or other domain-specific sources. An example evidence statement: { "type": "agentenvelope.evidenceStatement", "version": 1, "evidenceId": "ae-evidence-...", "producer": { "actorId": "WarehouseFeed", "signerAddress": "0x..." }, "evidenceKind": "sensor", "subject": "trolley4", "claims": [ { "name": "location", "value": "bay4" }, { "name": "free", "value": true } ], "observedAt": "2026-08-26T18:30:06.000Z", "signature": { "alg": "secp256k1-keccak256", "signerAddress": "0x...", "value": "0x..." } } Evidence formats MAY be profile-specific. If evidence is signed, the signature MUST cover the evidence body without the signature field. Evidence used to renew an executor's legitimacy SHOULD be sufficiently independent from that executor. Independence is policy- specific, but a profile SHOULD identify: * the executing actor; * trusted evidence sources; * minimum independent source count; * freshness requirements; * conflict-resolution rules; McPhillips Expires 4 March 2027 [Page 13] Internet-Draft AgentEnvelope Authority and Legitimacy August 2026 * whether the executor's own observations may be used as a signal but not as a final basis for renewed authority. 12. Legitimacy Decisions A legitimacy decision is the evaluator's result after applying policy to state, evidence, and time. Example denied decision: { "decision": "denied", "reasonCode": "state.mismatched", "reason": "trolley4 is at bay4, not bay7", "checkedAt": "2026-08-26T18:30:08.000Z", "expectedLocation": "bay7", "observedLocation": "bay4", "evidenceIds": ["ae-evidence-...", "ae-evidence-..."] } Example allowed decision: { "decision": "allowed", "reasonCode": "state.current", "reason": "independent evidence supports the command", "checkedAt": "2026-08-26T18:30:10.000Z", "evidenceIds": ["ae-evidence-...", "ae-evidence-..."] } Common reason-code families include: * scope.* for operation, resource, or record-scope failures; * state.* for status, expiry, mismatch, unavailable, or unobserved state; * evidence.* for missing, stale, untrusted, conflicting, or non- independent evidence; * policy.* for policy-specific denial; * replay.* for nonce, idempotency, or usage exhaustion failures. Profiles MAY define stricter reason-code registries. McPhillips Expires 4 March 2027 [Page 14] Internet-Draft AgentEnvelope Authority and Legitimacy August 2026 13. Legitimacy Events A legitimacy event updates legitimacy state. Events are useful when authority remains cryptographically valid but no longer satisfies policy or evidence. Example event: { "type": "agentenvelope.legitimacyEvent", "version": 1, "eventId": "ae-legit-event-...", "eventType": "evidence.invalidation", "legitimacyId": "ae-legit-...", "occurredAt": "2026-08-26T18:30:08.000Z", "effectiveAt": "2026-08-26T18:30:08.000Z", "scope": { "kind": "record", "id": "ae-action-..." }, "patch": { "status": "suspended", "reasonCode": "state.mismatched", "metadata": { "commandId": "cmd-trolley4-bay7-v1", "expectedLocation": "bay7", "observedLocation": "bay4", "evidenceIds": ["ae-evidence-...", "ae-evidence-..."] } }, "evidence": [ { "kind": "independent-evidence", "uri": "agentenvelope:evidence:ae-evidence-...", "label": "Evidence contradicted the old command state" } ], "producer": { "authorityId": "GovernanceEvaluator" }, "signature": { "alg": "secp256k1-keccak256", "signerAddress": "0x...", "value": "0x..." } } McPhillips Expires 4 March 2027 [Page 15] Internet-Draft AgentEnvelope Authority and Legitimacy August 2026 An event producer SHOULD be distinct from the executor when the event renews, suspends, or restores the executor's authority. 14. Governance Reports and Receipts Governance systems SHOULD emit verifier-safe reports or receipts for decisions. These reports let auditors distinguish: * whether the command signature was valid; * whether the action envelope matched the public record; * whether the legitimacy state was active; * which evidence was considered; * which evaluator made the decision; * why the action was allowed or denied. Example report: { "type": "agentenvelope.governanceReport", "version": 1, "reportId": "ae-report-...", "command": "robot2.pickUp(trolley4, bay7)", "recordId": "ae-action-...", "signatureValid": true, "scopeValid": true, "legitimacyDecision": "denied", "reasonCode": "state.mismatched", "reason": "trolley4 is at bay4, not bay7", "checkedAt": "2026-08-26T18:30:08.000Z", "evidenceIds": ["ae-evidence-...", "ae-evidence-..."], "evaluator": "GovernanceEvaluator" } Hosted attestations, when used, sign only the hosted verifier's statement about facts it computed. They MUST NOT become a required precondition for sovereign offline verification. 15. Mint Delegation and Legitimacy Mint delegation lets a bot request bounded action capabilities without receiving the vault root or domain seed. A MintDelegate MAY include a legitimacyRef: McPhillips Expires 4 March 2027 [Page 16] Internet-Draft AgentEnvelope Authority and Legitimacy August 2026 { "legitimacyRef": { "legitimacyId": "ae-legit-...", "required": true, "policyId": "support-ops-delegate-legitimacy", "stateVersion": 1, "stateHash": "0x..." } } If legitimacyRef.required is true, the mint verifier MUST require the bot-signed MintRequest to include the same legitimacyId. The purpose is to bind the bot's request to the current governance state without giving the bot authority to decide that state. 16. Public Action Records and Legitimacy A public action record MAY include a legitimacyRef that points to the governance state used when the record was created, minted, registered, or verified. Example: { "type": "agentenvelope.publicActionRecord", "version": 1, "recordId": "ae-action-...", "status": "active", "agentId": "support-refund-0", "agentAddress": "0x...", "actionEnvelopeHash": "0x...", "legitimacyRef": { "legitimacyId": "ae-legit-...", "required": true, "stateVersion": 1, "stateHash": "0x..." } } The presence of legitimacyRef does not change offline signature verification. It gives verifiers and governance systems a stable handle for present-tense admissibility checks. McPhillips Expires 4 March 2027 [Page 17] Internet-Draft AgentEnvelope Authority and Legitimacy August 2026 17. Hosted Governance Boundary Hosted governance may store encrypted workspace state, public action records, stored delegates, verification events, audit events, API key hashes, billing records, mint ledgers, legitimacy state, legitimacy events, evidence references, and governance reports. Hosted governance verifies, records, meters, and audits authority. It does not create authority. Hosted services MUST NOT receive, derive, persist, log, or return: * vault passphrases; * plaintext identity roots; * domain seeds; * action seeds; * actionSeedHex; * mint material; * bot private keys; * other private signing material. Hosted API keys meter and protect hosted governance services. They MUST NOT be treated as agent authority. Agent authority is proven by signatures, public records, delegates, and out-of-band custody material. 18. Verification with Legitimacy A verifier that holds a public action record, payload, and signature can perform the -00 sovereign checks without hosted access: 1. record type and version; 2. record status; 3. action index; 4. canonical action envelope; 5. action envelope hash; McPhillips Expires 4 March 2027 [Page 18] Internet-Draft AgentEnvelope Authority and Legitimacy August 2026 6. optional expected envelope hash; 7. time decay; 8. signature form; 9. recovered address. These checks prove provenance and integrity. They do not prove usage exhaustion, nonce replay, current real-world conditions, or active legitimacy. A governed verifier MAY additionally check: 1. legitimacy reference; 2. latest legitimacy state; 3. state hash and version; 4. policy reference; 5. evidence freshness; 6. evidence independence; 7. reason-code result; 8. evaluator signature or attestation; 9. audit/event continuity. The result SHOULD report signature validity and legitimacy separately. Example: { "signatureValid": true, "legitimacyDecision": "denied", "reasonCode": "state.mismatched" } 19. Executor Non-Self-Authorization An autonomous executor SHOULD NOT be the final arbiter of whether its own authority remains legitimate. McPhillips Expires 4 March 2027 [Page 19] Internet-Draft AgentEnvelope Authority and Legitimacy August 2026 An executor MAY: * detect a mismatch; * refuse execution; * emit an observation; * request evaluation; * propose a corrected action. An executor SHOULD NOT: * unilaterally renew its own legitimacy; * suppress evidence needed for evaluation; * be the only evidence source for renewed execution authority; * patch its own legitimacy state without an independent governance role. The recommended lifecycle is: Reality change -> executor detects mismatch -> evidence is gathered from sufficiently independent sources -> old legitimacy is suspended or denied -> independent evaluation occurs -> new legitimacy basis is created -> execution is re-authorized This requirement prevents executor self-authorization through executor-controlled evidence. 20. Relationship to Issued Authorization Containers AgentEnvelope is not an issued authorization container. Issued authorization systems can describe an actor's mandate, constraints, and validity. AgentEnvelope instead derives the action capability from custody material and canonical action parameters. This makes the permission boundary part of the action key itself. Legitimacy adds a second distinction: McPhillips Expires 4 March 2027 [Page 20] Internet-Draft AgentEnvelope Authority and Legitimacy August 2026 Issued authorization asks whether a presented assertion says an action is allowed. Derived authority asks whether the signer could only have been produced from the correct root, domain, and canonical action envelope. Legitimacy asks whether that authority remains admissible now. 21. Security Considerations Implementations MUST treat identity roots, domain seeds, action seeds, actionSeedHex, mint material, bot seeds, and private keys as secret signing material. Implementations MUST NOT log or sync private signing material to hosted services. Implementations SHOULD zero temporary seed buffers after use where the runtime permits. Offline verification does not prove consumption. A signature can be valid and still be a replay if the relying system does not maintain state for nonces, idempotency, or max-use counters. The any-signed-bot mint policy is intentionally open. Issuers that require bot restriction MUST use an address-set policy. Legitimacy state is mutable governance state. Implementations SHOULD maintain state versions, state hashes, signed events, and audit trails so evaluators and auditors can distinguish current legitimacy from historical legitimacy. Legitimacy introduces additional attack surfaces. Implementations SHOULD consider: * executor influence over evidence sources; * forged evidence; * stale or replayed evidence; * conflicting observations; * spoofed producers; * compromised sensors or services; * suppression of unfavorable evidence; * policy drift between state versions; McPhillips Expires 4 March 2027 [Page 21] Internet-Draft AgentEnvelope Authority and Legitimacy August 2026 * state-hash mismatch; * governance evaluator compromise; * governance-event tampering. Evaluators SHOULD sign legitimacy events. Verifiers SHOULD check state hashes and evaluator identity when a governed legitimacy decision depends on mutable state. Evidence used to renew legitimacy SHOULD be sufficiently independent from the executor. Evidence independence is not absolute; it is a policy property defined by the legitimacy profile. Profiles SHOULD describe the trust assumptions under which evidence is considered sufficiently independent. Hosted attestations, when used, sign only the hosted verifier's own statement about facts it computed. They MUST NOT become a required precondition for sovereign verification. 22. IANA Considerations This document has no IANA actions. 23. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, BCP 14, May 2017, . [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, May 2010, . 24. Informative References [FIPS180-4] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", August 2015, . McPhillips Expires 4 March 2027 [Page 22] Internet-Draft AgentEnvelope Authority and Legitimacy August 2026 [SEC2] Standards for Efficient Cryptography Group, "SEC 2: Recommended Elliptic Curve Domain Parameters", 2010, . [AGENTENVELOPE-SDK] McPhillips, M., "AgentEnvelope SDK and v1 Specification", 2026, . [AGENTENVELOPE-MCP] McPhillips, M., "AgentEnvelope MCP", 2026, . [AGENTENVELOPE-WEB] McPhillips, M., "AgentEnvelope Web", 2026, . Appendix A. Manufacturing Legitimacy Example This appendix illustrates legitimacy as present-tense admissibility. Initial command: robot2.pickUp(trolley4, bay7) signature.valid: true Reality changes: trolley4 is at bay4, not bay7 The executor detects the mismatch: RobotBot local observation: trolley4.location = bay4 trolley4.free = true Evidence supplied only by RobotBot is insufficient: renewal.evidence: insufficient reasonCode: evidence.not_independent reason: executing actor cannot supply the evidence that renews its own legitimacy Independent evidence authorities confirm reality: WarehouseFeed -> trolley4 at bay4, free=true DockSafetyController -> trolley4 at bay4, free=true The governance evaluator reviews the original command: McPhillips Expires 4 March 2027 [Page 23] Internet-Draft AgentEnvelope Authority and Legitimacy August 2026 signature.valid: true legitimacy.decision: denied reasonCode: state.mismatched reason: trolley4 is at bay4, not bay7 The old command stays cryptographically valid, but its legitimacy state is suspended. PlannerBot proposes a corrected command: robot2.pickUp(trolley4, bay4) Governance creates a fresh legitimacy basis using independent evidence: signature.valid: true legitimacy.decision: allowed reasonCode: state.current This example demonstrates: * cryptographic validity is not the same thing as operational legitimacy; * legitimacy can change when reality changes; * the executor can detect and refuse, but must not self-authorize renewal; * sufficiently independent evidence should feed renewed governance; * audit records should preserve both the valid old signature and the denied legitimacy decision. Author's Address Matthew McPhillips BlackBox Engineering Email: mattmcp@blackboxengineering.co.uk URI: https://agentenvelope.io McPhillips Expires 4 March 2027 [Page 24]