Who Is Accountable When the Agent Acts?

The first wave of AI at work produced drafts and summaries, and a person reviewed every output. The second wave produces actions. An agent that answers a customer, approves a refund, updates a contract record, or books a vendor payment is making a decision with consequences, often faster than anyone can watch.

That shift moves AI from a technology question to a management one. This playbook is for the people who answer for the outcome: executives, functional leaders, risk and legal owners, and the board. It sets out an operating model for governing agents that does not require reading code. The technical build of the control layer is in the agent guardrails guide, and the market landscape is in the analysis of the two governance models.

The Accountability Gap

Three conditions produce most agent incidents, and none of them is a model failure.

• No one is accountable. A team builds an agent to save time, it works, and others start relying on it. When it misbehaves, nobody is sure whose job it is to fix, pause, or explain it.
• No boundary exists. The agent has the credentials of whoever set it up, which are usually far broader than the task needs. It can do things nobody intended, and nothing stops it.
• No one is watching. The agent runs unattended, errors accumulate quietly, and the first signal is a customer complaint, an audit finding, or a news story.

Recent incidents involving agents acting beyond their remit show the pattern. See our coverage of rogue agent incidents and how an agent can be misled by untrusted input. The lesson for leaders is that governance is cheapest before the incident and expensive after it.

The Principle: An Owner, a Boundary, and an Off Switch

The three requirements are deliberately simple, because leaders can verify them without technical depth. Ask, for any agent: who is accountable for it, what is it allowed to do, and how do we stop it. If the answers are vague, the agent is not governed.

The Governance Operating Model

The stages repeat for every agent, whether built in house, configured on a platform, or bought from a vendor. Governance is a loop, not a launch checklist: the register is reviewed, tiers are revisited, and incidents change the rules.

Stage 1: Inventory and Ownership

Start with a census. Most companies discover they have more agents than they thought, including ones created by individual employees with personal access, automations that gained AI steps over time, and agent features switched on inside vendor products.

Run the census through several channels: ask each function head, review the identity and access system for non-human accounts, scan for connections between systems, and check vendor admin consoles. Offer an amnesty. People who built an unregistered agent should be thanked for registering it, not penalized, or the register will be incomplete.

An agent with no owner is paused until it has one. This single rule resolves most of the accountability gap.

Stage 2: Tier by Risk and Autonomy

Two questions determine how much oversight an agent needs: how much damage can its actions do, and how much freedom does it have to act without a person.

Rate the risk of its actions

Set the autonomy level

Combine the two to set the rule. A low-risk agent can earn higher autonomy quickly. A high-risk agent starts at suggest or approve and moves up only with a track record. Irreversible actions, such as releasing a payment or deleting data, never go above approve without explicit executive sign-off and compensating controls.

Autonomy is earned, and it can be revoked. An agent that performs well for a quarter at one level can be considered for the next. An agent that causes an incident drops a level until the cause is fixed.

Stage 3: Set Hard Boundaries

A boundary is a limit enforced outside the agent. Telling an agent in its instructions not to do something is a request. Removing its ability to do it is a control. Leaders should insist on the second.

Your technical team builds these, and the guardrails guide explains how. The leader's role is to ask for evidence: show me the permissions, show me the limit being enforced, show me the switch working.

Stage 4: Approve and Launch

A launch gate confirms the owner, boundaries, and monitoring exist before the agent runs on production work. Scale the gate to the tier so low-risk agents move quickly and high-risk agents get scrutiny.

Pilot every medium and high-risk agent alongside a person before it acts alone. A pilot reveals the exceptions that testing does not, and it produces the track record that justifies a higher autonomy level.

Stage 5: Monitor and Intervene

Running an agent without monitoring is delegating without looking. Monitoring answers three questions: what did it do, did it stay inside its boundary, and is it still doing the job well.

• An action log: every action the agent takes, with inputs, outputs, and the rule that allowed it, kept long enough to investigate.
• Boundary alerts: notices when the agent approaches a limit, is blocked by one, or tries something outside its list.
• Quality sampling: a person reviews a regular sample of outputs, with more samples for higher tiers and newer agents.
• Drift checks: comparisons over time of error rates, exception rates, and customer feedback, since model and data changes can shift behavior without notice.
• Cost and volume watch: unusual spikes often signal a loop or a misuse.

Assign the monitoring to a named person per agent, usually the owner or a delegate. An alert nobody receives is decoration. The multi-agent workflow guide covers monitoring patterns when agents hand work to each other, which multiplies the places a failure can hide.

Stage 6: Respond, Review, and Retire

Incident response

Decide before the incident who can pause an agent, who must be told, and how customers and regulators are informed. Write it down and rehearse it once. During an incident, the first move is containment: pause the agent, revoke credentials, and preserve the logs. Diagnosis comes second.

Retire what you no longer need

Agents outlive the projects that created them. Credentials stay active, subscriptions renew, and nobody remembers the owner left. Review the register on a schedule, and retire agents that no longer have an owner or a purpose: revoke access, archive the logs, and close the entry.

Decision Rights

Governance fails when decisions fall between functions. Write down who decides what.

Give the risk lead authority to stop a launch. A governance function that can only advise will be bypassed the first time a deadline appears.

The Governance Rhythm and Board Reporting

A small group meets on a fixed schedule: a risk lead, a security lead, legal and privacy representation, and the business owners of the highest-tier agents. Monthly is typical early on, and quarterly once the program matures.

Report to the executive team and board on a short page each quarter: how many agents, by tier and autonomy level; incidents and near misses; open exceptions; and the top three risks. Directors do not need the technical detail. They need to know that someone is accountable and that the numbers are moving in the right direction.

An Illustrative Walkthrough

The scenario below is illustrative, not a company case.

A support director wants an agent to issue small refunds. The proposal goes into the register with the director as owner. The risk lead tiers it high, because it moves money, and sets the starting autonomy at approve: the agent prepares each refund and a person releases it.

Security gives the agent a dedicated identity that can read order records and create refund requests but cannot release payments. The payment system enforces a per-refund cap and a daily total, so the limits hold even if the agent is manipulated by a hostile message. The agent runs in pilot for six weeks beside a human reviewer, and the team logs every disagreement.

After the pilot, error rates are low, and the risk lead and owner agree to move refunds under a small amount to act with limits, with sampling. Larger refunds stay at approve. Three months later, a spike in refunds triggers a boundary alert. The owner pauses the agent, finds that a customer had embedded misleading instructions in a message, and tightens the input rules. The incident is written up, the rule change is added to the gate checklist for all agents, and the next quarterly report shows one incident, contained in hours.

Where This Breaks

Measuring Governance

Choose a few measures that show coverage, control, and learning. Leaders should be able to read them in a minute.

Treat a rising count of near misses as a sign of a working program, not a failing one. People report what they trust will be handled constructively.

What You Need to Build This

Most of the program is people and decisions. Start with the register, the tiers, and the decision rights on paper. Add tooling as the register grows.

Plan for ongoing costs

Governance has running costs beyond any template. Agents run on automation platforms and AI models billed by usage. Whether you use an n8n instance or a Zapier plan, the platform is billed separately by its vendor, and Zapier counts AI steps as multiple tasks depending on the model tier. Monitoring, logging, and review also take staff time. Estimate agent volumes and review effort before you scale, and verify current pricing on each vendor's page.

A 90-Day Roadmap

After 90 days, widen to vendor agents and the lower tiers, and move toward a quarterly rhythm. Expect the register to grow as people see that registering is easy.

Conclusion: Autonomy Is Earned

Agents are useful because they act, and risky for the same reason. Governance does not stop that. It makes sure someone answers for each agent, that each one has a limit the systems enforce, and that anyone can stop it.

Begin with the census, give every agent an owner, and let autonomy grow only as the evidence builds. Leaders who do this will deploy agents faster than those who do not, because they will trust what they have built.