Who Is Responsible for an AI Agent?

Overview

A procurement agent approves a duplicate invoice. A marketing agent publishes an unapproved discount. A data agent runs a query that returns a column it should never have touched. Someone has to answer for it, and most organizations answer by writing a name in a registry next to the agent's entry.

We don't think that settles it. A named owner is a good first step and a bad final answer, because the question "who is responsible" collapses two different questions into one: who should answer for what this agent did, and who can change what it does next. Those are frequently different people, and an ownership model that doesn't say so out loud is hiding its own weakest point.

Regulators have started writing the distinction into law, which makes this less of a philosophical exercise than it was two years ago. A companion piece on accountability frameworks covers the mechanics of the first ten minutes of an incident. This one is about the earlier problem: what happens the moment you write a single name next to "owner", and what the record needs to say instead.

The Agent Cannot Own Itself

It's tempting to treat an autonomous agent as a self-contained actor bearing its own responsibility, and the framing fails under real pressure. When an agent updates the wrong field across hundreds of records, nobody accepts "the model decided that" as a resolution. The cleanup is human, and so was the decision to deploy.

The law is blunter than most internal governance documents here. The EU AI Act recognises two roles that matter and neither is the software: a provider "develops an AI system ... and places it on the market or puts the AI system into service under its own name or trademark", and a deployer is "using an AI system under its authority". No third category, no partial personhood, no shared liability with the model.

The part worth knowing is how easily an enterprise crosses from the second category into the first. Under Article 25(1), a deployer becomes the provider, with the provider's full obligations, if it puts its own name or trademark on a high-risk system already on the market, substantially modifies it, or modifies the intended purpose so the system becomes high-risk. Article 3(23) defines a substantial modification as a change "not foreseen or planned in the initial conformity assessment" that affects compliance or the assessed intended purpose. Rewriting a system prompt, adding a tool that lets the agent write where it previously only read, or pointing it at a new business process is the class of change that argument covers. Buying an agent does not outsource accountability for it, and configuring one aggressively can move you up the chain without anyone filing a document.

What the Law Actually Assigns

Article 26(2) of the AI Act is one sentence long and it is the most useful sentence in this whole subject: "Deployers shall assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support."

Three requirements, and internal registries skip the third. Competence and training are properties of a person you can check at assignment time. Authority is a property of the systems around them, and writing a name down does not establish it.

Article 14 then says what oversight has to be capable of. The assigned people must be able "to decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output", and "to intervene in the operation of the high-risk AI system or interrupt the system through a 'stop' button or a similar procedure that allows the system to come to a halt in a safe state". Override, reverse, halt. Those are mechanisms, not attitudes, and each is a separate piece of engineering somebody has to have built before the incident.

The dates moved, so if your internal deck still says August 2026 it is out of date. After the Digital Omnibus amendments entered into force on 27 July 2026, the European Commission's framework page puts the Annex III high-risk use cases, including biometrics, critical infrastructure, education, employment and border control, at "2 December 2027", and systems embedded in regulated products such as lifts or toys at "2 August 2028". Prohibited practices have applied since February 2025 and the general-purpose model rules since August 2025.

What a missed deployer obligation costs is also specified. Article 99(4) covers Article 26 among others and sets fines "of up to EUR 15 000 000 or, if the offender is an undertaking, up to 3 % of its total worldwide annual turnover". Failing to give your named overseer a working stop button is not a paperwork offence.

Naming an Owner Is Not Giving Them a Switch

Take a contracts lead named as the business owner of a contract-triage agent, accountable for what "correct" means in that workflow and for whether the agent is still fit for it. That's a reasonable assignment. The contracts lead understands indemnification language better than anyone on the platform team.

Now the agent starts passing through indemnification clauses it should be escalating. The contracts lead is, by every definition on the org chart, the responsible party. They also, structurally, almost never hold the ability to revoke the agent's access, roll back what it already sent to a counterparty, or stop the next run. That sits with whoever manages the integration, usually a platform or security function that was never named accountable for the outcome and has no particular urgency to treat this as their emergency.

So the person supposed to act has to find the person who can, mid-incident, without a defined path for doing it. That search is where the damage compounds. Not because nobody was responsible, but because responsibility and capability were assigned to different desks and nobody wrote down the bridge between them.

Figure 1 — Naming an owner answers who gets asked. It doesn't answer who can act, and the gap between those two questions is where an incident runs while a phone call happens.

Five Levers and Who Holds Them

"Owner" is doing two jobs on most registries. One is a business judgment: is this outcome acceptable, should the agent's scope change, should it keep existing. That belongs with the business owner. The other is operational: can this specific action be stopped right now, and by whom. It decomposes into five levers, and they are not interchangeable. Confusing them is how an incident call ends with four people agreeing something has been handled when it hasn't.

Table 1 — The five levers, what each one is good for, and the gap each one leaves.

Note what that costs you. The fastest lever, disabling the identity, exists at all only where the agent has aact:identity-model/per-agent-identity; under aact:identity-model/shared-human-identity pulling it disables the person. It is also the lever most likely to be held by the accountable person and the one that does least about damage already done. The lever people reach for rhetorically, "revoke its access", is usually the slowest, because it lives in a provider console the agent's owner has no account on.

Why the Mismatch Is Worse Than No Owner

An agent with no named owner announces its own problem. Anyone who looks for one notices the gap and keeps asking. An agent with a named owner who has no lever looks solved. The registry has an entry, the entry has a name, and the search stops there, right up until the day it matters.

There's a second cost, less obvious and more corrosive. A person formally accountable for outcomes they can't influence learns, correctly, that the title carries risk without power. Some respond by rubber-stamping, since their sign-off was never going to change what happens. Others avoid the role. Neither is a character flaw.

NIST's AI Risk Management Framework makes the dependency explicit. GOVERN 2 asks that "accountability structures are in place so that the appropriate teams and individuals are empowered, responsible, and trained". Empowered comes first in that list for a reason. GOVERN 3.2 then asks for policies that "define and differentiate roles and responsibilities for human-AI configurations and oversight of AI systems", which is the framework's way of saying one column called "owner" is not enough.

The Ownerless Agent

The failure mode that arrives without anybody making a decision is the agent whose owner has left. It is common enough that vendors now ship a counter for it. The agent registry in the Microsoft 365 admin center surfaces a tenant-wide tile for "Agents without owners", defined as "the number of agents that no longer have owners at your organization", and states the cause plainly: "Shared agents can become ownerless when you delete the user who created them from the organization." The remediation offered is blocking or deleting the agent, which tells you how little else is available at that point.

Microsoft Entra's governance model for agent identities takes the other approach, and we think it is the more interesting one. Sponsors of agent identities are described as "human users accountable for making decisions about its lifecycle and access", and sponsors and owners can enable and disable the agent themselves, so the accountability and the switch sit with the same person. The documentation then handles departure directly: "If the sponsor is leaving the organization, sponsorship of the agent identities is automatically transferred to their manager", so that "there's always a human user accountable for managing the access and lifecycle of the agent identities."

Whether or not you use that stack, both ideas are portable. Ownership needs a successor rule that fires without a human remembering, and the owner needs at least one lever they can pull without a ticket.

Access-control guidance already treats the ownerless case as a disabling trigger rather than a reporting line. NIST SP 800-53 requires organizations to "assign account managers" and to "align account management processes with personnel termination and transfer processes", and AC-2(3) says to disable accounts that "are no longer associated with a user or individual".

What Ownership Should Record

An honest ownership record answers more than a name. For every agent it should be possible to say, in under a minute, who is accountable, which of the five levers that person holds, who they escalate to for the rest, and how fast.

agent: contract-triage
accountable_owner: contracts-lead@example.com     # answers for the outcome
levers_held: [disable_identity]                    # the only one they can pull alone
escalation:
  scope_change: platform-iam@example.com           # entitlements, 1 business day
  provider_revoke: workspace-admin@example.com     # DocuSign + Gmail grants, 30 min on-call
  data_rollback: clm-platform@example.com          # CLM writes, 2 h RTO
successor_rule: manager_of_record                  # fires automatically on offboarding
last_confirmed: 2026-07-14                         # someone actually tested the switch

The levers_held and escalation fields are the ones almost every registry is missing, and the ones that matter at 02:00. A business owner who can retire an agent is a real owner. One who can only ask someone else to consider retiring it is a contact, and the record should say so plainly rather than listing them in the same column as everyone else.

last_confirmed deserves its own defence, because a lever nobody has pulled is a lever nobody knows works. NIST's MANAGE 2.4 asks for mechanisms "applied, and responsibilities ... assigned and understood, to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use". Applied is the operative word. Disable the agent in a staging tenant once a quarter, watch what breaks, and write the date down.

The Incident Clock

Fix this before an incident rather than during one, because the reporting clocks are short and they start without asking you. Under Article 26(5), a deployer that identifies a serious-incident risk must inform the provider and the relevant market surveillance authority and suspend use of the system. Article 73 sets the outer bounds: a serious incident is reported "not later than 15 days" after the provider or deployer becomes aware of it, "not later than two days" where there is a widespread infringement or serious disruption of critical infrastructure, and "not later than 10 days" in the event of a death. Awareness starts the clock, and awareness is cheap to acquire accidentally.

Two days is not enough time to discover who can turn something off. It is barely enough to describe what happened, which is the other thing the accountable person needs and rarely has. Article 26(6) requires deployers to keep the logs a high-risk system generates automatically "for a period appropriate to the intended purpose ... of at least six months", and Article 18 keeps the provider's technical and quality-management documentation for "a period ending 10 years after the high-risk AI system has been placed on the market or put into service".

Figure 2 — The clock starts at awareness, not at resolution. Every minute spent finding the lever holder is spent inside it.

Take an IT-operations agent that provisions access for new hires, with a named business owner and a named technical owner. Both names are correct. A template it reads from is updated upstream, and it starts granting a role broader than the request specified. The business owner, accountable for the outcome, can't pull the provisioning access. They call the technical owner, who is on another team and got no alert, because nothing routed the incident to them. Twenty minutes pass, four more new hires get the broad role, and the reason is never mysterious afterwards. Two correct names, no defined path between them.

Where Fabriq Fits

Agentic Fabriq holds each user's credentials in a vault and attaches them server-side at the moment of the call, so the agent never handles the secret, and every call carries two identities, the agent and the acting user, into the audit record. An agent's effective tool list is the intersection of the user's scopes and the agent's, which is what makes a scope change narrow what the agent can reach.

It does not reach into the provider for you. Clearing a vault copy is not the same act as invalidating a grant upstream, so the provider's revocation endpoint stays on the escalation row of your own record.

Frequently Asked Questions

Who is legally responsible if an AI agent makes a mistake? In the EU, the organization deploying it, as the "deployer" using the system "under its authority", unless it has crossed into being the provider under Article 25 by rebranding the system, substantially modifying it, or changing its intended purpose. Liability attaches to organizations and the natural persons they assign, never to the agent.

Is the AI vendor or the company using the agent responsible? Both, for different things. The provider carries conformity, documentation and the Article 72 duty to "establish and document a post-market monitoring system". The deployer carries use according to instructions, human oversight, logging and incident reporting.

Can an AI agent be held liable? No. The AI Act's definitions cover providers and deployers as natural or legal persons, and nothing in the text assigns duties to the system itself.

What does "authority" mean in Article 26(2)? Read alongside Article 14(4), that the assigned person can disregard, override or reverse the output and "interrupt the system through a 'stop' button or a similar procedure". If your named overseer has to file a ticket to stop the agent, that is the test they fail.

Who should own an AI agent, the business or IT? The business owner should own the judgment about whether the outcome is acceptable. Someone has to own each lever. Record the levers separately and the argument mostly disappears.

What happens when the person who created an agent leaves? By default the agent becomes ownerless, which Microsoft's registry counts as a distinct condition arising when "you delete the user who created them from the organization". Entra instead transfers sponsorship to the departing sponsor's manager. Failing either, AC-2(3) says to disable accounts that "are no longer associated with a user or individual".

How fast do we have to report an agent incident? Under Article 73, within 15 days of becoming aware, two days for a widespread infringement or serious disruption of critical infrastructure, and 10 days where someone has died.

Does the August 2026 deadline still apply to high-risk systems? No. The Commission's framework page now puts Annex III high-risk rules at 2 December 2027 and product-embedded Annex I systems at 2 August 2028.

Conclusion

The goal of naming an owner was never to have someone to blame. It was to guarantee that when an agent does something wrong, someone can change what happens next. A name accomplishes the first goal alone. It accomplishes the second only when attached to a real mechanism, or to a fast path to whoever holds one.

Ask the uncomfortable version for every agent you're accountable for: if this goes wrong at 02:00, what can I do about it, right then, with nobody else awake? Write the answer down next to the name. Then pull the lever once in staging and record the date.

Sources

All URLs read 2026-09-29.

• Agent Access Control Taxonomy — the identity-model dimension, whose terms decide whether "disable the agent" is a lever at all or the same act as disabling a human.
• EU AI Act Article 3, Definitions — the definitions of "provider", "deployer" and "substantial modification"; no category exists for the system itself.
• EU AI Act Article 14, Human Oversight — 14(4)(d) on disregarding, overriding and reversing output, and 14(4)(e) on the 'stop' button and halting in a safe state.
• EU AI Act Article 25, Responsibilities Along the AI Value Chain — the three conditions under which a deployer becomes a provider.
• EU AI Act Article 26, Obligations of Deployers — "competence, training and authority" in 26(2), the duty to inform the provider and suspend use in 26(5), and the six-month log retention floor in 26(6).
• EU AI Act Article 73, Reporting of Serious Incidents — the 15-day, two-day and 10-day reporting deadlines measured from awareness.
• EU AI Act Article 99, Penalties — the EUR 15 000 000 / 3 percent band that covers Article 26, against the 7 percent band for prohibited practices.
• European Commission, AI Act regulatory framework — the Digital Omnibus amendments in force 27 July 2026, moving Annex III to 2 December 2027 and Annex I to 2 August 2028.
• NIST AI Risk Management Framework 1.0 (AI 100-1) — GOVERN 2 and 2.1 on empowered accountability structures, GOVERN 3.2 on differentiating human-AI oversight roles, MANAGE 2.4 on applied deactivation mechanisms.
• NIST SP 800-53 Rev. 5, control AC-2 — assigning account managers, aligning account management with termination and transfer, and AC-2(3) disabling accounts no longer associated with an individual.
• Governing agent identities, Microsoft Entra ID Governance — sponsors as the humans "accountable for making decisions about its lifecycle and access", enable/disable from My Account, and automatic sponsorship transfer to the manager.
• Agent Registry in the Microsoft 365 admin center — the "Agents without owners" count, how agents become ownerless, and blocking or deleting as the available remediation.
• OWASP Top 10 for Agentic Applications — the ASI01-ASI10 categories, including ASI09 Human-Agent Trust Exploitation and ASI10 Rogue Agents.