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, 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. Most accountability models assume one team builds, runs and owns an application. Agents are assembled from parts that different teams own, so the assumption fails exactly when it is needed. The fix is structural: owners defined by the decisions they make, and credentials that depend on those owners existing. Here is how one afternoon goes without them.
Teardown: one afternoon at Marlow
Marlow is a fictional B2B software company with about 600 employees, and its story is illustrative.
Step 1: a useful agent, built outside the usual lines
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.
Step 2: every credential was borrowed
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.
The agent was built by one team, ran on credentials other teams had issued, and acted in three systems whose owners were never consulted. Each orange marker is a question nobody on the incident call could answer.
Step 3: one wrong digit
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 ceiling lived in the prompt, so nothing in billing refused them. The renewals desk noticed after several dozen had gone out.
Step 4: nobody could stop it without breaking something else
Finance could revoke the shared billing key, but that 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.
Step 5: four questions without answers
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. Each was an ownership question nobody had been assigned.
Why it fails the same way everywhere
A conventional application has one owning team that writes the code, deploys it, holds its credentials and answers for its data. An agent splits those duties. The credential's owner is accountable on paper for actions they did not design. The target system's owner approved an integration months ago for a different purpose and never reviewed the agent. The business unit gets the productivity gain while the teams that own the systems and credentials absorb the risk, so nobody holds both the authority and the incentive to say no. And 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].
Fix 1: four owners, defined by what they decide
Define ownership by decision rights, not by org chart. One person may hold two roles in a small company, but each role needs exactly one name. A team alias is fine for paging and never for accountability.
| Role | Usually held by | Decides | Must be able to do within 15 minutes | Is not responsible for |
|---|---|---|---|---|
| Builder | The engineer or team that wrote the prompt, tools and integrations | What the agent tries to do, which model it uses, how its tools are defined | Explain why the agent took a given action, from its logs | Granting the agent access to systems they do not own |
| Operator | The team that runs it in production and carries the pager | When to deploy, pause or roll back; how credentials are stored and rotated | Stop every run of the agent without breaking anything else | Deciding whether a paused agent goes back into service |
| System owner (one per system touched) | The existing owner of the CRM, billing, ticketing or data store | What the agent may do in their system and within which limits | Revoke the agent's access to their system alone | The agent's behavior in other systems |
| Risk owner | An accountable leader in the business unit that benefits | Whether residual risk is acceptable; exceptions; return to service after an incident | Make a go or no-go call on restarting the agent | Day-to-day operation |
| Security (advisor, not owner) | Security engineering or the AI governance function | The control floor every agent must meet; review and monitoring | Pull detection and decision logs for the agent | Owning or accepting the agent's risk |
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, 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.
Two placements matter most. The risk owner is never the security team, because the function that advises on risk cannot also accept it; listing the CISO as risk owner for every agent turns accountability back into advice. 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.
Fix 2: write the RACI for the arguments you will actually have
Generic 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.
| Decision | Builder | Operator | System owner | Risk owner | Security |
|---|---|---|---|---|---|
| Add a tool or a new connection | R | C | A for their system | I | C |
| Grant or widen access to a system | C | R | A | I | C |
| Raise a limit, such as a discount or refund ceiling | C | R | A | A | C |
| Change the model, prompt or retrieval sources | R | A | I | I | C |
| Pause the agent during an incident | R | R | R | R | R |
| Return the agent to service after an incident | C | R | C | A | C |
| Grant a time-limited exception to a control | C | R | C | A | C |
| Notify affected customers or partners | C | I | C | A | C |
| Quarterly access review | I | R | A for their system | I | C |
| Retire the agent and revoke its credentials | C | R | I | A | I |
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's MANAGE 2.4 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 in 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 Marlow, the billing team would have refused a shared key with unlimited write access, and the agent would have had a quote-only credential with the discount ceiling enforced in billing itself.
Fix 3: a register built from evidence, not surveys
GOVERN 1.6 asks for mechanisms to inventory AI systems, resourced according to risk priorities [1]. For agents, an inventory is useful only if it records authority as well as existence. Keep one row per agent with a stable ID and a one-sentence purpose a stranger could check behavior against; the four owners, linked to their identity-provider accounts so departures are detectable; every credential, with who issued it, its scope and its expiry; the systems it acts in and the highest-consequence action in each, from read to money and administrative changes; the data classes it reads and every channel through which an outsider can put text in front of it; how to stop it and when the stop was last tested; and its lifecycle status and last access review.
Do not fill 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: 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 row is a finding with an owner and a due date. Include vendor agents: AI features inside your SaaS tools act on your data too, NIST GOVERN 6.1 expects policies for third-party AI risk [1], and they need a system owner and a risk owner even if you never see the prompt.
Fix 4: no owner, no credentials
A register decays within a quarter unless something depends on it. Credentials are the dependency that works, because an agent cannot run without them.
Credentials are issued only against a register entry with four active owners, and an owner's departure opens a reassignment task that suspends the agent if nobody takes it. The agent never runs on authority that nobody answers for.
- Give every agent its own identity. Never let it run on a person's token, a shared integration user or a key other tools also use. Shared credentials are what made Marlow's stop impossible, and temporary shared keys are the ones nobody can revoke during an incident.
- 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.
- Put an expiry on every agent credential and make renewal a deliberate act by the operator, who confirms the owners and scopes are still right.
- Connect the register to joiner, mover and leaver events. When an owner leaves, open a reassignment task; 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].
- Scope each credential to what the system owner approved, recorded with their name and the date. OWASP's Excessive Agency guidance points the same way: limit downstream permissions to the minimum necessary and act in the context of the specific user where possible [3].
- Run a quarterly recertification in which each system owner confirms the 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.
Intertrace helps with the evidence-dependent parts. 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. Deciding who owns an agent, and connecting ownership to your identity provider, remain practices your organization implements.
Marlow, replayed
After the review, Marlow 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. Email can go only to the contact on the CRM record. The operator added a single pause and tested it with the renewals desk watching. In the tabletop that replayed the original incident, the operator paused the agent in minutes, the billing owner confirmed no quote above the ceiling could have been created, and the risk owner decided when it came back.
The test to run on Monday
Pick one production agent. Ask someone outside its team who can stop it, and time the answer. Then request a credential for an agent with no register entry and confirm it is refused, and trace one random action from last week to the agent, its owners and the approval that granted that access. If any of the three fails, start with the evidence list: keys, grants, integration users and repository configurations, each matched to an agent or marked unknown. An agent nobody will accept as risk owner is a decision to retire it.
