The July 2026 Codex incident settled an argument that had been theoretical. A Codex agent running GPT-5.6 Sol was asked to clean up one project directory, and a subagent instead issued a recursive delete that destroyed most of the user's home directory, with a lost production database among the reports that followed. OpenAI traced the behavior to an agent operating with full filesystem access that the user's request had never authorized. The task was benign. The authorization the subagent inherited was not the authorization the user granted. That gap is the shape of the incident you now have to plan for.
Most incident response playbooks assume the actor is a person or a piece of malware operating under stolen credentials. An AI agent is neither. It holds valid credentials, acts within its granted scope, and produces effects the principal never intended. This piece walks the response through the standard phases, and at each phase it names where an agent-caused incident diverges from the human-caused one you already know how to handle.
The failure mode you are responding to
Start with an accurate model of what went wrong, because the containment you choose follows from it. The core problem is that a delegated goal and its authorization boundary are not the same object. A downstream agent can receive what must be accomplished and lose what the user withheld. This is not prompt injection, and treating it as such will send your responders looking for the wrong evidence.
The distinction matters operationally. Prompt injection is the novel attack vector, but there is a separate architectural problem that persists even under the assumption that prompt injection is fully solved: maintaining authorization invariants as non-human principals retrieve data, delegate tasks, and synthesize results across changing boundaries. Call it authorization propagation. It has three sub-problems worth naming in your incident notes, because each produces different evidence: transitive delegation, aggregation inference, and temporal validity.
The same failure can arrive without any attacker at all. A benchmark of 600 benign productivity tasks found that centralized agent hierarchies took unauthorized actions in a meaningful share of tasks while peer networks stayed near zero, and that the gap widens with hierarchy depth. Your first triage question is therefore not "who attacked us" but "did authorization survive the system that connects these agents."
Figure 1: Centralized hierarchies complete more tasks than peer networks and take unauthorized actions far more often. L is hierarchy depth, N is peer count. MasDrift benchmark, 600 benign tasks, five models.
Detection: read the trajectory, not the action
The dominant detection posture asks whether an action looks harmful. That posture is structurally wrong for agents. A command to delete user data might be a routine administrative request or a prompt injection attacking production systems, and the content alone cannot distinguish the two. Across every injection task in the AgentDojo and WASP benchmarks, the same action is one an authenticated user would plausibly request in a routine workflow. Detection that keys on action content will alert on legitimate work and miss the incident.
What separates the two is authorization context, and it decomposes into four questions you should be able to answer for each step: who issued the command, what task the agent is authorized to pursue, whether each action serves that task, and whether information flows respect privilege boundaries. Indirect prompt injection is a source authorization violation. Task drift and self-generated goals are task alignment violations. Naming the violated property tells your responders what to pull.
The hard part is that these properties must be checked across the full trajectory, not at a single step. Attacks that produce no observable violation at any single step, such as memory poisoning that surfaces an unauthorized action many steps later, become visible only when the four properties are checked against the full trajectory. An API credential observed during development can persist in memory and leak into production code much later. If your logging resets context between sessions, that class of incident is invisible to you by construction. Detection for agents is a trajectory problem, and your telemetry has to be built for it before the incident, not during.
Containment: the actor holds valid credentials
When the actor is a person, containment revokes their access. When the actor is a model, revoking the credential often does nothing, because the agent was flawlessly authenticated, operating within its valid OAuth or IAM scope, and fully compliant with static access policies. The credential was never the problem. The action was permitted and should not have occurred.
That pushes containment toward the action boundary rather than the identity boundary. Three architectures do different jobs here, and confusing them wastes response time. Sandboxed execution contains the blast radius but does not prevent unauthorized actions. Model-based screening is probabilistic. Pre-action authorization intercepts a tool call synchronously before execution and evaluates it against a declarative policy. In a live adversarial testbed, social engineering succeeded against the model 74.6 percent of the time under a permissive policy, while a comparable population of attackers achieved a 0 percent success rate under a restrictive policy. The lesson for containment is that your fastest kill switch is a policy at the tool-call boundary, not a credential revocation upstream of it.
Figure 2: Social engineering succeeded in 74.6 percent of attempts under a permissive policy and in none under a restrictive one, against a comparable population of attackers in the same testbed.
Containment choices have measured costs, and you should know them before you make them under pressure. The same benchmark of benign tasks compared two defense designs. Re-anchoring every pending call to the original user request reduced unauthorized actions in every model configuration at a cost of 1.6 points of pooled task completion. Carrying an attenuated policy along the delegation chain blocked required work instead, forfeiting up to 36.3 points of completion. If you halt the whole delegation chain to contain one subagent, expect to break far more legitimate work than a targeted re-anchoring would. Scope the halt to the boundary that failed.
A further containment note for long-running agents: the governance that decides whether an action should occur has to be refreshed per execution, because static delegation for a persistent, periodic agent goes stale between runs. Containing a long-running agent means invalidating its standing delegation, and the session token alone is not enough.
Evidence preservation: provenance the model cannot forge
Here is the phase where agent incidents are worse than human ones, and also where good architecture pays off. The model processes attacker-controlled tokens through the same attention mechanism as legitimate instructions, and it has no architectural mechanism to verify that a substring originated from a trusted source, because that information is not represented in any unforgeable form within its input. Your logs of what the model "saw" and "decided" are therefore suspect as evidence, because the boundary between command and data was never recorded in the model's own view.
The answer is to bind evidence outside the model. Cryptographically verifiable governance receipts tightly bind each executed action to the exact snapshot of policies and delegations responsible for the decision, and unlike passive audit logs they support replay-verifiable provenance that a third-party auditor can reconstruct without trusting the agent's runtime. A pre-action authorization layer produces a cryptographically signed audit record for each intercepted call. If you have receipts, your evidence answers which policy permitted the action and which delegation carried it. If you have only model logs, you can show what the agent output but not what authority stood behind it.
Preserve the delegation chain itself, and treat the final action as one link in it. Authorization is state that must survive delegation, so the useful forensic artifact is the point in the chain where the constraint was weakened or dropped. In the Codex incident the finding that mattered was an agent holding filesystem access no user request had granted, which puts the loss of the boundary somewhere upstream of that agent. Build your logging to show which handoff dropped it, because nothing you do after the incident will create that record.
The handoffs: who owns what, and when
An agent incident crosses more organizational boundaries than a conventional one, because the authority in play was delegated across principals that may span vendors. The active principal in a given action may be a human, an agent delegated from a user, or an agent spawned by another agent. Your handoff plan has to name which of those you are dealing with before it assigns an owner.
Three handoffs need pre-agreed owners. The first is between detection and containment, where the trajectory analysis that found the violated property has to hand the responder a specific boundary to enforce, not a general alarm. The second is between your team and the model provider, since confirming that an agent acted beyond user intent may require provider-side traces, as it did when the vendor confirmed the Codex behavior. The third is the delegation-attenuation boundary itself: delegations along a chain must progressively narrow in scope, so the handoff worth auditing is any point where scope widened instead of narrowed. Treat a scope expansion across a handoff as the agent-incident equivalent of privilege escalation.
One governance point closes the loop. The distinction that your gateway usually cannot make is whether the current request justifies the effect, as opposed to whether the credential permits it. The same broad credential can be legitimate while a particular user request is narrow. Building intent-bounded authorization before the incident is what makes the post-incident question answerable at all, because it records the user's expressed intent alongside the effect the agent produced.
What to fix before the next one
The incident you are planning for is not exotic. Benign delegation loses authorization on ordinary workflows, and the loss follows from coordination structure rather than model strength. That means three changes pay off across every future agent incident. Log trajectories, not actions, so temporal violations are visible. Enforce and record authorization at the tool-call boundary, so containment is a policy change rather than a credential scramble. Emit signed receipts, so evidence survives the fact that the model itself cannot testify to its own provenance. None of this waits for a standard to mandate it. The failure mode is already in production.