Move the authorisation, not the keys
Agents are useful precisely because nobody has to watch. So when you are not there to say yes, what is your agent carrying that says you did?
On 22 September, on the sidelines of the UN General Assembly, more than 20 leaders signed a short statement on frontier AI. Singapore was among them, and Prime Minister Lawrence Wong made a point I agree with: the work now is to find practical ways to build common ground. At the centre of the statement is one sentence: AI “must remain under human direction, oversight and control.”
I use frontier models in two ways:
- To advise me. Research and guidance, where I make the decisions.
- To act for me. Delegation, where the AI makes changes in my name.
That sentence starts to matter at the second one, and few systems can meet it today. The answer is not to lend our keys to agents. It is to send our authorisation with them.
Signing this statement is the easy part.
By 24 December, every EU member state must offer its citizens a digital identity wallet. Implementations that were mostly tested in-house will start working together across borders, and agents will cross those same borders on our behalf. Permission that only one system can check stops at the first border. I’ll come back to that.
When nobody is watching
In my last piece, Show me the proof, not the promise, I described a demonstration that assumed a human was present at the moment of purchase. That assumption is the one I keep coming back to.
Oversight has quietly come to mean a person watching. But agents are useful precisely because nobody has to watch. Version 0.2 of Google’s Agent Payments Protocol (AP2) specifies payments with no human present, on instructions authorised in advance. Google’s own example is buying limited-run tickets as soon as they go on sale.
I would like my agent to buy those tickets. The sale opens at 3 am, and I intend to be asleep.
The usual answer is to push the responsibility back onto us and ask us to click through an endless stream of approvals. We already know how that ends. It is the “Accept Cookies” problem: most people click “Accept All” because declining has been made deliberately hard. More prompts are not oversight. Better rules are.
The login we lend
Today, when software acts for you, it is usually because you lent it something: a password, an API key, an OAuth token. For apps that a person supervises, that was a reasonable design.
The trouble is what the token grants. The app can now do everything the token can, whenever it likes, for as long as the token lives. You approved access. You never approved an action.
The industry has been working on this, and credit is due.
On 21 September, NVIDIA’s Chief Security Officer, Saša Zdjelar, put the principle plainly: an agent “can request additional access, but it cannot authorise that access itself.” Each agent, he wrote, needs a traceable identity and credentials limited to its assigned task, with human approval for consequential actions.
Scoped, short-lived tokens make the pass smaller, but it is still a standing pass. What an agent really needs is a receipt for one decision.
When I am not there to say yes, what is my agent carrying that says I did?
The notary
A notary holds a seal you cannot borrow. You bring the document; they check who you are and what you are asking; they stamp it; and the seal never leaves the room. You do not post your seal. You send the document.
The Verifiable Trust Agent (VTA) at the centre of the Verifiable Trust Infrastructure (VTI), which I helped build, works the same way. An application sends it an unsigned payload. The VTA picks the key, signs the payload in memory and hands back the signature. Nothing that can sign ever has to travel. Like a notary, it can refuse. Unlike a notary, it can also wait until a human on another device says yes.
The VTA also holds your approval policy and a register of devices and agents that may act on your behalf. Any of them can be switched off or wiped. That makes approval programmable: what is being requested determines who must approve it and how.
When we set out to let a website update someone’s DID document, the record that serves as their public identity, there were only ever three options. Put the key in the browser, the most hostile runtime you own. Give the key to the host, who then controls your identity. Or move the authorisation, not the key, so that nothing that can sign ever moves.
What the third option cost the hosting service surprised me: nothing. It needed no changes, because it verifies the proof chain exactly as it always did. It trusts the mathematics, not the caller.
Three ways to let a website change your identity. Only the third keeps the key where it is.
Two different letters
An agent acting for me needs something in writing, and it can carry one of two things. If I ask a colleague to write an article for Affinidi, I have given them authority: they can do that one thing for me. If I hand them my social media, with the power to decide what goes out, I have delegated: they now make decisions in my name.
Our credentials keep the two apart. In the Decentralized Trust Graph (DTG) credential family, which we are specifying with others in Trust Over IP, an authority credential says that an agent may do this one thing, here. When it is passed to a sub-agent, it can only be narrowed, never widened. A delegation credential says that an agent may act on my behalf, within limits on what it can decide for itself.
Here is authority for my agent: buy up to two tickets for one event, from one seller, tonight, at no more than the price I set. The box office can check that without calling me, and by morning, the authority has expired.
Here is delegation: my agent keeps looking for events that match my interests, and it has a monthly budget to spend as it sees fit. It does not need to ask me before it books.
Delegation works best when you also define the authority that comes with it. Put simply, decide when the agent must stop and ask. Without those limits, it has to ask you about everything, and you are back to clicking “Accept All”.
Delegation, unlike authority, is single-hop. A delegate who needs help goes back to my VTA, which either issues a fresh credential or asks me. Chains of delegation would force verifiers to trace the entire ancestry, revealing who is behind it and allowing one party to pose as several. And you cannot revoke what you cannot enumerate.
That may change. Zero-knowledge proofs could make blind delegation possible, in which an agent acts without revealing the principal to the verifier, yet can still be held to account.
Delegation credentials are countersigned, so an appointment is not valid until the delegate accepts it. As the issuer, I can revoke a delegation at any time. When a verifier asks my VTA whether a credential is still valid, the only party that learns anything is an agent that works for me. Compare that with today’s platforms, where a third party acts as my approver and sees everything I do.
The credentials themselves are small: six fields and five checks, all run locally. The only live question is whether I have revoked the credential, and only my VTA can answer that.
Authority and delegation: two different letters.
Delegation has moved from concept to specification and implementation, and the details are still being debated in public. Both credentials are implemented in our credential library, and the approval flow is running and tested. The wire formats will keep changing.
Checked when it is used
A credential settles what an agent may do. It does not settle whether a particular action should happen now. For that, every action goes through its own approval, is checked again, and runs exactly once. I walked through that flow step by step in my last piece.
Because approval is programmable, the flow can match the stakes. A micro-payment within budget is simply logged. A request to book flights over $500 needs my fingerprint or face on one of my other devices.
The whole design defends one sentence: nothing changes unless a real person, on a device we still trust, approves this exact thing, and it is still allowed at the moment it happens.
The party asking can never authorise anything. The approval is bound to a digest of the exact payload, so nothing can be swapped after I say yes. And revoking a device should also stop any approvals still in flight.
That last rule did not hold in our first draft.
We evaluated the policy when the consent request was created, and nothing rechecked the authority before the task ran, which could be minutes or hours later. If the policy was tightened in that window, the change never applied.
In plain terms, say I start an approval from my phone on Monday, lose the phone on Tuesday, and disable it from my laptop. That approval should die with the phone. In our first draft, it did not.
We re-checked the data when the action ran, but not the authority, so the data was checked twice and the authority only once. The fix re-evaluates both the policy decision and the approver’s enrolment at the moment of execution. Authority should be checked when it is used, not when it was given.
The gap between checking and doing: our first draft, and the fix.
We found this by reviewing the design, not through an incident. That is the argument for writing the rule as a single sentence: you can audit a sentence.
The rules are yours
None of this works if the rules belong to us. Here is the entire configuration for one action, updating your identity document, as it appears in the public workshop material:
# the whole configuration. yours, not ours.
[policy.approver_sets]
operators = ["did:key:z6Mk…"] # named ahead of time
[[policy.require_consent]]
task_type = "…/webvh/dids/update/1.0"
approver_set = "operators"
exclude_requester = true # forces two devicesThis is the policy behind the approval screen in my last piece, where my agent asked me before changing my own identifier. The line doing the work is exclude_requester: the thing that asks can never be the thing that agrees. You decide, action by action, which actions need a human, who may approve them and how many must agree. It also protects you from a compromised device. If device A requests a change, approval must come from another device.
An agent approves a tool, not a call
AI agents make this more urgent. MCP leaves approval to the host, and many hosts approve a tool once and then let every call ride on that single approval.
On 20 September, Simon Willison set out what a less reckless agent needs, including authentication that never exposes the agent to API keys, and strong audit logs. His view is that MCP makes these easier to provide. I agree, but the layer beneath the host still has to hold when the host does not.
So our bridge between agent hosts and the VTA adds three layers of limits. The access list limits which identity an agent can use. The bridge limits the session and refuses outright when the host cannot show a person a prompt. The approver policy limits the operation itself.
The third layer matters most. The bridge’s settings live on the machine running it, and a compromised host could ignore them. The approver policy lives in the VTA, next to the keys. Name an operation in require_consent, and no AI agent can perform it, through any host, until a named approver signs on a second device. Local policy is advisory. Agent policy is not.
Three limits on an AI agent. Only the last one lives next to the keys.
Common ground, written in public
Common ground only counts once someone checks it against someone else’s. The Trust Spanning Protocol (TSP), Trust Over IP’s protocol for secure messaging between agents, has been on by default in our stack since September. A public conformance suite runs it against five implementations: 893 interoperability checks passed, none failed, and we reported seven specification issues upstream. That is the December wallet problem in miniature: implementations tested against each other, not just against themselves.
The credentials are Trust Over IP working group deliverables. VTI is part of OpenVTC under LF Decentralized Trust. Everything described here is open source under Apache-2.0, and none of it requires a login.
The wider lesson
Human control of an agent is not a person watching. It is a permission that the person wrote down, held next to their keys, carried by the agent as a credential anyone can check, re-checked at the moment it is used, and withdrawn by that person alone. Anything less is a login we lent and hoped for the best.
Most people will never read a delegation credential, and they should not have to. They will notice whether they can stop the assistant booking their travel in one step, whether a box office can check it without phoning them, and whether a lost phone stops being a way in. Trust in agents will be won or lost in moments like those, long before anyone agrees on a specification.
If you deploy agents, ask three questions. What does each agent carry when it leaves your walls? Where does the key that signs for it live? Could anyone outside check its authority without calling you? If you’d like to see how we answer them in real code, I’m happy to walk you through it. It is all public.
Signing a statement is easy. Proving that a human is still in control, at 3 am with nobody watching, is the work. Keep the keys where they are, and send the authorisation.
This is the second in a series on moving from asserting trust to measuring it. The first was Show me the proof, not the promise. Next: an agent’s authority is only as good as the code it runs, so who may change that code, and who says so right now?
Sources
Finnish Government, “A Call for Control of Frontier AI Models”, joint leaders’ statement, 22 September 2026.
Google, “We’re donating Agent Payments Protocol to the FIDO Alliance”, Google blog, 28 April 2026 (AP2 v0.2, payments with no human present).
Saša Zdjelar (NVIDIA), “AI Security Is an Engineering Problem: How to Solve It at Every Layer of the Agent Stack”, NVIDIA blog, 21 September 2026.
Simon Willison, comment on “MCP was always a bad idea?”, simonwillison.net, 20 September 2026.
European Union, Regulation (EU) 2024/1183 (European Digital Identity Framework), wallet availability by 24 December 2026.
Glenn Gore, “The Verifiable Trust Stack”, VTI workshop, OpenID Foundation Digital Credentials Protocols working group, Geneva, 31 August 2026.
Trust Over IP, Decentralized Trust Graph credentials specification (github.com/trustoverip/dtgwg-cred-spec).
OpenVTC, TSP conformance suite (github.com/OpenVTC/tsp-conformance). Figures as of 16 September 2026.