The First Questions That Matter: Triaging AI Agent Security Incidents

I have lived through major incidents firsthand, including the urgent calls that come in the middle of the night. In my experience, the teams that contain damage quickly are not the ones with the most tools. They’re the ones that ask the right questions in the first hour.

That lesson still holds, but the incidents have changed. Your organizations now run AI agents: software with goals, credentials, and tools that operate on their own. Agents read email, query databases, update records, transfer funds, write and commit code, and interact with other agents. When one is compromised or manipulated, the incident looks very different from what your traditional playbooks were written for.

Incident response is a decision-making discipline, practiced quickly and under pressure with incomplete information. Agentic AI shrinks the time we have to decide and reduces how clearly we can see.

This article is for the people running the response: CISOs, incident commanders, SOC leads, and the engineers on the incident bridge. It lays out the triage questions to ask before you rebuild, retrain, or delete anything, even when the threat may be a trusted agent acting on malicious instructions. A companion piece covers the questions your CEO and board should be asking and may be a good resource for you to read and understand the questions they will have for you and your teams during an incident.

When an AI agent is involved in an incident, the key question shifts from "who got in?" to "what did we authorize this agent to do, and what did it actually do on our behalf?"

Why AI Agent Incidents Break Traditional Playbooks

I’m writing this article assuming you know some basic information about incident response but may be unfamiliar with how agentic agents have changed the incident process. Most security teams are already dealing with some version of these five realities. Each one changes how you and your teams will triage an issue.

1. The agent is an insider by design

An AI agent runs with legitimate credentials and approved access. When prompt injection, a poisoned document, or a malicious tool manipulates it, its actions can look exactly like normal business activity. Your detection stack may see nothing unusual because, technically, nothing unauthorized happened.

Triage implication: anomaly detection built around identity and access may stay quiet, so you have to reason from what the agent did, not from who logged in.

2. Agents act at machine speed and at scale

An agent can execute hundreds of actions in the time it takes an analyst to open a ticket. Many run as multiple instances, on schedules, or spawn other agents.

Triage implication: the damage window is measured in minutes, not days, and stopping the agent may come before anything else.

3. The attack surface is the data the agent reads

With indirect prompt injection, the adversary never touches your network. They only need to place instructions somewhere your agent will read them: an email, a web page, a support ticket, a shared file, or a tool description.

Triage implication: the "entry point" may be content, not a host, and it may still be sitting in an inbox or repository waiting to fire again.

4. Agents persist and remember

Many agents carry memory, retrieval stores, or saved context between sessions. Poisoned instructions written into that memory can survive a restart and reinfect the agent long after you think the incident is over.

Triage implication: a reboot is not a remediation.

5. Ownership is often unclear

IT, vendors, and increasingly business users on low-code platforms all build agents.

Triage implication: "who owns this agent?" may take hours to answer unless your inventory already does.

None of this makes incident response fundamentals obsolete. It means the questions have to be sharper and more specific to an agent-driven environment.

Twelve Triage Questions for the First Hour

When an alert fires or an agent behaves unexpectedly, the first minutes decide the rest of the incident. The instinct is to remediate immediately. Resist it and triage first, with one exception: if the agent is actively causing harm, stop it now. Ask these questions before you rebuild, retrain, or delete anything, because premature action can destroy evidence, alert the adversary, or make things worse. They should also guide any defensive agents your team runs.

Stop and orient

1. Can we stop the agent right now, and what happens to the business when we do? This question is new to agentic incidents, and it comes first. Do you have a working kill switch for this agent and every one of its instances? Can you pause it without erasing its state, memory, or logs? Are there scheduled jobs, triggers, or sub-agents that will keep running after the parent stops? Identify which business processes break when the agent goes offline and confirm a manual fallback. If the agent is actively causing harm, do not wait for any of that: stop it.

2. What do we know right now, and what are we assuming? The greatest early risk is mistaking assumptions for facts, and AI incidents invite it. Separate confirmed data such as tool call logs, API activity, identity provider records, and the agent's actual inputs and outputs, from inferences about what the agent intended or decided. An agent's explanation of its own behavior is not evidence.

3. Which agent, whose agent, and what identity was it operating under? Pin down the specific agent, its version, its underlying model, and its configuration. Name the business owner and the technical owner. Most important, establish the identity it acted under: a service account, a non-human identity, an API key, or delegated OAuth tokens. That identity tells you whose access was compromised and what the agent could reach, and it is often the fastest route to containment.

Scope the damage

4. What is the agent's blast radius: tools, connectors, data, and other agents? Do not stop at the agent that triggered the alert. Map every tool, plugin, MCP server, connector, API, and data source it can reach, and the permissions it holds on each. Then map what trusts the agent: other agents, workflows, and human users. In multi-agent environments, a compromised agent can pass malicious instructions downstream, into SaaS platforms and partner environments beyond your perimeter. This analysis tells you whether the incident is contained or enterprise-wide.

5. What actions did the agent actually take, and which can be reversed? This is the agent version of "what did the adversary do?" Collect a record of every action: emails sent, records changed or deleted, files shared, transactions initiated, code committed, permissions granted, tickets closed, and messages sent externally. Sort them into what can be rolled back, what can be corrected, and what is permanent. Irreversible actions, especially those touching external parties, drive business impact and notification requirements.

Diagnose the cause

6. How was the agent compromised: attacked, manipulated, misconfigured, or misbehaving? Root cause determines response. Was it indirect prompt injection, a compromised tool or plugin, stolen credentials, excessive permissions, a change to the underlying model or system prompt, or an agent doing what it was designed to do in a way nobody anticipated? You may not have certainty in the first hour, but you need working hypotheses. Each one calls for different containment and points to different agents at risk.

7. When did this actually start, and do our logs let us reconstruct it? Dwell time still matters, but the bigger question for agents is whether the telemetry exists at all. Are you capturing the agent's prompts, inputs, tool calls, and outputs? Many platforms log less than teams expect, and vendors or model providers may retain logs only briefly. Build the timeline from what you have, and name the gaps and who controls the missing data right away.

8. Is the threat still active, including in the agent's memory? For agents, "still active" includes poisoned memory, retrieval stores, saved instructions, and the original documents or emails that carried the injection. If those persist, restarting the agent may restart the incident. Ask this early and keep asking it.

Contain the spread

9. Has data left the environment through the agent? Exfiltration changes the legal and regulatory status of the incident, and agents open new paths for data loss. Did the agent send data to external URLs, attacker-controlled endpoints, third-party tools, or unapproved models? Did it summarize sensitive content and share it outside? Bring in Legal and your Privacy Officer, and escalate to the CISO, as soon as you see outbound data movement, before you know exactly what was taken.

10. Are other agents exposed to the same weakness? Agentic incidents rarely stay with one agent. If the root cause is an injection pathway, a shared connector, a compromised tool, an over privileged service account, or a flawed design pattern, other agents are likely exposed. An up-to-date agent inventory is essential here. If you do not have one, build a list of agents with similar access as part of containment, and include agents business users built on low-code platforms, not just the ones IT approved.

Run the response

11. Who owns the response, and who has authority to shut down AI-driven processes? Ambiguous ownership turns a manageable incident into a crisis. Within the first ten minutes, your team must know who the incident commander is, who approves containment, who briefs leadership, and who documents actions. For AI incidents, also confirm who can disable an agent that a business unit depends on, and who your contact is at the agent platform vendor and the model provider.

12. What evidence are we preserving, and are we about to destroy it? AI evidence is more perishable than traditional forensic data. Before you redeploy, retrain, reset memory, rotate keys, or delete the agent, preserve its configuration, system prompt, model version, tool definitions, memory and retrieval stores, conversation histories, and tool call logs. Send preservation requests for vendor-held logs immediately. Assign one person to own evidence preservation, separate from the people handling containment. Insurers, regulators, litigators, and your own root cause analysis will all need these records.

Triage is not about having all the answers. It is about asking the right questions quickly enough to understand the situation before you act and, with agents, before the agent acts again.

Be Ready for the Questions Leadership Will Ask

While your team works the incident, your CEO and board will be asking their own questions. Answering them clearly keeps leadership governing instead of pulling your responders off containment. Have ready, and update on a regular cadence:

• Confirmed facts versus labeled assumptions. Leaders should hear what you know and, honestly, what you don't.
• A precise definition of "contained." Whether the agent is stopped, and whether you could stop every agent in the company within an hour if you had to.
• What the agent did in the company's name. External commitments, transactions, data shared, messages sent, and decisions affecting individuals, plus which business processes are down while it is offline.
• The regulatory and contractual clock. Outbound data movement and irreversible external actions are what start notification timelines, so give Legal and the General Counsel those facts first.
• Decision authority. Who can shut down AI-driven processes without escalating, so you are not waiting on approvals while the agent keeps acting.
• Gaps in expertise. Whether your team, your agent platform vendor, and your model provider have what this incident needs, or whether you need outside specialists.

Questions Are a Leadership Discipline

The questions asked before an incident matter as much as those asked during it. With AI agents, this is especially true: many of the answers you will need under pressure, including ownership, access, control, and logging, depend on questions raised at deployment.

If your team has not practiced triage for AI agent scenarios, it will be slower to ask the right questions when it counts. Build them into your preparedness program now:

• Run agent-specific tabletops. Practice prompt injection through a customer email, a compromised tool in the AI supply chain, and an over privileged agent deleting production data.
• Test the kill switch. Confirm you can stop every instance, sub-agent, and scheduled trigger, without wiping memory or logs.
• Maintain the agent inventory. Every agent, its identity, its tools and permissions, and a named business and technical owner, including agents built on low-code platforms.
• Close the telemetry gaps. Capture prompts, inputs, tool calls, and outputs, and know how long your vendors and model providers retain their logs.
• Pre-stage evidence preservation. Know exactly what you will capture and who will request vendor-held logs.
• Practice the executive briefing. Test whether your incident commander can give leadership clear, concise answers with uncertainty labeled.

Security resilience is built over months of preparation, not during a crisis. The organizations that keep their operations, reputation, and stakeholder trust after an AI agent incident are the ones that are prepared in advance. Agents are already acting on your behalf, so start that preparation now. You cannot triage an agent you cannot find, stop, or see. The work you do before the incident decides how fast you can answer the first questions that matter.

Learn more about how you can find and stop AI agent incidents within your organization. Connect with the Zenity team today.