Derived Authority
A Cryptographic Model Without Custody
Modern authentication systems often depend on issued secrets. Whether those secrets take the form of bearer tokens, refresh tokens, API keys, or session credentials, the issuer becomes part of the authority surface. If broad reusable credentials leak, the blast radius can be much larger than the single task an actor needed to perform.
AI agents created the immediate pressure, but they are not the boundary of the model. In AgentEnvelope, an agent is a bounded action identity: encrypted key material plus verifier-safe public record, scoped to a domain, operation, resources, time window, and limits. That shape applies to chatbots, backend workers, workflow steps, car keys, hotel keys, device unlocks, and machine-to-machine instructions.
AgentEnvelope reduces that risk by deriving scoped signing identities from a customer-held root. Derivation is deterministic and one-way: a child seed cannot recover its parent, and sibling seeds cannot be inferred from each other.
1. Architectural Overview
AgentEnvelope's authority model is built on HKDF-SHA256 for deterministic key derivation, secp256k1 for signing and public-key recovery, and Keccak-256 for Ethereum-style address derivation. These are standard, widely reviewed primitives. AgentEnvelope uses them with domain-separated messages rather than custom cryptography.
identityRoot (32 bytes, customer-held) | +-- HKDF(root, domainInfo) -> domainSeed | | | +-- HKDF(domain, envelopeInfo) -> actionSeed | | | +-- secp256k1.sign() -> signature | +-- more domains
Each domain, each action, and each delegated capability is cryptographically siloed.
2. Threat Model
Server breach
Traditional: Database breach can expose stored tokens. Attackers may gain reusable authority.
AgentEnvelope: There is no issued authority token to steal. Customer authority seeds are not stored server-side; the hosted API receives public records, payloads, signatures, and expected addresses, not vault roots or action seeds.
Token replay
Traditional: Bearer tokens are transferable. If intercepted, they can be replayed until revoked.
AgentEnvelope: Each signature is bound to a canonical payload and signing context. It cannot authorize a different payload; exact-payload replay is handled with time windows, nonces, idempotency, or application policy.
Privilege escalation
Traditional: A compromised credential often grants broad access across services.
AgentEnvelope: Capabilities are domain-scoped. Compromising one action seed yields no information about any other domain or action.
Revocation lag
Traditional: Revocation requires propagation across distributed systems.
AgentEnvelope: Authority can be time-bounded by the action envelope. Immediate revocation remains a verifier or hosted-governance policy question, but the default blast radius is smaller.
Man-in-the-middle
Traditional: MITM attackers can replay bearer tokens into unrelated requests.
AgentEnvelope: Signatures are bound to canonical JSON payloads. A captured signature fails if the payload changes even slightly.
Supply chain compromise
Traditional: Injected code can exfiltrate broad human or service tokens.
AgentEnvelope: A compromised worker can expose only the scoped capability or delegate it was given, not the vault root or sibling capabilities.
3. Prefix Isolation
Different signing contexts use different prefixes to prevent cross-context replay. A delegate signature cannot pass as an action signature. A mint request cannot be replayed as a delegate.
| Context | Prefix |
|---|---|
| Action signing | \x19AgentEnvelope Signed Message:\n |
| Delegate issuance | \x19AgentEnvelope Mint Delegate:\n |
| Mint request | \x19AgentEnvelope Mint Request:\n |
| Receipt attestation | \x19AgentEnvelope Attestation:\n |
4. Verification Without Custody
Action verification is recovery-based. The verifier needs only the payload, signature, expected address, and public record. It does not need the seed, a shared secret, or a hosted AgentEnvelope key.
recoveredPubKey = secp256k1.recover(prefixedHash, signature) recoveredAddress = keccak256(recoveredPubKey)[12..32] valid = (recoveredAddress === expectedAddress)
This differs from systems where validation depends on issuer-side state or shared validation secrets. AgentEnvelope can verify a signed action offline against the public record.
For action verification, authority is proven by capability. The signer proves it holds the scoped seed that can sign this payload; it does not need to disclose the vault root, domain seed, or any sibling capability.
5. Two Operating Modes
Sovereign
Fully offline with the Apache-2.0 SDK and MCP server. Derive keys, sign actions, and verify signatures without any account, API key, or network. Authority stays with the customer-held root and derived capabilities.
Governed
Published attester: 0x2332d1b716a49a520d9a2de6baebeb5bdafdf994
Optional hosted layer. Adds API-keyed minting, attestation receipts, ledgers, audit exports, and enforcement. The hosted API validates permits and returns receipts; it never receives vault roots, domain seeds, action seeds, or mint material.
API keys meter and protect the hosted service. Signatures prove authority.
Account login, billing, and API-key rotation are operational controls for the hosted portal, not the source of authority. AgentId, a digital identity wallet currently in production, can add an optional wallet-native governance route through the portal without changing the sovereign SDK substrate.
Anyone can build their own governance layer on top of the sovereign substrate.
6. What Never Goes to the Hosted API
identityRoot <- never sent domainSeed <- derived locally, used, zeroed passphrase <- never sent mintMaterial <- given to the bot out-of-band, never sent to hosted API actionSeed <- derived locally, never transmitted
The hosted API is not a custodian of customer signing authority. It stores governance state, public records, receipts, and encrypted workspace data, not the seeds that create authority.
7. Prior Art
AgentEnvelope builds on established cryptographic patterns. The value is in applying them to delegated action authority, scoped action envelopes, and hosted governance, not in inventing new cryptography.
| System | Relationship |
|---|---|
| BIP-32 | Hierarchical deterministic derivation - AgentEnvelope applies the pattern to delegated action authority, not wallet accounts. |
| SPIFFE | Workload identity - AgentEnvelope adds scoped action envelopes and decay bounds. |
| OAuth 2.0 | Token issuance - AgentEnvelope replaces broad bearer authority with derived signing capability. |
| HKDF (RFC 5869) | Key derivation - used directly. |
| Ethereum-style addresses | secp256k1 public-key recovery and Keccak-256 address derivation. |
8. Synthesis
| Property | Traditional Tokens | AgentEnvelope |
|---|---|---|
| Issued authority tokens | Often stored or issued by a server | No issued authority token to steal; customer roots and action seeds are not stored by AgentEnvelope |
| Breach amplification | Broad tokens can be exposed | Hosted breach should not expose vault roots, domain seeds, or action seeds |
| Token replay | Bearer token works until rejected | Signature is bound to payload and context; exact replay needs nonce or idempotency policy |
| Lateral movement | Credential reuse | Hierarchical isolation |
| Cross-context misuse | Possible | Prefix isolation prevents |
| Revocation lag | Propagation required | Time windows reduce standing authority |
| Verification | Issuer or shared secret often involved | Recovery-based, no shared secret for action verification |
Packages
Sovereign mode is available through the Apache-2.0 SDK and MCP server.
Start deriving authority.
Use the SDK offline, or open the portal when you need hosted governance.