Nobody owns the agents: fixing AI accountability before the first incident

The first serious agent incident in most companies does not start with a clever attack. It starts with a bridge call. An agent has done something visible and wrong, such as emailing customers the wrong offer or closing tickets it should not have touched, and five teams are on the line. The platform team says it only hosts the runtime. The team that built the agent says operations runs it. The owner of the affected system says nobody asked them before the agent was given access. Security says it was never told the agent existed. Forty minutes in, nobody has turned it off.

That is not a culture problem, and a policy memo will not fix it. Agents are assembled from parts that different teams own, while most accountability models assume one team builds, runs and owns an application. This guide replaces that assumption with something that holds up on the bridge call.

Why agents fall between teams

A conventional internal application has an owning team that writes the code, deploys it, holds its credentials and answers for its data. An agent splits those duties. The prompt and tools are written by whoever had the idea, often a business operations team using a low-code builder. The runtime and the credentials belong to whoever had a service account or an API key to spare. The actions land in systems such as the CRM, billing or the ticketing platform, each of which already has an owner who was not part of the project.

• Borrowed credentials. The agent authenticates as an integration user, a shared API key or a person's OAuth token. The credential's owner is accountable on paper for actions they did not design and often do not know about.
• Inherited authority. The agent can do whatever its credential can do. The owner of the target system never reviewed the agent's actions; they approved an integration months ago for a different purpose.
• Split benefit and risk. The business unit gets the productivity gain. The teams that own the systems and the credentials absorb the risk. Nobody with both the authority and the incentive is in a position to say no.
• Departures. When the person who wired the agent leaves, the agent keeps running. OWASP calls these orphaned identities: the original owner departs, and the identity stays active without a new designated owner [2].

A worked example: the renewal agent at Corvane

Consider Corvane, a fictional B2B software company with about 600 employees. Revenue operations built a renewal agent in a hosted agent builder. It reads upcoming renewals from the CRM, drafts quotes, applies discounts up to a ceiling the team set in the system prompt, writes the quote into billing and emails the customer contact. It saved the renewals desk a day a week and everyone liked it.

Look at what it ran on. CRM access came through an integration user created by a sales-operations administrator who had since left. Billing used a shared key that finance engineering had issued to several internal tools. Email went out through marketing's sending domain. Four teams were involved, and none of them had agreed to own the agent.

Then a pricing sheet the agent retrieved was edited with a misplaced digit, and the agent began issuing quotes with a much larger discount than intended. The renewals desk noticed after several dozen had gone out. Finance could revoke the shared billing key, but doing so would also stop invoicing for three other tools. The departed administrator's integration user had no current owner, so the CRM team was reluctant to disable it without knowing what else depended on it. Revenue operations could edit the prompt but could not stop the runs. The agent kept working for most of an afternoon.

The post-incident review found four questions nobody could answer quickly: who can stop this agent, who approved its access to billing, who decides whether it comes back, and who tells the affected customers. Every fix in this guide exists to make those four answers boring.

Four owner roles, defined by the decisions they make

Define ownership by decision rights, not by org chart. An agent needs four roles filled by named people. One person may hold two roles in a small company, but each role must have exactly one name next to it, and a team alias is fine for paging but never for accountability.

This maps directly to the NIST AI Risk Management Framework. GOVERN 2.1 asks that roles and responsibilities for mapping, measuring and managing AI risks be documented and clear to individuals and teams throughout the organization, and GOVERN 2.3 asks that executive leadership take responsibility for decisions about risks from AI system development and deployment [1]. The risk owner is how that executive responsibility reaches a specific agent instead of staying in a policy document.

Two placements matter most. The risk owner should never be the security team, because the function that advises on risk cannot also accept it. And the system owner role is plural: an agent that touches four systems has four system owners, each approving only what happens in their own system.

A RACI for the decisions that actually come up

Generic RACI charts list activities like build, run and monitor. Write yours against the decisions that cause arguments during incidents and change reviews. R does it, A signs off, C is consulted before, and I is informed after.

Notice the asymmetry in the pause row. Anyone on the chart may stop the agent, with no approval and no blame for a false alarm. Restarting it needs the risk owner. Stopping should be cheap and widely held; starting again should be narrow and deliberate. NIST makes the same point in MANAGE 2.4, which asks for mechanisms and assigned, understood responsibilities to supersede, disengage or deactivate AI systems whose outcomes are inconsistent with intended use [1]. A pause that only the builder knows how to perform does not meet that bar.

The other rule built into the chart is that access to a system is always approved by that system's owner. Builders propose, operators request and system owners decide. At Corvane, the billing team would have refused a shared key with unlimited write access, and the agent would have been given a quote-only credential with the discount ceiling enforced in billing itself.

The agent register: one row per agent, kept true by machines

GOVERN 1.6 asks for mechanisms to inventory AI systems, resourced according to risk priorities [1]. For agents, an inventory is only useful if it records authority as well as existence. Keep one row per agent with these fields.

• A stable agent ID and a one-sentence purpose that a stranger could check behavior against.
• The four named owners, linked to their identity-provider accounts so that departures are detectable.
• Every credential the agent holds: which identity, who issued it, its scope, and when it expires.
• The systems it can act in and the highest-consequence action available in each, for example read, reversible change, irreversible change, outbound message, or money and administrative changes.
• The data classes it reads and every channel through which someone outside the company can put text in front of it.
• How to stop it, who last tested the stop, and when.
• Lifecycle status (pilot, production, suspended, retired) and the date of the last access review.

Do not populate the register by survey alone. Teams forget agents they consider experiments, and nobody lists the agent they wired on a personal token. Start from evidence instead: API keys in your AI provider organizations, OAuth grants to AI applications in your identity provider, integration users in your SaaS systems, and agent and MCP configuration files in your repositories. Every credential you cannot match to a register row is a finding with an owner and a due date.

Make ownership enforceable: no owner, no credentials

Ownership written in a register decays within a quarter unless something depends on it. The dependency that works is credentials. An agent cannot run without them, so tie their issuance and renewal to a complete, current set of owners.

1. Give every agent its own identity. Never let an agent run on a person's token, a shared integration user or a key that other tools also use. Shared credentials are what made Corvane's stop impossible.
2. Require a register ID on every credential request, and have the issuing process check that all four owners exist and are active accounts before it issues anything.
3. Put an expiry on every agent credential and make renewal a deliberate act by the operator, who confirms that the owners and scopes in the register are still right.
4. Connect the register to joiner, mover and leaver events. When an owner leaves or changes teams, open a reassignment task automatically; if nobody accepts it within a fixed window, suspend the agent rather than deleting it. OWASP's guidance for departing staff is the same: transfer ownership to another employee and rotate any credentials the person had access to [2].
5. Scope each credential to the system owner's approval, recorded with the owner's name and the date. OWASP's Excessive Agency guidance supports this from the other direction: limit downstream permissions to the minimum necessary and act in the context of the specific user where possible [3].
6. Run a quarterly recertification where each system owner confirms the list of agents acting in their system. Anything not confirmed is suspended at the next renewal.

Keep a sandbox lane so experiments stay fast: synthetic data, credentials that reach nothing real, and the builder as the only owner. The four-owner rule applies when an agent first touches production data or a production system, which is when its failures start to matter.

What goes wrong in practice

• The register is a one-off spreadsheet. Within weeks it describes last quarter's agents. If no system reads it at credential time, assume it is wrong.
• The CISO is listed as risk owner for every agent. That converts accountability back into advice and leaves the business decision unmade.
• An owner is named who cannot actually stop the agent. Test the stop with the operator on a schedule and record who did it.
• Shared keys are kept temporarily. Temporary shared keys are the ones nobody can revoke during an incident.
• Vendor agents are left out. AI features inside your SaaS tools act on your data too; NIST GOVERN 6.1 expects policies for third-party AI risk [1]. They need a system owner and a risk owner even if you never see the prompt.

Corvane, rebuilt

After the review, Corvane named the revenue operations engineer as builder, the internal tools team as operator, the CRM, billing and email owners as system owners, and the vice president of revenue as risk owner. The agent got its own identity in each system. Billing issued a credential that can create quotes but not invoices, with the discount ceiling enforced by billing rather than by the prompt. Email can go only to the contact on the CRM record. The operator added a single pause that stops all runs and tested it with the renewals desk watching.

In the tabletop exercise that followed, the facilitator replayed the original incident. The renewals desk paged the operator, who paused the agent in minutes; the billing owner confirmed no quote above the ceiling could have been created; and the risk owner decided when the agent came back. The four questions had answers before anyone asked them.

A 30-day plan and the tests that prove it worked

1. Week 1: build the evidence list. Pull AI provider keys, identity-provider grants to AI apps, SaaS integration users and repository agent configurations. Match each to a known agent or mark it unknown.
2. Week 2: create register rows for every agent that touches production, and fill the four owner roles. Escalate rows where nobody will accept the risk owner role; an agent nobody will own is a decision to retire it.
3. Week 3: replace shared and borrowed credentials with per-agent identities, starting with the agents whose highest-consequence action is outbound, financial or administrative. Record each system owner's approval.
4. Week 4: wire credential issuance and renewal to the register, connect leaver events, and run a pause drill for each production agent with its operator.

Then verify with tests rather than status reports. Ask someone outside the team who can stop a named agent and time the answer. Request a credential for an agent with no register entry and confirm it is refused. Deactivate a test owner account in the identity provider and confirm the reassignment task opens and the agent suspends when it expires. Pick a random agent action from last week and trace it to the agent, its owners and the approval that granted that access.

How Intertrace handles it

Intertrace helps with the parts of this that depend on evidence. Read-only discovery scans cloud accounts, repositories, identity providers' AI-app grants and AI provider organization keys, and opens each unmatched finding as a work item; key values are never stored, only a masked form and fingerprint. At runtime each agent calls models, tools and MCP servers through the gateway with its own runtime key, and every decision is recorded with the agent, the rule and the layer that made it, so the question of which agent did what, and under whose policy, has a direct answer. Exceptions are named, scoped to one agent and expire. Deciding who owns an agent, and connecting ownership to your identity provider, remain practices your organization implements.