An AI agent just did something it wasn't supposed to do: sent an email it shouldn't have, modified a record outside its intended scope, called a tool with parameters nobody approved. Before deciding how severe this is or how to respond, you need a clear, factual picture of what actually happened, and that picture doesn't come from guessing based on how alarming the action looks. It comes from asking a specific set of questions in a specific order, each grounded in the audit trail and session record rather than in assumption. This guide groups those questions into five clusters: what happened, why it happened, what it affected, what should have stopped it, and what needs to change. Working through them in order keeps an investigation from jumping to conclusions before the facts are actually in.
What actually happened
Start with the plain facts before interpreting anything. What was the specific action, described precisely rather than in the language of the alarm that flagged it? Was it completed, or only attempted and blocked partway through? What identity, session, and specific request initiated it, and does that identity map to a real user, a service account, or another automated process acting through the agent? Was this a single occurrence, or does the same pattern show up elsewhere in the logs? Answering these first, using the audit trail rather than a verbal account of what someone thinks happened, keeps the rest of the investigation anchored to fact.
Why did it happen
Once the facts are established, the question shifts to mechanism. Was this a prompt injection, where content the agent processed carried an instruction it shouldn't have followed? Was it a permission gap, where the agent had legitimate access to a tool or data source that it should never have been granted in the first place? Was it a misinterpreted instruction, where a legitimate user request got translated into an action broader than intended? Or was it a tool bug, where the agent's request was reasonable but the tool it called executed something different from what was requested? Each of these points to a different fix, so conflating them produces a fix that addresses the wrong layer.
What was the actual impact
Impact needs to be assessed on what actually happened, not on what could theoretically have happened in a worse version of the same scenario. What specific data, system, or person was affected, and can that be stated precisely rather than broadly? Is the effect reversible, a record that can be restored or a message that can be retracted, or is it permanent, information that's already been seen by someone or an action that already took real-world effect? Did the action touch anything covered by a regulatory or contractual obligation, which would change who else needs to be looped in? Getting this specific matters because it determines the actual response, not a response sized to worst-case anxiety.
What was supposed to stop this
Every unauthorized action passed through some control, or slipped past the absence of one. Which control was supposed to catch this: a permission scope, an approval gate, an output check, a rate limit? If a control existed, why didn't it fire? Was it misconfigured, was it bypassed through a path nobody anticipated, or did it fire correctly but too late to prevent the outcome? If no control existed at all, is that because the risk wasn't anticipated, or because it was accepted as tolerable at the time and that assessment now looks wrong? This question is often the most uncomfortable one to answer honestly, and it's usually the most useful.
What needs to change
The investigation closes by turning findings into action. Does the agent's permission scope need narrowing, removing an access grant it never should have had? Does this class of action need an approval requirement it didn't have before? Does policy need to state explicitly what's off-limits, where it previously left a gap unaddressed? Is there a monitoring signal that should have caught this sooner, and if so, what would it need to look like? Each answer here should map to a specific, assignable change, not a general intention to "be more careful" that nobody owns going forward.
Where TELEON fits
Answering the "what actually happened" and "what should have stopped it" clusters depends heavily on having a reliable record to check against, and TELEON's audit trail, running through the gateway or supported middleware, gives investigators the identity, decision, and tool-call detail needed to answer those questions with evidence instead of guesswork. Its runtime policy enforcement at the tool-call boundary is also where several of the "what needs to change" answers, tighter permission scope, a new approval requirement, get implemented once decided.
Determining why the action happened, judging its actual impact, and deciding what specifically needs to change still require direct investigation and judgment from the team involved. TELEON's record supports that work; it doesn't draw the conclusions on its own.
A short checklist
- Establish the specific action, identity, and completion status from the record.
- Identify the mechanism: injection, permission gap, misinterpretation, or tool bug.
- Assess actual impact and reversibility, not worst-case impact.
- Determine which control should have caught this and why it didn't.
- Turn findings into specific, owned changes to policy, scope, or monitoring.
Resist the temptation to answer all of these at once from a single alarming log line. The most common mistake in this kind of investigation isn't missing a question, it's answering "why" before "what" is actually nailed down, which tends to produce a fix aimed at the wrong mechanism. Work through the clusters in order, and let each answer come from evidence rather than from how the incident initially looked.