AgentEnvelope: Deterministic Derived Authority for Autonomous Systems

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.¶

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.¶

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.¶

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¶

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.¶

{
  "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.¶

{
  "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
)

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.¶

17. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, BCP 14, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC5869]

Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, May 2010, <https://www.rfc-editor.org/rfc/rfc5869>.

18. Informative References

[FIPS180-4]

National Institute of Standards and Technology, "Secure Hash Standard (SHS)", August 2015, <https://csrc.nist.gov/publications/detail/fips/180/4/final>.

[SEC2]

Standards for Efficient Cryptography Group, "SEC 2: Recommended Elliptic Curve Domain Parameters", 2010, <https://www.secg.org/sec2-v2.pdf>.

[AGENTENVELOPE-SDK]

McPhillips, M., "AgentEnvelope SDK and v1 Specification", 2026, <https://github.com/BlackBoxEngineering/agent-envelope-sdk>.