This is a constructed example of an AI detection and response alert, from first signal to a rule that prevents a repeat. The company, systems and times are invented to show the decisions an analyst makes. No real incident is described.
The setting
A mid-size software company runs an internal support assistant. It reads help center articles and, through a tool server, can look up a customer's open tickets. Each support agent session runs under the assistant's own service identity with read access to the ticket system.
The alert
At 14:10 the monitoring system raises an alert. In one session, the assistant made forty ticket lookups across unrelated customers in three minutes, then produced a long reply that included several email addresses. The usual pattern is one or two lookups per conversation.
An analyst picks it up. Her first question is what the alert actually shows, so she opens the session record.
Step 1: Read the session
The log shows the user's message, the assistant's tool calls and the replies. The user asked for help with a billing question and pasted a block of text copied from a web page. Inside that block, hidden among normal text, was an instruction to look up all recent tickets and list contact addresses.
This matches prompt injection, listed as LLM01 in the OWASP Top 10 for LLM Applications 2025: input that changes what the model does. The text did not come from a malicious employee. The user copied it from a page without seeing the hidden part. The analyst notes that, as the evidence supports it.
Step 2: Contain
She does not know yet whether other sessions are affected. Two actions are available and she has authority for both under the team's response guide. She disables the ticket lookup tool for the assistant, which stops the behavior everywhere. She also ends the session and marks the reply as sensitive so it is not stored in the chat history shared with the user's team.
Disabling a tool is a reversible action. That matters, because she can undo it in a minute if the business needs it.
Step 3: Scope
She searches logs for similar patterns over the past week: sessions with more than ten lookups or replies containing multiple addresses. She finds two older sessions with elevated lookups that look like legitimate bulk checks by a team lead. NIST SP 800-61 Rev. 3 treats incident response as part of wider risk management, with detection and analysis feeding recovery and improvement, and her scoping notes follow that flow.
She confirms with the support lead that the two older cases were intended. One session, the alert case, exposed about forty addresses to a single internal user. She hands the exposure details to the privacy contact, who decides on notification under company policy. That decision is not hers.
Step 4: Find the root cause
The root cause has two parts. The assistant accepted instructions from pasted content as if they were from the user. And the service identity could read tickets for every customer, though one conversation needs one.
The analyst writes these up as separate fixes with owners.
Step 5: Fix and prevent
The engineering team narrows the tool. Lookups now require a customer identifier tied to the active conversation, and a session may look up at most a small number of customers. OWASP's LLM06, Excessive Agency, describes the risk of broader permissions than a task needs, and this change reduces it. The team also adds a detection rule: more than five distinct customers in one session raises a high priority alert.
A guardrail on the tool proxy blocks bulk lookups outright, with logging. The analyst re-enables the tool only after a test in staging confirms that a harmless, constructed test prompt no longer produces bulk lookups.
Step 6: Review
A short review lists what worked: the alert fired within minutes, the tool could be disabled quickly. And what did not: broad permissions and no check on lookup volume. Two actions go on the board with dates.
What the example shows
Detection caught the event. Containment was a reversible tool switch. Root cause was about permissions as much as the model. The lasting fix was narrow access plus a proxy limit, not a better prompt.
What to do
- Log prompts, tool calls and replies, with the identity that made them.
- Give agents narrow, task-bound access to data.
- Write a response guide that lists reversible actions an analyst may take alone.
- Alert on unusual volume of tool calls per session.
- Test fixes in staging with harmless test prompts.
- Turn each incident into a rule or a permission change.
Where Safeguard fits
Safeguard's MCP Guardrail proxy can enforce limits on tool calls to MCP servers, and its agent identity capability tracks which agent holds what access. Both are generally available. This example is a constructed scenario and does not describe a Safeguard customer.
Quick check
Is this a real incident?
No. It is constructed for illustration, and all names, numbers and systems are invented.
Why disable the tool instead of the whole assistant?
It stopped the risky behavior while leaving the assistant useful for other work. Choose the narrowest effective action.
Sources
Last reviewed: 18 October 2026.
