Most of the work on agent identity so far has gone into answering a question vendors cannot actually use: which agent is this? Knowing the agent's name, or that it carries a signed identity, does not tell a supplier whether anyone authorized the purchase it is about to make, or whether the purchase falls inside that authority. So services do what is available to them. They block agents, they route every step back to a human, or they take the agent's word for it.
In this session, Agne Caunt, Product Owner at Dock Labs, demonstrated Truvera's delegated authority feature against a deliberately ordinary scenario: an office manager delegates a narrow slice of her purchasing authority to an agent that reorders paper and toner, and the vendor verifies that the agent is acting inside limits set by the company, not by the agent. Mike Parkhill, Head of Engineering at Dock Labs, covered the implementation, including the MCP based wallet that lets agents hold and present credentials without a browser, a UI, or a thumb to authenticate with.
What follows is a set of insights from the session, covering how delegation is modeled, what the verifying party receives, where policy becomes an operational problem, and how this approach compares to bot blocking, enterprise OAuth extensions, the Trusted Agent Protocol, KYA-OS, x401 and Verifiable Intent.
The trust gap agents create
- Agne Caunt framed the problem as one-sided: agents are already capable enough to buy and sign things, but the counterparty has no way to judge them. Knowing which agent is calling, when that is even possible, does not tell the service who authorized it or how far that authority extends.
- The three fallbacks available to online services today are to block the agent, drop back to a human approving each step, or take the agent's word for it. None of these scale, which is why the problem gets pushed onto the verifying side of the transaction rather than the agent side.
- Trusting an agent breaks into three separate questions: who takes responsibility, what did they authorize, and how does payment settle. This session covered the first two. Payment is handled through AP2 and was deferred to a dedicated session.
- Richard Esplin opened by relaying a point Andrew Shikiar of the FIDO Alliance made in an earlier Dock Labs session: a service does not need to trust the agent so much as the chain tying the agent back to an accountable person, with clear evidence of what that person actually authorized.
How delegated authority works
- The model has four steps: issue a credential with the limits written into it, present it when the agent acts, verify who granted the authority and whether it still covers the action, and revoke when circumstances change. Once revoked, the credential no longer verifies and the agent cannot use it.
- Attribution is the thread running through all four steps. Every action the agent takes traces back to the human or organization behind it, which is what makes the credential useful to the vendor rather than just to the enterprise.
- Delegation narrows authority rather than copying it. In the demo, the purchasing schema allowed a maximum of $5,000, Quotient issued Lisa $2,000 as office manager, and Lisa could pass the agent that full amount or less. Capability scope narrows the same way. In the rule set Agne Caunt walked through, the office manager role could buy IT peripherals and electronics while the agent role was held to office supplies, and the agent's credential was also restricted to a single approved vendor.
- The agent holds only the delegated slice. It does not carry Lisa's employee credential or Quotient's wider attributes, and Richard Esplin noted the policy travels signed by the delegator, so the agent cannot quietly widen its own limits.
What the verifier actually receives
- One audience question pressed on the obvious gap: Stockwell, the vendor, does not care about Quotient's internal policy. Richard Esplin's answer was that Stockwell only needs to know the agent is authorized by Quotient. Internal policy is enforced through the delegation chain, and Stockwell ends up holding signed evidence that it was.
- Mike Parkhill pushed that further: the vendor probably does not care about Lisa's spending limit at all. It needs to know that someone at Quotient had authority, and it needs the presentation on record so that a later dispute is answered with evidence rather than judgment. Stockwell is not the party that enforces Quotient's internal rules.
- The verification record shown in the demo included the date, the issuing DID, the delegation chain, the capabilities and constraints that were checked, and the full presentation. Stockwell ran verification in its own sub-account with separate DIDs, not inside Quotient's account.
- How much the verifier asks for is a business decision, not a technical one. Agne Caunt noted a vendor might only want the name of the person behind the agent and confirmation of sufficient purchasing authority, though she observed that asking for less information is rarely anyone's natural instinct.
Policy becomes a product surface
- Delegation rules live in a rule set attached to a credential schema, expressed as Cedar policy. The rule set defines roles, which attributes pass down the chain, capabilities, and constraints. The demo restricted the agent to a named vendor, to specific product categories, and to a spend ceiling.
- Rule sets are immutable once created. Changing the rules means duplicating the rule set and creating a new one.
- Delegation depth is an explicit constraint: how many times a credential can be redelegated. Agne Caunt tied this to multi-agent and sub-agent architectures already appearing in organizations, where an orchestrating agent spins off task agents and has to pass along part of its authority.
- Agne Caunt was direct about the usability problem: nobody is born knowing how to write Cedar policies, and the current roadmap effort is aimed at making rule sets approachable through the interface.
The privacy inversion
- Agne Caunt made a sharp point: the default instinct in credential design, minimize disclosure to protect the holder, does not apply to agents. For an agent you want the opposite, the least freedom and the most visibility into what it did at every step.
- Richard Esplin extended that into an unresolved design question. Normally the goal is that an issuer does not learn how a verifier uses a credential, but a delegator does want to know what its delegate is doing. Packaging that audit trail is harder once the delegate is a person rather than an agent, since he noted agents do not have privacy rights and humans may be more concerned.
Where this sits in the market
- Richard Esplin's read of the landscape: bot blocking is easy and costs you customers; Entra and Okta OAuth extensions are built on mature technology but cannot span trust boundaries; the Trusted Agent Protocol does span boundaries and reuses existing HTTP infrastructure, but authenticates the agent without tying it to a responsible party and is centrally managed.
- He placed three efforts closer to Truvera's approach: KYA-OS from Vouched and DIF, which adds DIDs, VC delegation and authorization history to MCP but is a draft specification; x401 from Proof, which he praised for standardizing proof exchange over HTTP headers but which does not specify how delegation happens; and Verifiable Intent from Mastercard and FIDO, which is built on keybound SD-JWTs and is expected to merge with AP2.
- The team was candid that its own delegation approach, RDF delegation plus Cedar policy, is not a standard and is not adopted by anyone else. Mike Parkhill said none of these protocols existed when the work started and the goal is not to stay different, and Richard Esplin described the same pattern from Dock Labs' earlier ecosystem work: get ahead of the standards, then converge.
- Richard Esplin argued the near-term value is in closed ecosystems, specifically internal procurement and insurance verification, where one organization can pick its own standards.
- He also drew a useful boundary: a fair amount of agent transactions will not need delegation at all, only working payment. Delegation earns its place where something has to be proven alongside the transaction, such as age verification, proof of insurance, or professional credentialing.
Implementation notes
- Agne Caunt highlighted that wallets do not have to be separate apps. The demo embedded a cloud wallet inside Quotient's existing employee portal, so delegation happens inside the tool the employee already uses.
- Mike Parkhill described the agent wallet as an MCP server, currently in preview, with each agent bound to a single wallet. As Agne Caunt put it, agents do not have thumbs to authenticate with and do not need a UI, but they are good at calling MCP tools.
- The same mechanism works for human delegation. Agne Caunt cited Lisa delegating to a colleague while on holiday and organizations delegating to employees, and connected it to the business wallet conversation about how personal identity gets tied to business identity.
