Updated 17 October 2026. An agent has a task. A credential has an owner. A business process has someone responsible for the result. Those three facts need to meet somewhere other than the incident review.
That is the accountability gap I care about: a system can be technically authorised to act while the organisation remains unclear about who approved its purpose, who reviews exceptions and who handles the consequences. No market-wide percentage is needed to make that a worthwhile design question.
Follow one action through the system
Take an illustrative agent preparing a supplier payment. It retrieves an invoice, checks a purchase order and requests approval. Which identity read the invoice? What scope allowed the lookup? Who approved the payment amount and recipient? Does approval expire if either changes?
“A human approved it” is incomplete if the person approved a different amount ten minutes earlier. “The service account did it” identifies a credential, not the business decision behind it.
| Layer | Question | Record |
|---|---|---|
| Purpose | Why is this task allowed? | Task owner and scope |
| Identity | Which principal requested it? | Principal and credential context |
| Authority | Who approved this exact action? | Bound approval and policy decision |
| Outcome | What actually changed? | Execution result |
| Recovery | Who owns the exception? | Named handler and next step |
Make the approval specific
Bind approval to the action that matters: the operation, target, relevant parameters and validity window. If the proposed action changes materially, require a new decision. This is a design proposal; the precise implementation depends on the workflow and threat model.
The same discipline applies to delegated access. An agent should not inherit an unlimited interpretation of a person’s job merely because it uses a credential associated with that person. Decide the scope explicitly and test the boundary.
Test the awkward handoff
A useful exercise is to interrupt the workflow after approval but before execution. Can the team tell whether the action happened? Can it avoid performing the action twice? Can someone safely resume the task? This turns accountability from a diagram of job titles into observable behaviour.
The NIST AI Risk Management Framework provides a voluntary risk-management reference. The action chain above is my proposed review tool, not a prescribed NIST model or a claim that every deployment requires the same architecture.
Connect the chain to evaluation evidence and to the responsibilities in the vendor agreement. Where those disagree, resolve the disagreement before widening access.
The useful answer to “who is accountable?” should survive a real example. A slide containing six department logos is a seating plan, not an answer.
