AgentEnvelope: Deterministic Derived Authority for Autonomous Systems

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.

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

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.

Cryptographic Primitives AgentEnvelope v1 uses the following primitives:

HKDF-SHA256 for key derivation.
The derivation salt string agentenvelope-v1.
SHA-256 for content hashes.
Keccak-256 for signed message hashes.
secp256k1 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.

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. canonicalizes to:

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: The signature format is 0x plus 32-byte r, 32-byte s, and a 1-byte recovery id encoded as 27 or 28.

Authority Tree The AgentEnvelope authority path is: 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.

Domain Derivation A DomainInfo object is the immutable canonical input for domain derivation: The domain seed is derived as: The domain hash is SHA-256 over canonicalJSON(domainInfo). The domain address is the v1 secp256k1 address of domainSeed.

Action Envelope An ActionEnvelope is the complete immutable permission input for one deterministic action key. 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: 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.

Public Action Record A PublicActionRecord is verifier-safe metadata for one action capability. 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.

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.

Mint Delegation Mint delegation lets a bot request bounded action capabilities without receiving the vault root or domain seed. Mint material is derived as: 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:

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.

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.

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.

IANA Considerations This document has no IANA actions.