Who stands behind the agent?
AI agents are starting to act in the world rather than just answer questions. They book, buy, file, message and negotiate, sometimes for you and sometimes for someone dealing with you. That raises a plain question with no settled answer yet: when an agent acts, who stands behind it?
Dazza Greenwood takes this on directly in a recent essay, “Build Up, Don’t Just Slow Down”. His work on what he calls Accountable Agents is one of the clearest statements of the problem, and it is worth following closely, because it also shows where the work still has to go.
Three questions, not one
Greenwood’s core point is that identity alone is insufficient. He separates three questions:
Who is this?
Who stands behind it?
What is it actually authorized to do?
They are often treated as one. A credential that identifies an agent does not show who is accountable for it, and neither tells you whether the action in front of you is within its authority.
He puts the test at the boundary where an agent’s request becomes an effect in the world. The receiving system checks the delegation, its scope and limits, and whether it is still valid. If the authority cannot be established, the request is refused or sent for approval. The agent’s own claim to permission is not enough. He sets out the chain an agent should be able to present: identity, principal, delegated authority, current validity, configuration state, revocation, and evidence afterward.
Two design choices stand out. He proposes pairwise pseudonymous identifiers, so an agent can be held to account without becoming a beacon that can be tracked across every counterparty. And he proposes a route to the ultimate beneficial owner, the party finally accountable for what the agent says and does. Accountability without surveillance is the right target.
The missing party
Look at who does the checking in this model. It is the receiving system: the bank, the platform, the API, the counterparty. Accountable Agents answers the question “may this agent do this?” for the organisation receiving the request.
There is another party in most of these transactions, and it is not running a verification service. It is the person the agent acts on: the customer whose account is changed, the applicant whose file is assessed, the individual whose data is collected, the reader of the content produced. Today that person is usually identified first and told later, if at all. They cannot check a delegation chain they never see.
For that person the question is the same, asked from the other side: who is acting on me, on whose authority, for what purpose, and how can I show later what I was told? Without an answer, the accountability built for counterparties stops short of the people it is meant to protect.
What the person needs
The person needs three things, in this order.
A record of who stands behind it, available before they are identified. The accountable party publishes who it is, how to reach it, and the authority it relies on, at a stable address anyone can resolve. The person does not have to hand over an identifier to find out who is asking for one.
The notice that was in effect. What the agent was doing, for what purpose, on what terms, with a version that can be referred to later. When the terms change, the change is recorded as an event, so revocation and material change are visible rather than silent.
A receipt the person keeps. A record of the notice they were given and when, held by them and not only by the operator. It lets them, or a regulator acting for them, reconstruct what happened without relying on the operator’s own account.
These map onto Greenwood’s chain. “Who stands behind it” is the controller record. “Current validity” and “revocation” are events in a public log. “Evidence afterward” is the receipt. The difference is who can read them: the counterparty, and also the person.
Greenwood’s own second proposal points the same way. His Agent 911 idea, an incident channel that agents themselves can report to, would issue a signed receipt to whoever files a report. The reasoning is the same: the party raising the alarm should hold proof of what they reported and when, independent of the operator’s account. People affected by agents deserve the same footing.
Why a code of practice
None of this needs a new technology. It needs a shared expectation that the accountable party discloses first, in a form people can read and machines can check, and leaves evidence behind. That is a code of practice question as much as an engineering one.
The Internet Transparency Code of Practice (ITCoP) takes that route for online services generally: transparency by default, a controller that is identifiable before the person is, and records a regulator can inspect independently. Agents are the case where it matters most, because they act at a speed and scale at which nobody can reconstruct what happened from memory.
Greenwood ends his list of roles with a line that fits here: builders build, evaluators test, counterparties enforce authorisation, investigators reconstruct failures, institutions set legitimate rules. Different functions in different hands. The person on the receiving end of the agent belongs on that list too, with a record they can hold.
Questions for anyone deploying agents
- Before your agent identifies, profiles or acts on a person, can that person find out who stands behind it?
- Is the authority your agent relies on published somewhere a person, not just a counterparty, can check?
- When your agent’s terms or authority change, is the change recorded where it can be seen?
- After the fact, does the person hold any evidence of what they were told?
Transparency Lab assesses AI transparency against published standards. Start with the controller self-assessment, which has an AI transparency module, or contact info@transparencylab.ca.
Source: Dazza Greenwood, “Build Up, Don’t Just Slow Down”, DazzaGreenwood’s Weblog, 14 September 2026.