B
We are entering a new era of autonomous systems. Centralized systems now operate sub‑decentralized components that automate workflows, workers, runtimes, and processes. These systems already exist around us. What’s new is agentic capabilities.
Agentic capabilities, put simply, allow a system to choose actions rather than wait on explicit instructions, and this is attractive because agency collapses human bottlenecks. The next bottleneck is traditional IAM, which is built for users and not machines.
This article introduces a new category: IAM for Autonomous Systems, where authority is derived, not issued. It explains why derived authority is the scalable trust primitive for autonomy.
A warehouse operator tells a robot:
The command is valid, it came from the correct system, and it has been signed by the correct authority. However, after this instruction was created, a real-world error occurred, and when the robot reached bay 7, there was no trolley there to be collected.
Traditional IAM cannot tell us very much about that. The robot had the credential, so the API accepted it, which means the command was allowed. That is not ideal for a manufacturing flow, as it requires further layers of checks, safeguards, and compensating controls bolted on to cover IAM's blind spots. For multiple hosted agents that are designed to operate under orchestrated permissions, the complexity becomes extremely difficult to scale.
It is apparent that autonomous systems need authorisation to answer deeper questions such as:
Authority is a social contract, not a protocol. We humans seem to intuitively understand authority as something that should be granted, issued, or delegated by someone else higher up the chain. This explains why all of our systems revolve around OAuth flows, API keys, JWTs, secrets, and passwords, for these are all projections of human authority models.
Naturally, we pushed our worldview onto machines, and identity systems were built for people. However, the problem we are facing today is that autonomous systems have no users.
OAuth, API keys, and long-lived service secrets assume a human logs in, or a service holds a credential representing broad access. These models may work for people, but they are fundamentally mismatched with systems that act independently and continuously without human presence. The problem is that not only can credentials leak, be shared, or be copied, but also that issued credentials are the wrong shape for a machine actor because they represent broad, standing access, when what an autonomous action only needs is a narrow, verifiable boundary.
Autonomous agents do not wait. They act.
Agents, bots, robots, workflow runners, and service agents today authenticate using human-centric IAM flows designed for browsers and dashboards. That is borrowed authority, not autonomy. Autonomy needs a different model entirely.
There is also a structural scaling problem as issued authority requires an issuer in the loop, and every credential is an issuance transaction that must be requested, stored, rotated, revoked, and checked. That is manageable when credentials are few and long-lived. But autonomous systems need the opposite; they need narrow, per-action authority.
Under an issuance model, per-action scoping means an issuance call for every action. The issuer becomes the throughput ceiling, the availability dependency, and the single point of compromise for the entire fleet. Systems that issue tokens can claim the name "IAM for autonomous systems", but they cannot scale to it. Derivation removes the issuer from the loop entirely: a capability is computed locally from parent authority material and the action's canonical description as a hash operation, not a service call, hence computationally free.
Authority should be derived, not issued.
Software should not wait for a server to issue authority. That is the premise of AgentEnvelope's approach, where software carries an authority that is derived from a root the customer holds and a canonical description of the action itself.
While issued authority gives machines broad bearer tokens, derived authority gives machines scoped capabilities. AgentEnvelope defines the boundary of the action: who is acting, what operation is allowed, which resources are within scope, when the authority is valid, and what use limits are declared. This example is drawn directly from the protocol's published test vectors:
The envelope is not metadata attached to a credential. It is the credential. It is the permission boundary from which the action identity is derived. Identical inputs produce identical public action identities, and different inputs produce different identities.
One honest detail is declared right there in the envelope:
Verification can happen offline.
No token introspection endpoint is required. No shared secret has to be handed to the verifier. The verifier checks the math. This is IAM rebuilt for autonomy, where authority is derived and not issued.
If a broad API key leaks, the attacker inherits everything that key touches. They do not need to understand the original task, nor do they need to stay within the user’s intent. The credential is enough on its own.
A scoped action capability behaves differently. If it leaks, the blast radius is only the action envelope itself:
That is a substantial difference, and it matters when autonomous systems are allowed to act at machine speed.
Agents do not make one request. They chain actions together. They call tools. They trigger workflows. They pass work to other agents. A single broad credential in that loop can become a very large failure very quickly. Scoped authority gives each action its own boundary.
AgentEnvelope uses deterministic cryptography to define authority.
Each capability is derived using HKDF SHA256, which transforms parent authority material and the canonical form of the action envelope into a unique child signing key. Once derived, that capability becomes its own asymmetric signing identity on the secp256k1 curve, with a public address derived via Keccak 256, the same address construction Ethereum uses.
The result is a mathematically isolated permission that can be verified offline. The verifier checks the signature against the derived agent address and the public action record. If the signature, the address, the record, the time window, and the declared scope all match, then the action is valid. Otherwise, the action is invalid and fails.
This is what authority derived, not issued, means in practice.
A note on scope, because capability tokens will come to mind: formats such as Macaroons, Biscuit, and UCAN also express scoped permissions, and they do it well. But they are issued artifacts; a service or principal mints a token and hands it to the holder, and the surrounding system remains custodial.
The claim here is not about token formats; it is about the system. In AgentEnvelope, there is no token carrying the permission, because the permission is the key: the signing identity for an action exists only because that exact envelope was derived from the customer's root. There is nothing to issue, no issuance service to compromise, and no way for an issuer to mis-scope what the mathematics will not derive.
Every action envelope can produce a public record. The private capability signs the action, the public record verifies it, and the record proves the boundary of authority without exposing seeds or private material.
That separation is the core design:
This is where AgentEnvelope's portal becomes useful. The SDK can run completely offline. A team can derive capabilities, sign actions, and verify signatures without an AgentEnvelope account or hosted API. But once autonomous systems are operating across teams, services, robots, workflows, or customers, local proof is not always enough. Someone needs to know what was authorised, what acted, when it acted, and whether the evidence still holds.
The portal provides that hosted governance head.
It stores public records, mint receipts, legitimacy state, audit events, and ledger entries. It does not store the root, the domain seed, the action seed, mint material, bot seeds, or private capabilities. The system can prove that an action was in scope without revealing the private material that created the authority. That is the point of the split:
A signature can prove that an action came from the correct authority. It cannot prove that reality has not changed.
In the initial robot and trolley example, the robot may hold a valid command to collect a trolley from bay seven while sensors now show the trolley is in bay four. That action remains cryptographically valid as signed evidence, but governance should deny execution because the current evidence no longer supports the command.
AgentEnvelope separates cryptographic validity from hosted legitimacy.
Validity asks:
Legitimacy asks:
The portal is where that legitimacy state can be recorded, patched, suspended, superseded, or closed as reality changes.
This distinction is essential for autonomous governance. A command can be valid and still no longer legitimate.
AgentEnvelope is not only local cryptography; autonomous systems can leave hosted records.
After a hosted mint, a bot can publish remote mint delegate public records through the hosted route, meaning the autonomous system can leave a verifier‑safe record of what it was allowed to do without a human manually publishing the record afterwards. The action can still be cryptographically verified locally without the hosted record. With the hosted record, the organization gets a shared governance trail. It is a product jump from "offline signing library" to "governance head for autonomous systems."
An autonomous system does not borrow the human key. It holds its own bot key.
A human, domain owner, or governance process signs a mint delegate that grants the bot a bounded authority envelope, and the bot acts with its own key. The delegate proves the boundary, the action envelope proves the operation, and the hosted record proves what has happened.
For teams that need oversight, a hosted governance head can add shared records without breaking sovereignty.
In AgentEnvelope, the AgentEnvelope Portal provides one implementation of that governance head. It lets the user create a browser‑held vault that is the source of authority, creating a sovereign root used by the SDK to derive domains, delegates, action envelopes, mint material, and action capabilities.
Unlocking the vault locally allows the same authority path to be re‑derived and replayed from canonical evidence that is verifiable from the original root, because authority that cannot be replayed from its own evidence cannot be trusted.
The portal is where the user creates and manages the vault, but the vault remains browser‑held. The hosted service may store encrypted vault ciphertext for continuity, but it cannot decrypt it and never receives the vault passphrase or sovereign root. Hosted functions do not receive domain seeds, action seeds, mint material, bot seeds, or private capabilities.
They work with the public side of the authority chain: domain projections, signed delegates, public records, legitimacy state, mint receipts, verification events, and ledgers. The portal can record what was authorised, verify what was signed, track legitimacy state, issue receipts, expose audit exports, and revoke delegates when needed, but it does not become the source of authority.
Every derived action can produce a cryptographic receipt. Hosted attestations can be added and verified.
Compliance teams get visibility without taking custody of the keys.
AgentEnvelope has three practical surfaces:
The SDK and MCP server are fully open source under Apache 2.0, making the authority model inspectable, reproducible, and usable without the hosted portal. The web portal is my own governance implementation using the SDK.
AI agents were the spark, but delegated action is the category. This protocol is applicable in any system that needs to carry bounded, verifiable authority, such as workers, workflows, tools, links, devices, services, or agents.
The SDK was intentionally kept as a compact sovereign engine for wider application. For example, ProjectEnvelope uses it to create neutral permissioned URL links and authority‑stamped media, letting files, pages, and shared project material carry verifiable proof without exposing private signing authority.
The protocol is also published as an IETF Internet Draft: Deterministic Derived Authority for Autonomous Systems.
The SDK is the substrate. MCP is the runtime bridge. The portal is the governance head.
Autonomous systems schedule workloads, migrate containers, approve deployments, rebalance queues, coordinate with other agents, and interact with physical systems. Yet most of these systems still authenticate using borrowed human credentials, API keys, bearer tokens, service accounts, and IAM flows that were designed for browsers and static services.
AgentEnvelope marks the shift from human IAM to machine native authority. Derived authority is the missing layer for autonomous systems with runtimes, workers, agents, or LLMs acting as agents. It is the trust primitive autonomy has been missing, and the one that lets it grow safely.
Back in the warehouse, a robot receives a signed instruction that reality has contradicted:
Then the robot gathers fresh evidence:
AgentEnvelope patches the old legitimacy state as
The old command stayed signed and still cryptographically valid, but it was no longer legitimate. An autonomous system cannot stop there, so the bot gathered evidence and issued a new command under a fresh legitimacy state.
Autonomous systems are forcing IAM to evolve. The move from issued authority to derived authority is becoming a structural requirement for machines that act faster than any human can supervise. IAM for autonomous systems will become a foundational layer of infrastructure as autonomy spreads into agents, robots, workflows, and distributed runtimes.
AgentEnvelope is the first open protocol in this category, which is now inevitable.
IAM for autonomous systems where authority is derived, not issued.
The SDK and MCP server are Apache 2.0, the protocol is published as an IETF Internet Draft, and the method is open for developers, researchers, and autonomous system builders to inspect, fork, and explore.
Agentic capabilities, put simply, allow a system to choose actions rather than wait on explicit instructions, and this is attractive because agency collapses human bottlenecks. The next bottleneck is traditional IAM, which is built for users and not machines.
This article introduces a new category: IAM for Autonomous Systems, where authority is derived, not issued. It explains why derived authority is the scalable trust primitive for autonomy.
A Small Failure That Explains The Problem
A warehouse operator tells a robot:
Code:
robot2.pickUp(trolley4, bay7)The command is valid, it came from the correct system, and it has been signed by the correct authority. However, after this instruction was created, a real-world error occurred, and when the robot reached bay 7, there was no trolley there to be collected.
Traditional IAM cannot tell us very much about that. The robot had the credential, so the API accepted it, which means the command was allowed. That is not ideal for a manufacturing flow, as it requires further layers of checks, safeguards, and compensating controls bolted on to cover IAM's blind spots. For multiple hosted agents that are designed to operate under orchestrated permissions, the complexity becomes extremely difficult to scale.
It is apparent that autonomous systems need authorisation to answer deeper questions such as:
- Was this exact action authorised?
- Is the authority scoped to this operation?
- Is the evidence still current?
- Has reality contradicted the assumption behind the command?
The Problem With Human IAM
Authority is a social contract, not a protocol. We humans seem to intuitively understand authority as something that should be granted, issued, or delegated by someone else higher up the chain. This explains why all of our systems revolve around OAuth flows, API keys, JWTs, secrets, and passwords, for these are all projections of human authority models.
Naturally, we pushed our worldview onto machines, and identity systems were built for people. However, the problem we are facing today is that autonomous systems have no users.
OAuth, API keys, and long-lived service secrets assume a human logs in, or a service holds a credential representing broad access. These models may work for people, but they are fundamentally mismatched with systems that act independently and continuously without human presence. The problem is that not only can credentials leak, be shared, or be copied, but also that issued credentials are the wrong shape for a machine actor because they represent broad, standing access, when what an autonomous action only needs is a narrow, verifiable boundary.
Autonomous agents do not wait. They act.
Agents, bots, robots, workflow runners, and service agents today authenticate using human-centric IAM flows designed for browsers and dashboards. That is borrowed authority, not autonomy. Autonomy needs a different model entirely.
There is also a structural scaling problem as issued authority requires an issuer in the loop, and every credential is an issuance transaction that must be requested, stored, rotated, revoked, and checked. That is manageable when credentials are few and long-lived. But autonomous systems need the opposite; they need narrow, per-action authority.
Under an issuance model, per-action scoping means an issuance call for every action. The issuer becomes the throughput ceiling, the availability dependency, and the single point of compromise for the entire fleet. Systems that issue tokens can claim the name "IAM for autonomous systems", but they cannot scale to it. Derivation removes the issuer from the loop entirely: a capability is computed locally from parent authority material and the action's canonical description as a hash operation, not a service call, hence computationally free.
Authority should be derived, not issued.
The Shift To Derived Authority
Software should not wait for a server to issue authority. That is the premise of AgentEnvelope's approach, where software carries an authority that is derived from a root the customer holds and a canonical description of the action itself.
While issued authority gives machines broad bearer tokens, derived authority gives machines scoped capabilities. AgentEnvelope defines the boundary of the action: who is acting, what operation is allowed, which resources are within scope, when the authority is valid, and what use limits are declared. This example is drawn directly from the protocol's published test vectors:
Code:
{
"type": "agentenvelope.actionEnvelope",
"version": 1,
"agentId": "support-sender",
"domain": {
"domainId": "support-ops",
"domainHash": "0x3fa9eeed97ac81422a6838aa6cd81adb4abcf3fd42cdd8e0f234889997166dae"
},
"actionIndex": 0,
"operation": "send-message",
"resources": ["channel:support", "thread:customer-123"],
"timeWindow": {
"notBefore": 1786924800000,
"notAfter": 1798761599000
},
"decayPolicy": { "mode": "BOTH" },
"limits": { "maxUses": 1, "enforcement": "external" }
}The envelope is not metadata attached to a credential. It is the credential. It is the permission boundary from which the action identity is derived. Identical inputs produce identical public action identities, and different inputs produce different identities.
One honest detail is declared right there in the envelope:
"enforcement": "external". Use limits are declared in the envelope and enforced by the relying system. The protocol makes the declared boundary cryptographically verifiable; it does not pretend the boundary is self‑executing.Verification can happen offline.
No token introspection endpoint is required. No shared secret has to be handed to the verifier. The verifier checks the math. This is IAM rebuilt for autonomy, where authority is derived and not issued.
Scoped Authority Changes The Blast Radius
If a broad API key leaks, the attacker inherits everything that key touches. They do not need to understand the original task, nor do they need to stay within the user’s intent. The credential is enough on its own.
A scoped action capability behaves differently. If it leaks, the blast radius is only the action envelope itself:
Code:
[ one operation, one resource scope, one time window, one declared limit ].That is a substantial difference, and it matters when autonomous systems are allowed to act at machine speed.
Agents do not make one request. They chain actions together. They call tools. They trigger workflows. They pass work to other agents. A single broad credential in that loop can become a very large failure very quickly. Scoped authority gives each action its own boundary.
The Cryptographic Core
AgentEnvelope uses deterministic cryptography to define authority.
Each capability is derived using HKDF SHA256, which transforms parent authority material and the canonical form of the action envelope into a unique child signing key. Once derived, that capability becomes its own asymmetric signing identity on the secp256k1 curve, with a public address derived via Keccak 256, the same address construction Ethereum uses.
The result is a mathematically isolated permission that can be verified offline. The verifier checks the signature against the derived agent address and the public action record. If the signature, the address, the record, the time window, and the declared scope all match, then the action is valid. Otherwise, the action is invalid and fails.
This is what authority derived, not issued, means in practice.
A note on scope, because capability tokens will come to mind: formats such as Macaroons, Biscuit, and UCAN also express scoped permissions, and they do it well. But they are issued artifacts; a service or principal mints a token and hands it to the holder, and the surrounding system remains custodial.
The claim here is not about token formats; it is about the system. In AgentEnvelope, there is no token carrying the permission, because the permission is the key: the signing identity for an action exists only because that exact envelope was derived from the customer's root. There is nothing to issue, no issuance service to compromise, and no way for an issuer to mis-scope what the mathematics will not derive.
Private Authority Signs. Public Records Verify.
Every action envelope can produce a public record. The private capability signs the action, the public record verifies it, and the record proves the boundary of authority without exposing seeds or private material.
That separation is the core design:
Code:
private authority signs
public records verifyThis is where AgentEnvelope's portal becomes useful. The SDK can run completely offline. A team can derive capabilities, sign actions, and verify signatures without an AgentEnvelope account or hosted API. But once autonomous systems are operating across teams, services, robots, workflows, or customers, local proof is not always enough. Someone needs to know what was authorised, what acted, when it acted, and whether the evidence still holds.
The portal provides that hosted governance head.
It stores public records, mint receipts, legitimacy state, audit events, and ledger entries. It does not store the root, the domain seed, the action seed, mint material, bot seeds, or private capabilities. The system can prove that an action was in scope without revealing the private material that created the authority. That is the point of the split:
- SDK = sovereign authority
- Portal = hosted governance
Legitimacy: When Valid Is Not Enough
A signature can prove that an action came from the correct authority. It cannot prove that reality has not changed.
In the initial robot and trolley example, the robot may hold a valid command to collect a trolley from bay seven while sensors now show the trolley is in bay four. That action remains cryptographically valid as signed evidence, but governance should deny execution because the current evidence no longer supports the command.
AgentEnvelope separates cryptographic validity from hosted legitimacy.
Validity asks:
Code:
Did the right authority sign this exact action?Legitimacy asks:
Code:
Is this action still admissible under current evidence?The portal is where that legitimacy state can be recorded, patched, suspended, superseded, or closed as reality changes.
This distinction is essential for autonomous governance. A command can be valid and still no longer legitimate.
Autonomous Systems Can Leave Their Own Records
AgentEnvelope is not only local cryptography; autonomous systems can leave hosted records.
After a hosted mint, a bot can publish remote mint delegate public records through the hosted route, meaning the autonomous system can leave a verifier‑safe record of what it was allowed to do without a human manually publishing the record afterwards. The action can still be cryptographically verified locally without the hosted record. With the hosted record, the organization gets a shared governance trail. It is a product jump from "offline signing library" to "governance head for autonomous systems."
An autonomous system does not borrow the human key. It holds its own bot key.
A human, domain owner, or governance process signs a mint delegate that grants the bot a bounded authority envelope, and the bot acts with its own key. The delegate proves the boundary, the action envelope proves the operation, and the hosted record proves what has happened.
Governance Without Custody
For teams that need oversight, a hosted governance head can add shared records without breaking sovereignty.
In AgentEnvelope, the AgentEnvelope Portal provides one implementation of that governance head. It lets the user create a browser‑held vault that is the source of authority, creating a sovereign root used by the SDK to derive domains, delegates, action envelopes, mint material, and action capabilities.
Unlocking the vault locally allows the same authority path to be re‑derived and replayed from canonical evidence that is verifiable from the original root, because authority that cannot be replayed from its own evidence cannot be trusted.
The portal is where the user creates and manages the vault, but the vault remains browser‑held. The hosted service may store encrypted vault ciphertext for continuity, but it cannot decrypt it and never receives the vault passphrase or sovereign root. Hosted functions do not receive domain seeds, action seeds, mint material, bot seeds, or private capabilities.
They work with the public side of the authority chain: domain projections, signed delegates, public records, legitimacy state, mint receipts, verification events, and ledgers. The portal can record what was authorised, verify what was signed, track legitimacy state, issue receipts, expose audit exports, and revoke delegates when needed, but it does not become the source of authority.
Every derived action can produce a cryptographic receipt. Hosted attestations can be added and verified.
Compliance teams get visibility without taking custody of the keys.
SDK, MCP, And Portal
AgentEnvelope has three practical surfaces:
- The
agent-envelope-sdk, published on npm, provides the offline cryptographic primitives. - The
agent-envelope-mcp, published on npm, exposes those primitives to agent and tool runtimes. - The agentenvelope.io web portal, which provides hosted governance for teams that need shared legitimacy state, public records, mint receipts, ledgers, and audit exports without taking custody of private authority.
The SDK and MCP server are fully open source under Apache 2.0, making the authority model inspectable, reproducible, and usable without the hosted portal. The web portal is my own governance implementation using the SDK.
AI agents were the spark, but delegated action is the category. This protocol is applicable in any system that needs to carry bounded, verifiable authority, such as workers, workflows, tools, links, devices, services, or agents.
The SDK was intentionally kept as a compact sovereign engine for wider application. For example, ProjectEnvelope uses it to create neutral permissioned URL links and authority‑stamped media, letting files, pages, and shared project material carry verifiable proof without exposing private signing authority.
The protocol is also published as an IETF Internet Draft: Deterministic Derived Authority for Autonomous Systems.
The SDK is the substrate. MCP is the runtime bridge. The portal is the governance head.
The Road Ahead
Autonomous systems schedule workloads, migrate containers, approve deployments, rebalance queues, coordinate with other agents, and interact with physical systems. Yet most of these systems still authenticate using borrowed human credentials, API keys, bearer tokens, service accounts, and IAM flows that were designed for browsers and static services.
AgentEnvelope marks the shift from human IAM to machine native authority. Derived authority is the missing layer for autonomous systems with runtimes, workers, agents, or LLMs acting as agents. It is the trust primitive autonomy has been missing, and the one that lets it grow safely.
Back in the warehouse, a robot receives a signed instruction that reality has contradicted:
Code:
robot2.pickUp(trolley4, bay7)
signature.valid: true
legitimacy.decision: denied
reasonCode: state.mismatched
reason: trolley4 is at bay4, not bay7Then the robot gathers fresh evidence:
Code:
request trolley4 location -> bay4
check trolley4 free -> trueAgentEnvelope patches the old legitimacy state as
suspended with reason state.mismatched, then proposes:
Code:
robot2.pickUp(trolley4, bay4)
signature.valid: true
legitimacy.decision: allowedThe old command stayed signed and still cryptographically valid, but it was no longer legitimate. An autonomous system cannot stop there, so the bot gathered evidence and issued a new command under a fresh legitimacy state.
Autonomous systems are forcing IAM to evolve. The move from issued authority to derived authority is becoming a structural requirement for machines that act faster than any human can supervise. IAM for autonomous systems will become a foundational layer of infrastructure as autonomy spreads into agents, robots, workflows, and distributed runtimes.
AgentEnvelope is the first open protocol in this category, which is now inevitable.
IAM for autonomous systems where authority is derived, not issued.
The SDK and MCP server are Apache 2.0, the protocol is published as an IETF Internet Draft, and the method is open for developers, researchers, and autonomous system builders to inspect, fork, and explore.