An old picture, a current question
The picture below puts a familiar concern into plain language: "A computer can never be held accountable. Therefore a computer must never make a management decision." The screenshot attributes the statement to an IBM training manual from 1979. What interests me is the question it raises for the agents we're now giving access to our organizations.
I wouldn't read that statement as a ban on useful automation. We already let software apply rules, route requests, and carry out approved changes. The concern is what happens when an organization treats the computer's answer as the end of the conversation. Who explains the decision? Who can correct it? Who answers to the person affected?
An AI agent makes that question harder to avoid. It may send a message, update a customer record, or request access while nobody is watching that particular step. My position is simple: every agent acting for an organization should have an identifiable human sponsor, and accountability must stay with people and the organization. Giving the agent a name, an account, or an ID doesn't change that.
This is a governance position, not a claim that one sponsor is automatically personally liable for every outcome. Responsibility can be shared across management, developers, operators, and suppliers. The agent itself must never become the place where that responsibility disappears.
Why the agent needs an ID
Before discussing accountability, we need to distinguish the agent from the people around it. An agent identity lets systems recognize the software actor and give it appropriate access. It helps answer a basic question: which agent performed this action?
Imagine an agent and several employees all using one shared account. A record says that the account changed a supplier's details. Was that an employee, the agent, or another automation? Even if the change was legitimate, the organization has made its own explanation harder. Separate identities help keep those activities distinguishable.
Microsoft's Microsoft Entra Agent ID concepts describe agents that act on behalf of a signed-in user and autonomous agents that operate using their own identity. We don't need the authentication details to understand the business point: the software's identity and the human's responsibility are different things.
An ID isn't proof that an agent's decisions are correct, fair, or authorized in a business sense. It establishes who the software actor is. Permission establishes what systems allow it to do. Neither tells us whether it should do a particular thing to a particular person.
Give the agent its own identity so you can trace its work. Give a human sponsor the authority and responsibility to decide whether that work should continue.
Someone must answer for the work
A human sponsor is the person who can explain why the agent exists, what business purpose it supports, and which boundaries apply. That person doesn't have to write the code. They do have to understand the consequences of letting the agent act.
If an agent rejects a request, "the AI decided" is an incomplete answer. Someone chose to use that system, approved its scope, and accepted the process around it. A customer or employee should be able to reach a person who can review the outcome and arrange a correction, rather than being sent back to the same agent that caused the problem.
That distinction is present in Microsoft's responsible AI guidance, which includes accountability among its principles. It also appears outside the technology industry. UNESCO's Recommendation on the Ethics of Artificial Intelligence places ultimate responsibility and accountability with natural or legal persons, rather than giving AI systems legal personality. In plain language, that means people and organizations.
The OECD accountability principle adds a useful detail: accountability depends on the actor's role and the context, and requires traceability across the system's lifecycle. A named sponsor is a starting point. There also needs to be evidence of what happened and a clear route to the people who can respond.
How Microsoft separates the roles
Microsoft's Agent ID administrative model separates technical administration from business accountability. Owners handle configuration and operational management. Sponsors represent the business purpose and make lifecycle decisions, including whether access and continued use are justified.
That separation makes sense to me. The developer who can fix an integration isn't necessarily the person who should approve the business risk. The business sponsor shouldn't need broad administrator permissions simply to decide that an agent is no longer needed.
| Role or record | Question it answers | What it doesn't replace |
|---|---|---|
| Agent identity | Which software actor accessed a resource or performed an action? | Human judgment about whether the action was appropriate. |
| Technical owner | Who maintains the agent's configuration and operation? | Business approval of its purpose and accepted risk. |
| Human sponsor | Who answers for its business purpose, scope, and continued use? | The responsibilities of management, developers, or suppliers. |
| Organizational governance | Who sets the rules, funds oversight, and handles serious failures? | A reachable person who can respond to a specific problem. |
Microsoft supports users and certain groups as sponsors. My recommendation is to keep a named human lead even when a group provides coverage. A group can make absence and succession easier to handle, but "someone in this group owns it" isn't a useful answer during an incident.
Another agent can help gather evidence or flag unusual behavior. It shouldn't be the final accountable sponsor. Otherwise, we have replaced one unanswered ownership question with a second automated system.
A sponsor needs real authority
Putting a person's name in a directory isn't enough. If the sponsor can't see what the agent is doing, challenge its scope, or arrange to stop it, the organization has assigned responsibility without providing control.
Researcher Madeleine Clare Elish describes this problem through the idea of "moral crumple zones": a human with limited control over an automated system can end up absorbing blame when it fails. That warning matters here. Human accountability must not become a convenient way to blame the nearest employee while leaving the organization's decisions unexamined.
A sponsor needs understandable records, time to review them, and an agreed escalation route. For serious concerns, they need the ability to suspend the agent or get an operator to do it promptly. Management still needs to provide staffing, training, and clear rules about which risks the business accepts.
The American Philosophical Association's discussion of automated decision-making makes a related point: accuracy alone doesn't solve accountability. Even a system that usually produces correct answers needs a way for people to challenge harmful outcomes. A confident explanation from an agent isn't the same as a review by someone authorized to change the result.
When an ordinary task goes wrong
Consider a customer-service agent authorized to issue small refunds. It reads a message incorrectly and refunds a larger amount than the business intended. This doesn't require an attack or a dramatic technical failure. A routine misunderstanding is enough.
The identity record should help establish which agent acted. The transaction history should show what it read, what it changed, and whether a limit or approval applied. The sponsor then has a business decision to make: pause refund activity, help the customer, and determine whether the task needs narrower rules.
The technical owner may discover an integration error. The sponsor may discover that the refund policy was ambiguous. Management may discover that it approved automation without budgeting for exceptions. Different people can have different responsibilities for the same outcome.
Now suppose a customer disputes a correctly applied refund rule. The agent may have followed its instructions exactly, but the organization still needs a person who can consider circumstances the rule didn't anticipate. Accountability covers the decision to use the rule, not just failures to execute it.
Costs belong in that conversation too. The business case includes monitoring, support, and correcting mistakes, as well as the agent's running costs. An agent that saves staff time by removing every route to human review may simply be moving the cost onto customers.
Oversight without approving every click
Human sponsorship doesn't mean a person must approve every action. That would make many useful automations impractical. It means people decide the operating boundaries and remain available when those boundaries fail or need to change.
An agent that labels internal documents may need periodic checks and an easy way to undo errors. One that sends contractual commitments, changes access rights, or influences employment decisions needs stronger review. The relevant question is what harm a mistake could cause and how difficult it would be to reverse.
I would separate ordinary approved work from exceptions. Let the agent perform the bounded task. Require human review when it exceeds a financial limit, encounters conflicting instructions, or reaches a decision the organization hasn't authorized it to make. A review step only counts if the reviewer has enough information and can genuinely say no.
Sponsorship also has to survive staff changes. If the sponsor leaves, changes role, or no longer understands the agent's work, ownership needs to transfer. Without a valid sponsor or agreed coverage, pause the agent's ability to act until someone accepts that responsibility.
Before the agent gets access
Before granting an agent permission to act, I would ask the team to answer these questions in ordinary language:
- Who is the named human sponsor, and who provides coverage?
- What is the agent allowed to do, and what must it refer to a person?
- Who can stop it, and how quickly can that happen?
- What evidence will let us explain an action after the fact?
- How can an affected person request a review or correction?
- Who accepts responsibility when the agent's purpose or access changes?
If those answers aren't clear, a successful demonstration isn't enough reason to grant production access. The ID can be created before the governance is ready, but that doesn't make the agent ready to act.
The picture is useful because it brings us back to an ordinary management obligation. An organization can delegate work to software. It still owes people an explanation, a route to correction, and someone with authority to respond. Give the agent an ID, keep a human sponsor attached to its work, and don't accept "the agent did it" as the final answer.
References and further reading
- Microsoft Learn: Administrative relationships in Microsoft Entra Agent ID. Defines technical owners and business sponsors, including sponsor responsibilities and succession.
- Microsoft Learn: Microsoft Entra Agent ID key concepts. Explains agent identities and the distinction between user-directed and autonomous operation.
- Microsoft Learn: Apply responsible AI. Applies Microsoft's responsible AI principles to agents, including a named owner answerable for behavior and outcomes.
- UNESCO: Recommendation on the Ethics of Artificial Intelligence (2021). See the section on human oversight and determination, including paragraph 36 on responsibility and legal personality. An international ethics recommendation, not a rule assigning personal liability to an agent sponsor.
- OECD AI Principles: Accountability. Connects accountability to roles, context, traceability, and ongoing risk management.
- Madeleine Clare Elish: Moral Crumple Zones: Cautionary Tales in Human-Robot Interaction (2019). Published in Engaging Science, Technology, and Society, volume 5, pages 40–60. Examines misplaced responsibility when human operators have limited control over automated systems.
- Blog of the American Philosophical Association: Responsibility and Automated Decision-Making (2023). Discusses the responsibility gap and why accuracy doesn't replace a route to challenge decisions.
- Simon Willison: A computer can never be held accountable (2025). Documents the circulating image, its reported origin, and correspondence about the original material.