Standard incident response assumes a compromise you can bound. A host was breached, an account was taken, a database was accessed, and the investigation establishes which records were reached. AI incidents resist that framing, because the question is not only what the attacker touched but what the model was told, what it retrieved and what it then produced for someone else. Unauthorized ai usage risks sit alongside genuine compromise in the same category, since both produce data exposure through a channel your existing playbook does not describe. This article sets out what an AI incident actually looks like, how to contain and scope one, and the logging that has to exist beforehand for the investigation to be possible at all. Our note on stopping corporate data leaks through enterprise AI monitoring covers the detection layer.

Key Takeaways

• AI incidents divide into four types: prompt injection reaching a privileged action, data exposure through the model, model or supply chain compromise, and unsanctioned usage on personal accounts.
• Containment is different because the affected component is a service rather than a host. Disabling the agent's credential and revoking its tool access is usually faster and safer than isolating infrastructure.
• Scoping depends entirely on logs captured before the incident. Without prompts, retrieved context and outputs, you cannot establish what was exposed and will have to assume the worst.

The Four Incident Types

The first is prompt injection reaching a privileged action. An agent processes content it did not author, that content contains instructions, and the agent's credentials execute them. Nothing is technically compromised: the system does exactly what it was built to do with input it cannot distinguish from a legitimate request. The severity depends entirely on what the credential could reach.

The second is data exposure through the model. Confidential information enters a prompt or a retrieval context and appears in an output delivered to someone not entitled to see it. Retrieval systems make this common, because the retrieval layer frequently does not enforce the same access controls as the source system it indexed.

The third is model or supply chain compromise. A model, a plugin, an extension or a library in the AI stack is altered or malicious, and the behaviour change is difficult to detect because model outputs vary naturally. This is the hardest type to identify and usually surfaces through a downstream effect rather than an alert.

The fourth is unsanctioned usage. Staff process confidential material through consumer AI services on personal accounts, and the exposure sits entirely outside your estate. These unauthorized ai usage risks are the most frequent by volume, and they are discovered through monitoring rather than through an alert, because nothing in your environment broke.

Reference material such as MITRE ATLAS catalogues the techniques behind the first three and is worth using to structure detection coverage before an incident rather than during one.

Detection: What Actually Signals an Incident

Detecting compromise and unauthorized ai usage risks requires different signals, and for agent incidents the reliable ones are behavioural. An agent invoking a tool it has never used before. A burst of activity well outside its baseline. Access to a record set outside its normal pattern. Each of these is simple to implement and catches the realistic failure modes without attempting to inspect model reasoning.

For data exposure, the signal usually comes from output monitoring rather than input. Scanning generated content for classified identifiers, customer references and credential patterns catches exposures that input filtering missed, and it is the only place where a retrieval-layer access control failure becomes visible.

For supply chain issues, integrity checks are the practical control. Model versions, plugin manifests and dependency hashes should be recorded at deployment and verified continuously, because a changed artefact is far easier to detect than a changed behaviour.

For unsanctioned usage, network and endpoint telemetry does most of the work. Traffic to consumer AI services from managed devices, and large paste operations into browser tabs on those domains, are both detectable and both give you a conversation to have rather than an incident to investigate.

None of these detections is exotic, and all four can be implemented on tooling most enterprises already own. The reason they are frequently absent is that AI systems are deployed by teams outside the security function, and nobody asked which signals would be needed.

Containment Without Breaking the Business

The first containment decision in an AI incident is usually not to isolate a host. The affected component is a service, and the fastest safe action is to disable the agent's identity and revoke its tool access, which stops the behaviour while leaving the surrounding infrastructure running.

That requires the identity to be separable, which is the design decision made months earlier. Agents sharing a credential cannot be contained individually, and an incident involving one becomes an outage of all of them. This is the clearest operational argument for the one-identity-per-agent rule.

Second, preserve the conversation state before anything is reset. Prompts, retrieved context, tool calls and outputs are the equivalent of memory in a conventional investigation, and many platforms discard or rotate them on restart. Capturing them first is the step most often skipped and most often regretted.

Third, decide whether to disable the feature or the whole service. Where a single tool integration is implicated, removing that tool from the agent's list is proportionate and preserves the rest of the capability. Blanket shutdowns of AI services during an incident generate business pressure that shortens the investigation, which is how scoping errors happen.

Scoping: The Hard Part

Scoping an AI incident means answering three questions. What did the model receive, what did it retrieve, and what did it output to whom. Each is answerable only from logs captured at the time, and each is unanswerable afterwards if those logs were not enabled.

The input question requires prompt logging with the identity of the requester attached. The retrieval question requires a record of which documents or records the system fetched for each request, which is separate from the source system's own audit log and frequently not enabled by default.

The output question is the one that determines notification obligations, and it is the hardest. You need the generated content, the recipient, and the time. Without it you cannot establish whether confidential information actually reached anyone, and a regulator asking what was disclosed will not accept an inability to answer as a reason not to notify.

Where logs are incomplete, scope conservatively and say so. An honest statement that the exposure could not be bounded, with the reason, is a defensible position. An optimistic estimate that later proves wrong is not, and it is considerably harder to correct once notifications have gone out.

This is why logging design belongs in the deployment checklist rather than in the response plan. Our note on why traditional DLP fails against generative AI risks covers why the conventional controls do not produce this evidence.

Recovery and What Changes Afterwards

Recovery from an AI incident, whether it began as a compromise or as unauthorized ai usage risks materialising, rarely means restoring from backup. It means changing the conditions that allowed the behaviour: narrowing the agent's permissions, removing a tool from its available list, adding an approval gate on the action that was triggered, or fixing the retrieval layer's access control so it matches the source system.

Where a prompt injection succeeded, the fix is almost never a better system prompt. Instruction-level defences are advisory and the same channel that carries them carries the attack. The durable fixes are permission scoping, an enumerated tool list and human approval on consequential actions.

Where data exposure occurred through retrieval, the fix is in the indexing layer. Retrieval systems that index everything and filter at query time will eventually leak, because the filter is a single point of failure. Indexing per access boundary is slower to build and does not have that property.

Where unsanctioned usage was the cause, the fix is provision rather than prohibition. Staff used a consumer service because it helped and nothing sanctioned did. Closing the gap in capability closes the exposure far more reliably than a policy reminder.

Every AI incident should also update the deployment checklist, so that the next agent ships with the control that would have prevented this one. Our note on full visibility into workforce AI usage covers the monitoring foundation.

Preparing Before You Need To

Add an AI annex to your existing incident response plan rather than writing a separate one. The annex needs four things: the four incident types with their detection signals, the containment actions available for each and who may take them, the log sources required for scoping and where they live, and the notification decision path when exposure cannot be bounded.

Test it with a tabletop exercise using a realistic scenario, most usefully a prompt injection that caused an agent to send an external email containing customer information. That scenario exercises detection, containment, scoping and notification in one pass, and it reliably reveals which logs do not exist.

Confirm that responders have the access they need in advance. AI platform logs are frequently held by the team that built the system rather than by security operations, and an incident is a poor time to discover that the responder cannot read the evidence.

Align the response process with the standard you already use, such as NIST SP 800-61, so that the AI annex slots into an established process rather than creating a parallel one that only a few people know.

If you want help building or testing the annex against your own AI deployments, our incident response team can run the exercise with you. You can also see how SkyAlchemX applies AI within a governed perimeter with the logging these investigations require.