By Mike Parkhill (Head of Engineering at Dock Labs) and Agne Caunt (Product Owner at Dock Labs)
Suppose Lisa, an office manager, gives an AI agent permission to buy office supplies.
Identifying the agent is only the beginning.
When the agent reaches an external vendor, the harder question is:
Why should the vendor believe this agent is actually allowed to place the order?
An authenticated identity can tell the vendor which agent it is dealing with. It does not prove what Lisa authorized, whether Lisa had the right to delegate that authority, whether the authority changed as it moved through other agents, or whether the vendor should accept it for this transaction.
That is the problem we have been working on: making authorization portable enough to cross an organizational boundary while staying constrained, traceable, revocable, and independently verifiable.
A concrete example
Our test scenario has four fictional actors:
- Quotient, Lisa's employer
- Lisa, an office manager
- Atlas, Lisa's AI agent
- Stockwell, an external vendor
Quotient verifies Lisa and issues an employee verifiable credential to her wallet. It also gives her purchasing authority.
Separately, Quotient's IT system issues an agent identity credential to Atlas's wallet.
Lisa then delegates part of her purchasing authority to Atlas.
We’ve chosen to represent that authority as a verifiable credential: a cryptographically signed credential that another party can independently verify, which makes it useful for carrying trusted authorization across organizational boundaries.
Figure 1. Setup: identity and authority are separate
The key idea is that Atlas's identity and Atlas's delegated authority are separate artifacts.
Atlas now has two different things:
- Agent identity
- Delegated purchasing authority
The identity answers:
Which agent is this?
The delegated credential answers:
What is this agent allowed to do, and where did that authority come from?
Later, Atlas approaches Stockwell.
Figure 2. Transaction verification flow
Atlas presents identity and delegated authority. Stockwell verifies the chain and policy before acting.
If the delegation is valid and the purchase fits both the delegated scope and Stockwell's own policy, Stockwell can continue.
The interesting part starts when authority can be delegated more than once.
Delegation is another credential issuance
Suppose Lisa can spend up to $100.
If she delegates an $80 limit to Atlas, Lisa becomes the issuer of Atlas's delegated credential.
If Atlas is allowed to re-delegate, Atlas can issue another delegated credential to the next agent.
Every delegated credential contains two attributes:
- rootCredentialId
- previousCredentialId
rootCredentialId points to the original credential from which the authority comes.
previousCredentialId points to the immediate parent.
So a downstream credential is not just an isolated claim that says: "I am allowed to spend $80".
It carries links that let the verifier reason about where that authority came from.
Figure 3. Delegation chain and credential linkage
rootCredentialId tracks the origin of authority. previousCredentialId tracks the immediate parent.
Cryptography does not remove trust
It changes where trust has to exist.
If Stockwell traces Atlas's authority through Lisa to a credential issued by Quotient, Stockwell still needs a reason to trust Quotient as an authority for that claim.
The signatures and credential links can establish integrity and where the authority came from. They cannot answer:
Should Stockwell trust Quotient to issue this kind of authority?
That decision still depends on governance: ecosystem membership, a registry, a business relationship, or some other trust framework.
Cryptography can prove that an authority chain really descends from a chosen trust root. It cannot choose that trust root for you.
A valid delegation can only get narrower
Once authority moves through several hops, one rule becomes essential:
A delegation is valid only if authority does not expand as it moves down the chain.
If Lisa can spend $100, she cannot validly give Atlas a $120 limit.
If Atlas receives $80, Atlas cannot validly give the next agent $100.
Figure 4. Authority can only narrow
Authority may narrow as it moves down the chain, but it cannot validly expand.
We use Cedar for the rules
We use Cedar to express the rules associated with delegatable credentials rather than inventing a new policy language.
A simplified policy might describe:
- role: purchasing_delegate
- Constraints:
- max_purchase: 100
- redelegation_allowed: true
- valid_until: 2026-09-30T23:59:59Z
That is illustrative, not the literal wire format.
Cedar gives us a way to express numerical limits, booleans, string conditions, time constraints, and similar rules. The more interesting part is how those rules become part of credential verification.
The policy lives outside the credential, but its hash ties it to the credential.
We do not embed the full Cedar policy inside every credential.
Instead, the credential contains a reference to the policy and a hash of the whole policy.
In our implementation, a policy is immutable once set and assigned to a schema.
Figure 5. Cedar policy integrity
The policy lives outside the credential, but the credential's stored hash ties the referenced policy to the signed artifact.
If someone changes the referenced policy, the new content will no longer match the hash in the credential.
If someone changes the policy reference or stored hash inside the credential, the credential's own cryptographic validation should fail.
We also avoid a messy canonicalization problem by not allowing a policy to be edited in place. Even a small textual change produces a different hash.
Binding the authority to Atlas agent
The delegated authority credential is bound to a specific DID in Atlas's wallet.
A DID, or decentralized identifier, is a cryptographic identifier controlled through a set of keys. It gives Atlas a stable identity reference that verifiers can use to check that the credential is being presented by the same agent it was issued to.
If another agent tries to present it under a different DID, verification will fail because the DID does not match.
Figure 6. DID binding
The credential is bound to Atlas's DID. Presenting it as a different DID fails verification.
- Atlas credential
- subject DID = did:...atlas
cannot simply be reused as:
- Agent B
- subject DID = did:...agent-b
For another agent to attempt to reuse Atlas's authority successfully, it would need access to Atlas's wallet rather than merely being handed the credential data.
That makes wallet compromise a different problem from copying the authorization into another agent's wallet.
Each verification transaction also uses a nonce, following the same mechanism as our standard verification flows.
Revocation has to flow down the chain
Delegation creates another problem: what happens to downstream authority when an upstream credential is revoked?
Suppose the chain is:
If Lisa's purchasing authority is revoked, leaving Atlas and Agent B's authority alive would defeat the purpose of revocation.
Our credentials use the same revocation mechanism as our other verifiable credential implementations. A credential contains a link to a revocation registry, and verification includes revocation checks.
With delegation, an upstream revocation invalidates credentials delegated from it.
Figure 7. Cascading revocation
Upstream revocation invalidates downstream delegated authority.
Once authorization can be re-delegated, revocation is no longer only about one credential. The validity of downstream authority depends on the chain it came from.
Time and delegation depth are constraints too
Delegated authority can expire.
We generally represent time limits as Cedar datetime values and check them during verification. Issuance also prevents invalid expiry values from being placed on the verifiable credential.
A purchasing delegation might be equivalent to:
- max_purchase = 100
- valid_until = 2026-09-30T23:59:59Z
The implementation also limits how many times authority can be re-delegated.
The current system maximum is nine hops. It is an arbitrary guardrail against endless delegation chains.
A policy can set a lower limit, including zero re-delegations, and the system limit could technically be raised if a real use case required it.
Figure 8. Time and delegation depth
Time and maximum delegation depth are both constraints on valid authority.
The verifier gets a policy too
Imagine Lisa validly gives Atlas permission to spend up to $500.
Stockwell might still have an internal rule: AI-agent purchases over $100 require human approval.
Both statements can be true.
Atlas is authorized to spend up to $500.
Stockwell is only willing to accept up to $100 automatically.
So there are two separate policy decisions:
Delegator policy: "What is this agent allowed to do?"
+
Verifier policy: "What authority am I willing to accept?"
The verifier can be stricter than the delegator. It might require a lower transaction value, a shorter delegation chain, a specific original issuer, or another credential attribute.
This is why "valid authorization" is not a universal yes/no answer.
An agent can hold valid authority that a particular merchant still chooses not to honor.
Figure 9. Delegator policy vs verifier policy
Possessing valid authority is different from a verifier choosing to accept it automatically.
Tracing authority without seeing Lisa's credential
Atlas's delegated credential contains attributes derived from Lisa's purchasing authority together with the chain linkage.
That lets Stockwell establish that Atlas's authority was delegated from Lisa without requiring Lisa to present her own credential during the transaction.
Figure 10. Tracing authority without Lisa's credential
Stockwell receives a proof based on Atlas's delegated credential, not Lisa's full credential, but still gets enough lineage information to reason about the authority's origin.
The verifier can reason about the origin of Atlas's authority without receiving Lisa's own credential just to establish that provenance.
Where MCP, DIDComm, OpenID, and AP2 fit
Because this is an AI-agent use case, MCP is part of the architecture, but it is not the trust mechanism.
In our current flow, Atlas uses a wallet MCP server to work with its wallet and generate a presentation. An agent on the verifier side could use the API MCP server to perform verification.
The credentials, DIDs, policy, signatures, revocation checks, nonce, and verification rules are what carry the authorization model. MCP is how the agent calls into those capabilities.
DIDComm and OpenID sit at a similar supporting layer. We use them for credential delivery and verification across the broader credential stack. They do not define the delegation semantics.
AP2 is more use-case specific. A delegated credential can establish that Atlas has purchasing authority. AP2 can then govern a payment flow in which Atlas exercises that authority.
Delegation: Who authorized this agent, and within what scope?
AP2: How is a particular agentic payment authorization represented and executed?
The layers can work together, but they solve different problems.
Cryptographic interoperability is not semantic interoperability
A valid signature does not mean another implementation understands the authorization.
A third-party verifier still has to understand:
- the delegation-chain model
- the meaning of the Cedar policy
- how child constraints relate to parent constraints
- how verifier policy is applied
- what rootCredentialId and previousCredentialId mean
That gives us two different interoperability questions:
Cryptographic interoperability: Can I validate this artifact?
Semantic interoperability: Do I understand the authorization it represents?
The first is the easier problem.
The second is where more work remains.
Using Cedar means we did not create another policy language, but Cedar alone does not turn this delegation model into a universal cross-vendor protocol. A verifier cannot learn the semantics just by checking a signature.
Figure 11. Cryptographic vs semantic interoperability
A valid signature does not mean another implementation understands the authorization.
The next problem: agents asking for authority
Our current example starts with Lisa deciding what to delegate.
That is reasonable when the person already knows the scope the agent needs.
It is less natural in a consumer flow.
Imagine the agent says:
I can pay your lawyer's invoice, but I need permission to:
> pay this recipient
> up to $800
> before September 30
The user should not need to understand Cedar or know which credential schema the agent expects.
A more natural flow is for the agent to request the authority it needs and for the wallet to turn that into a proposed delegation that the user can approve or reject.
The bigger lesson
We started from what sounds like an identity question:
How does a vendor know which AI agent it is talking to?
Identity only gets part of the way.
For an agent acting on someone else's behalf, the harder questions are:
- Who granted this authority?
- Could they legitimately grant it?
- Which credential did this delegation come from?
- What exactly was granted?
- Did the authority grow as it moved down the chain?
- Has anything in the chain been revoked?
- Has the authority expired?
- Is this the agent the authority was issued to?
- And even if all of that is valid, will I accept it?
Inside one application, many of those answers can live in an ACL, a session, or an authorization server.
Across organizations, they have to travel.
Once authorization travels, its origin, scope, revocation state, identity binding, and policy become part of what the receiving organization has to evaluate.
That, more than attaching an identity to an LLM, has been the interesting engineering problem.
Building AI agents that need to act across organizations?
We’re working with teams on how AI agents can carry verifiable proof of who authorized them, what they’re allowed to do, and under what constraints.
