Network Working Group M. McPhillips Internet-Draft BlackBox Engineering Intended status: Informational 17 August 2026 Expires: 18 February 2027 AgentEnvelope: Deterministic Derived Authority for Autonomous Systems draft-mcphillips-agentenvelope-derived-authority-00 Abstract AgentEnvelope defines a deterministic derived-authority model for autonomous and action-performing systems. Instead of issuing bearer credentials or authorization envelopes 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, or hosted service access. This document specifies the v1 derivation model, signing domains, public record structure, mint delegation flow, verification rules, and security considerations. 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 18 February 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. McPhillips Expires 18 February 2027 [Page 1] Internet-Draft AgentEnvelope Derived Authority August 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Cryptographic Primitives . . . . . . . . . . . . . . . . . . 4 5. Canonical JSON . . . . . . . . . . . . . . . . . . . . . . . 4 6. Signing Domains . . . . . . . . . . . . . . . . . . . . . . . 4 7. Authority Tree . . . . . . . . . . . . . . . . . . . . . . . 5 8. Domain Derivation . . . . . . . . . . . . . . . . . . . . . . 5 9. Action Envelope . . . . . . . . . . . . . . . . . . . . . . . 5 10. Public Action Record . . . . . . . . . . . . . . . . . . . . 6 11. Verification . . . . . . . . . . . . . . . . . . . . . . . . 7 12. Mint Delegation . . . . . . . . . . . . . . . . . . . . . . . 7 13. Hosted Governance Boundary . . . . . . . . . . . . . . . . . 8 14. Relationship to Issued Authorization Containers . . . . . . . 8 15. Security Considerations . . . . . . . . . . . . . . . . . . . 9 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 17. Normative References . . . . . . . . . . . . . . . . . . . . 9 18. Informative References . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Autonomous software agents, workflow steps, backend workers, bots, devices, 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. This document describes AgentEnvelope v1. It is informational and records an implemented protocol surface. It does not require any particular AI framework, transport, blockchain, hosted service, identity provider, or trust registry. McPhillips Expires 18 February 2027 [Page 2] Internet-Draft AgentEnvelope Derived Authority 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 EVM-style address derived from an action seed. Capability Private action authority held by a worker or bot. Domain A stable authority branch scoped to a class of work. 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 * Derive authority rather than issue bearer credentials. * Keep roots, seeds, and private action material inside customer custody boundaries. * Bind action authority to a complete canonical action envelope. * Allow stateless signature verification from public records. * Keep hosted governance additive, never required for offline verification. * Preserve isolation between domains, actions, and delegated mint capabilities. McPhillips Expires 18 February 2027 [Page 3] Internet-Draft AgentEnvelope Derived Authority August 2026 4. Cryptographic Primitives AgentEnvelope v1 uses the following primitives: * HKDF-SHA256 [RFC5869] for key derivation. * The derivation salt string agentenvelope-v1. * SHA-256 [FIPS180-4] for content hashes. * Keccak-256 for signed message hashes. * secp256k1 [SEC2] signatures. * An EVM-style address: 0x plus the last 20 bytes of keccak-256 of the uncompressed secp256k1 public key without its leading format byte. All private seeds in v1 are 32-byte byte strings. If a seed is not a valid secp256k1 scalar, an implementation MUST transform it to a valid scalar using HKDF-SHA256 with the same salt and info string key, retrying no more than 8 times. 5. Canonical JSON All derivation, content-hash, and signing inputs MUST use canonical JSON with object keys sorted lexicographically, recursive object canonicalization, array order preserved, normal JSON encoding for primitives, and no added whitespace. {"z":1,"a":{"y":2,"x":3}} canonicalizes to: {"a":{"x":3,"y":2},"z":1} 6. Signing Domains Every signature domain separates its message with an exact UTF-8 prefix before canonical JSON: * Action payload: \x19AgentEnvelope Signed Message:\n * MintDelegate body: \x19AgentEnvelope Mint Delegate:\n * MintRequest body: \x19AgentEnvelope Mint Request:\n * Attestation receipt: \x19AgentEnvelope Attestation:\n McPhillips Expires 18 February 2027 [Page 4] Internet-Draft AgentEnvelope Derived Authority August 2026 The signed hash is: keccak256(utf8(prefix + canonicalJSON(body))) The signature format is 0x plus 32-byte r, 32-byte s, and a 1-byte recovery id encoded as 27 or 28. 7. Authority Tree The AgentEnvelope authority path is: identityRoot -> domainSeed -> actionEnvelope -> actionSeed -> agentAddress The public projection is the domain public summary, action envelope, action envelope hash, and agent address. It MUST NOT include the identity root, passphrase, domain seed, action seed, actionSeedHex, mint material, or private keys. 8. Domain Derivation A DomainInfo object is the immutable canonical input for domain derivation: { "type": "agentenvelope.domainInfo", "version": 1, "namespace": "example", "domainId": "support-ops", "kind": "communication" } The domain seed is derived as: HKDF-SHA256( ikm = identityRoot, salt = "agentenvelope-v1", info = canonicalJSON({ "purpose": "domain", "domainInfo": domainInfo }), length = 32 ) The domain hash is SHA-256 over canonicalJSON(domainInfo). The domain address is the v1 secp256k1 address of domainSeed. 9. Action Envelope An ActionEnvelope is the complete immutable permission input for one deterministic action key. McPhillips Expires 18 February 2027 [Page 5] Internet-Draft AgentEnvelope Derived Authority August 2026 { "type": "agentenvelope.actionEnvelope", "version": 1, "agentId": "support-sender", "domain": { "domainId": "support-ops", "domainHash": "0x..." }, "actionIndex": 0, "operation": "send-message", "resources": ["channel:support", "thread:customer-123"], "timeWindow": { "notBefore": 1786924800000, "notAfter": 1798761599000 }, "decayPolicy": { "mode": "BOTH" }, "limits": { "maxUses": 1, "enforcement": "external" } } Implementations MUST validate that the domain reference matches the selected domain projection, actionIndex is a non-negative integer, resources are non-empty, time-based decay has a finite time boundary, action-based decay has a positive maxUses, and v1 public envelopes use limits.enforcement set to external. The action seed is derived as: HKDF-SHA256( ikm = domainSeed, salt = "agentenvelope-v1", info = canonicalJSON({ "purpose": "action", "actionEnvelope": actionEnvelope }), length = 32 ) Changing the agent id, domain, action index, operation, resources, time window, decay mode, or limits changes the derived action seed and therefore the agent address. 10. Public Action Record A PublicActionRecord is verifier-safe metadata for one action capability. McPhillips Expires 18 February 2027 [Page 6] Internet-Draft AgentEnvelope Derived Authority August 2026 { "type": "agentenvelope.publicActionRecord", "version": 1, "recordId": "ae-action-...", "ownerUserId": "user-...", "custodyMode": "sovereign-browser", "verifierProfile": "domain-action-envelope", "status": "active", "createdAt": "2026-07-24T15:23:00.000Z", "agentId": "support-sender", "agentAddress": "0x...", "domain": { "...": "domain projection" }, "actionEnvelope": { "...": "action envelope" }, "canonicalActionEnvelope": "{...}", "actionEnvelopeHash": "0x...", "expiry": "2026-12-31T23:59:59.000Z" } Public action records MUST NOT contain private signing material. Metadata such as owner id, record id, creation time, and expiry does not enter key derivation. 11. Verification A verifier that holds a public action record, payload, and signature checks the record type and version, record status, action index, canonical action envelope, action envelope hash, optional expected envelope hash, time decay, signature form, and recovered address. These checks are stateless except for time. They prove that a signature matches a public action record and that the record's time boundary is satisfied. They do not prove that a max-use slot is unspent. Systems that require replay prevention or usage exhaustion MUST maintain verifier-controlled or hosted state. 12. Mint Delegation Mint delegation lets a bot request bounded action capabilities without receiving the vault root or domain seed. Mint material is derived as: HKDF-SHA256( ikm = identityRoot, salt = "agentenvelope-v1", info = canonicalJSON({ "purpose": "mint-material", "domainHash": domainHash }), length = 32 ) McPhillips Expires 18 February 2027 [Page 7] Internet-Draft AgentEnvelope Derived Authority August 2026 A MintDelegate is signed by the domain issuer. A MintRequest is signed by the bot. A mint verifier checks both signatures, the bot policy, resource bounds, operation bounds, action index range, max uses, time window containment, nonce replay, and mint count. Nonce replay and mint-count enforcement require state. After a valid delegate and request, the remote-mint action seed is derived as: HKDF-SHA256( ikm = mintMaterial, salt = "agentenvelope-v1", info = canonicalJSON({ "purpose": "remote-mint", "delegateHash": delegateHash, "mintRequest": requestBodyWithoutBotSignature }), length = 32 ) 13. Hosted Governance Boundary Hosted governance may store encrypted workspace state, public action records, stored delegates, verification events, audit events, API key hashes, billing records, and mint ledgers. 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, or private keys. 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 key material. 14. Relationship to Issued Authorization Containers AgentEnvelope is not an issued authorization container. Issued authorization systems can describe an agent'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. The distinction is architectural: issued authorization asks whether a presented assertion says an action is allowed; derived authority asks whether the action signer could only have been produced from the correct root, domain, and canonical action envelope. McPhillips Expires 18 February 2027 [Page 8] Internet-Draft AgentEnvelope Derived Authority August 2026 15. Security Considerations Implementations MUST treat identity roots, domain seeds, action seeds, actionSeedHex, mint material, bot seeds, and private keys as secret signing material. They 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. Hosted attestation, when used, signs only the hosted verifier's own statement about facts it computed. It must not become a precondition for sovereign verification. 16. IANA Considerations This document has no IANA actions. 17. 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, . 18. Informative References [FIPS180-4] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", August 2015, . [SEC2] Standards for Efficient Cryptography Group, "SEC 2: Recommended Elliptic Curve Domain Parameters", 2010, . McPhillips Expires 18 February 2027 [Page 9] Internet-Draft AgentEnvelope Derived Authority August 2026 [AGENTENVELOPE-SDK] McPhillips, M., "AgentEnvelope SDK and v1 Specification", 2026, . Author's Address Matthew McPhillips BlackBox Engineering Email: mattmcp@blackboxengineering.co.uk URI: https://agentenvelope.io McPhillips Expires 18 February 2027 [Page 10]