Your AI agent has permissions. Who has responsibility?

An AI agent needs an accountable human owner before it gets authority to change anything important. That owner needs a defined outcome, access boundaries, a review process and a way to stop the system. Naming the software after a colleague does not supply any of these things. It does, however, make the incident review sound unusually personal.

The 2026 conversation is moving beyond employees asking a chatbot for a draft. In Microsoft's 2026 Work Trend Index, agents and the design of human work are central themes. Its survey covers people already using AI, so it should not be read as a census of every workplace. The management question is nevertheless useful: when execution is delegated, where does responsibility stay?

An agent owner is different from the person who bought the licence

Procurement can approve a supplier. IT can manage access. A product team can build a workflow. The business owner must still decide what a satisfactory result means and which mistakes the organisation can tolerate. These responsibilities may sit with different people, but they must connect.

Write one sentence: “This workflow helps this group achieve this result, and this person can decide whether it continues.” If nobody can complete the sentence without naming a committee, the agent is about to inherit an unresolved organisational problem. It will process that problem enthusiastically.

For a hypothetical customer service agent, the business owner might own resolution quality, IT might own credentials, and a support lead might supervise exceptions. None of these assignments removes the company's responsibility to its customers. The operational owner needs enough authority to pause the workflow when those responsibilities conflict.

Match permissions to consequences

Start by separating observing, drafting, recommending and acting. Reading a public FAQ is different from reading personnel files. Drafting a refund message is different from sending it. Suggesting a refund is different from transferring money. A single “AI enabled” switch hides these distinctions.

Build a short permission record for each tool connection: what can be read, what can be changed, which accounts are involved, and which actions need approval. Give access for the actual task. Avoid a powerful shared account simply because it made the demo easier. Cisco's privacy benchmark research is a useful companion for the data governance questions, rather than a substitute for your own review.

In the support example, the first version could retrieve approved guidance and prepare a response. A person checks the case and sends it. Only after reviewing real performance should the team consider a narrowly defined automatic action. Permission should follow evidence, rather than arrive as a welcome gift.

Human review needs a real decision

A reviewer who receives hundreds of near identical suggestions, has seconds to approve each one and is measured only on speed is not much of a safeguard. The organisation has created an approval queue with a human-shaped button.

Tell the reviewer what to check, which evidence is available and what uncertainty should trigger escalation. Reserve capacity for that work. Review a sample of apparently successful cases too, because serious mistakes do not always introduce themselves as exceptions. For sensitive decisions, ask qualified specialists what additional controls apply.

The European Commission's AI Act guidance distinguishes obligations and implementation dates by system and use. A generic productivity workflow and an employment decision tool should not share a casual compliance assumption. This article offers an operating approach, not a legal classification of your particular system.

Define the stop rule before the interesting failure

Agree the conditions that pause the workflow: unexpected access, incorrect external commitments, a material quality failure or an unexplained change in behaviour. Specify who receives the alert and who covers the work while the agent is stopped. “Contact the AI team” is incomplete if that team has no on-call responsibility.

Keep an action trail that helps reconstruct what happened, with appropriate data protection and retention limits. Record the source information, significant tool actions and approvals necessary for investigation. Collecting everything forever creates another problem. The record should answer a business question, not become a second ungoverned archive.

Practice one recovery scenario. If the agent updates the wrong customer record, can you identify affected cases, correct the state and communicate with the right people? An undo button is useful. Knowing who is allowed to press it is also useful.

Measure the complete workflow

Track accepted outcomes, rework, exceptions and the human time needed to supervise. Compare these with a baseline for similar work. More actions per hour are not automatically more value, especially when colleagues spend the afternoon correcting them.

Use the same distinction in AI automation ROI: local speed can move effort to somebody else. A workflow that produces faster drafts but slower approvals may still be worthwhile, but the trade-off should be visible. Agree a review date and an explicit decision to continue, narrow or stop.

Give the owner a small operating agreement

Before launch, record six items together: intended outcome, accountable owner, authorised actions, review responsibilities, stop conditions and evidence for success. Keep it short enough to use during an incident. Link the supplier documentation and technical details separately.

Workday's October 2026 adaptability report provides another perspective on changing work and responsibilities. My recommendation is to treat the organisational design as part of the product, rather than documentation added after deployment. When the process remains fuzzy, an agent can multiply that fuzziness at a very respectable speed.

If the real issue is that teams are already using tools outside that agreement, read how to handle shadow AI. If ownership, delivery and adoption need connecting, my product and forward deployed engineering experience explains where I can help. Tell me which workflow you want to put into production, including the part that currently makes everyone nervous.

Questions people ask

Who should manage AI agents in a company?

Assign a business owner for the outcome, technical owners for access and reliability, and named people for review and exceptions. One person should have authority to pause the workflow. The exact structure depends on the consequences of the task; buying a licence or building an integration does not by itself settle business accountability.

What should an AI agent operating agreement include?

State the outcome, owner, permitted data and actions, approval requirements, escalation route, stop conditions and measures of success. Include how the team will investigate an error and restore service. Review the agreement when the task, model, connected tools or consequences change.

Is human approval enough to make an AI agent safe?

Approval is useful only when the reviewer has relevant evidence, time, training and authority to disagree. A rushed approval queue can become a rubber stamp. Test the full workflow, examine successful-looking cases and use additional controls appropriate to the task and applicable rules.