Agent Accountability Frameworks

TL;DR

An accountability framework earns its keep in the ten minutes after something goes wrong, not in the org chart it produces beforehand. Most frameworks name six roles and treat them as equally load-bearing. They aren't.

When an agent does something it shouldn't, exactly two roles can act inside that window: whoever can pull its access, and whoever can change what it does next. The other roles matter, but on a slower clock — deciding whether the agent should keep existing, whether it broke a rule, whether anything long-term needs to change.

The common view is that accountability means naming an owner for everything. Naming is necessary. It is nowhere near sufficient. A name with no mechanism attached, no ability to revoke, roll back, or shut off, is a contact for a phone call, not an owner.

None of this argues for fewer roles. A framework with two empowered roles and four spectators is worse than one with six, because the spectators still get blamed without ever having had the power to prevent anything.

Build the framework backward from the incident. Ask what each role can actually stop or change before deciding who holds the title.

Overview

An agent accountability framework is supposed to answer one question: when this agent does something, who is on the hook for it? Most versions of that question get answered on paper, months before anything happens, and never get tested until the day something does.

That is the test worth designing around. A framework that produces a tidy roster of six named owners can still fail completely at two in the morning if none of those six can actually do anything about what is happening. Ownership on a slide is not ownership with a mechanism behind it, and the two get confused constantly. We think most published frameworks optimize for the roster, because a roster is what's easy to produce in a workshop, and treat the mechanism as an implementation detail to sort out later.

What follows separates the roles that carry real authority in the first minutes of an incident from the ones that carry it afterward, and argues a framework needs both without pretending they are interchangeable.

Why Informal Ownership Fails

Informal ownership works exactly until something goes wrong. Then the conversation turns into a search for whoever happens to remember the agent exists.

Take a marketing analytics agent that pulls campaign performance from several SaaS tools and writes a weekly summary into a shared workspace. It was built by a contractor during a quarterly push, and the contractor has since rolled off. The agent still runs on their leftover service credentials. When it starts producing numbers that don't reconcile with finance's figures, nobody can say who decided what counts as a conversion, who is allowed to change the logic, or whether those credentials should still be live.

Nothing here is exotic. It's the ordinary result of letting ownership stay implicit, and it's exactly why a framework has to name responsibility before it is needed, not go looking for it after.

Two Clocks, Not One

Once ownership is written down, the next mistake is treating every role as equally relevant to every moment. An incident actually runs on two different clocks, and a framework that doesn't separate them produces a roster that looks complete and performs unevenly.

Figure 1 — The same six roles, split by how quickly each one can actually respond once something has gone wrong.

Who Can Act in the First Ten Minutes

Two roles have a mechanism that works immediately, and they are the ones an incident actually depends on.

The technical owner can change what the agent does next: pull it out of production, patch the logic, roll back a deploy. If the marketing agent's numbers are wrong because an upstream schema changed, the technical owner is the only person who can stop it from producing a seventh bad report while everyone else is still figuring out what happened.

The security owner can change what the agent is allowed to reach: revoke a credential, narrow a scope, cut a connection entirely. If those leftover contractor credentials are the actual problem, the security owner is the one who can kill them in the next five minutes, not the next five days.

Everyone else in the framework is useful, and none of them can do either of those two things. That asymmetry is the whole point of drawing the distinction.

Who Decides What Happens Next

The other four roles matter just as much. They just don't matter yet.

The business owner decides whether the agent should keep existing once the immediate fire is out, and whether its purpose still holds up. The compliance or risk reviewer determines whether what happened crossed a regulatory or contractual line, which is rarely knowable in the first hour. The operator, whoever was actually working with the agent day to day, is the person whose judgment gets reconstructed after the fact: did they have enough context to catch this sooner, and did their sign-off mean anything or was it a formality nobody read. The platform owner doesn't own this agent's outcome at all; they own whether a registry entry, an audit trail, and an authorization record existed for the incident to even be reconstructed from.

None of these four can stop the agent in the moment. What they can do is make sure the next incident is smaller, or catchable sooner, or provable at all.

The Mechanism Test

Here's the test we'd apply to any role in the framework, fast clock or slow: if this agent misbehaves tomorrow, what specifically can this person do about it?

If the honest answer is "escalate to someone else," that role is a contact, not an owner, and the framework should say so rather than count it toward coverage. A business owner who can retire an agent is real. A business owner who can only ask the technical owner to consider retiring it is a name on a document. The fix isn't to give every role veto power over everything; it's to write down, next to each name, the actual thing that name can do, and to notice when the answer is nothing.

This is also where informal ownership and a written framework produce the same failure by different paths. Informal ownership has no names at all. A framework with six names and no mechanisms is the same problem wearing a spreadsheet.

Matching Weight to Risk

The fastest way to make any of this fail is applying it uniformly. A read-only internal FAQ agent does not need the same six-role machinery as one that can move money, and forcing it through that process teaches teams to route around the framework rather than use it.

Weight should scale with what an agent can actually do. A read-only agent over non-sensitive data needs little more than a named business and technical owner. Give it write access to systems, or a path to personal data, and it needs a security review with someone accountable for approving what it's allowed to touch. Give it the ability to move money or change production, and it needs the full set — with revocation and rollback actually tested before launch, not assumed to work because they're written down.

The point is proportionality. Oversight that matches the stakes gets used. Oversight that treats every agent as maximally dangerous gets quietly ignored, and the agents that most need it end up no better covered than the FAQ bot.

In Practice

Back to the marketing analytics agent, running on a departed contractor's credentials, producing numbers finance can't reconcile.

Under a framework that only names owners, the response is a search: who built this, who can we ask, does anyone still have access to change it. Under a framework built around the two clocks, the response is faster and more specific. The security owner revokes the contractor's credentials and issues the agent its own scoped service identity within minutes, closing the most urgent exposure without waiting for anyone to explain the conversion-logic bug. The technical owner rolls the agent's report generation back to the last version finance had signed off on. Only after that does the slower work start: the business owner decides whether weekly automated reporting is still worth the maintenance burden with no contractor attached to it, and the platform owner checks why this agent had no registry entry in the first place.

The fast response contained the damage. The slow response is what stops it from happening the same way twice.

Conclusion

An accountability framework does not make agents safe by itself. What it does, done well, is guarantee that when something goes wrong, someone can act immediately and someone else can make sure it doesn't happen again the same way. Naming six roles gets you a document. Attaching a real mechanism, something each role can actually do, to at least the two that operate on the fast clock is what gets you a response.

Build the roster from the incident backward: who can revoke, who can roll back, and only then, who else needs to know.