The first hour when an AI agent misbehaves.

Minutes zero to five: call it an incident.

Agents rarely fail loudly. The first signal is usually small: a tool call nobody expected, data leaving for an unfamiliar destination, a sudden jump in model spend, an approval request with no clear reason, or a person saying the assistant told them something odd. Treat any agent acting outside its stated purpose as a possible incident, not a bug ticket, until you know otherwise.

Name an incident lead, open one channel and start a written timeline at once. Record what was seen, when, and which agent, model and tools were involved. Use the same clock you will report against later, because reporting deadlines start when you become aware, not when you finish investigating.

• The agent, its owner and its stated purpose
• The first and latest odd action, with times
• The tools, data and models it can reach
• Who noticed, and how

Contain the agent, not the whole company.

The instinct is to switch everything off. Start smaller: the narrowest control that stops the harm keeps the rest of the business running and keeps the evidence intact. Widen the stop only if the behaviour continues or spreads to other agents.

Prefer actions you can undo and that leave a record. Suspending an agent is better than deleting it; blocking one tool is better than revoking every credential the team uses. If several agents share one credential, assume they are all affected until you know which one acted, and write down who decided each step and why.

• One agent misbehaving: suspend or quarantine that agent
• One tool abused: block that tool for that agent
• A credential exposed: revoke it and issue a new one
• A model or provider involved: switch that model off
• Spreading between agents: widen to a fleet-wide stop

Keep the evidence before it changes.

Agent incidents erase their own traces. Context windows roll over, memory is rewritten, tool descriptions change on the server that serves them, and logs age out. Capture what you can before you change anything else, and record who captured each item and when.

Keep originals, not summaries. A screenshot of a chat is weaker than the exact prompt, the exact reply and the tool call with its arguments. Hash files as you collect them, so you can show later that nothing changed, and store them where the agent and its credentials cannot reach.

• Prompts, replies and tool calls, with arguments
• The system prompt and configuration version that ran
• Tool and MCP server descriptions, as they were served
• Memory, vector store or knowledge-base snapshots
• The identities and credentials the agent used
• Gateway, proxy and egress logs for the window

Cut the paths it can use.

Containment stops the agent; this step stops the attack reaching it again. Many agent incidents arrive through content the agent was asked to read: an email, a web page, a document, a tool description or another agent’s message. Find that source and quarantine it, or the next run repeats the incident.

Then narrow what the agent can reach. Pause the schedules and webhooks that wake it, block outbound destinations it does not need, and remove tools it was never meant to use. If its memory or knowledge base may be poisoned, take it out of retrieval until someone has reviewed it.

• Quarantine the poisoned email, page or document
• Pause schedules and webhooks that wake the agent
• Block outbound destinations it does not need
• Pull suspect memory and documents from retrieval

Work out what it did, and to whom.

With the agent contained, build the scope from records, not from memory. For the incident window, list each tool call and what it touched: which records were read, which were changed, what left the organisation and where it went. Note whose personal data was involved, because that decides who you must tell.

Then check whether other agents consumed its output. In multi-agent systems one poisoned instruction can travel from one agent’s answer into the next agent’s input, so widen the window and the list of agents until the trail stops. Naming the risk against the OWASP Top 10 for Agentic Applications now, for example ASI01 or ASI06, helps later when you choose the fix.

• Records read, changed or deleted
• Data that left, and where it went
• People whose personal data was involved
• Agents that consumed its output

Tell the right people, in the right order.

Inside the organisation, tell the system owner, the security lead and the people who own the data involved, then legal and privacy. Agree one person who speaks to customers and regulators, and keep a note of each decision and who made it.

Reporting clocks are short, and they start when you become aware. In India, CERT-In’s directions ask for cyber incidents to be reported within six hours of noticing them. Under the GDPR, a personal data breach goes to the supervisory authority without undue delay and, where feasible, within seventy-two hours. India’s DPDP Rules add a detailed report to the Data Protection Board within seventy-two hours once the core obligations apply on 13 May 2027. Check with counsel which of these apply to you, and to which entity.

Restore with the fix proven, not assumed.

An agent that worked yesterday is not safe to bring back because the obvious cause was removed. Write the fix, then prove it: replay the exact attack that worked, through the same controls, and keep the result. If you cannot reproduce the original attack, say so in the record rather than calling it fixed.

Bring the agent back in stages. Start in a monitor-only mode or a lower trust level, keep high-impact actions behind human approval for a while, and compare its behaviour with the baseline it had before the incident. Widen its access only when the evidence says it is behaving as intended.

• Replay the attack that worked, through the same controls
• Return in monitor-only mode first
• Keep high-impact actions behind approval
• Compare behaviour with the pre-incident baseline

After the hour: learn, and keep the record.

Within days, hold a blameless review: what happened, why the agent could do it, what stopped it and what would have stopped it sooner. Name the cause against the OWASP agentic risk it belongs to, and turn the attack into a regression test that runs before each release. Share what you learned with the teams who build agents, not only with security.

Close the incident only on evidence: the passing re-test, the changed configuration and the decisions made, with who made them. Keep the timeline and the evidence together, so an auditor or a regulator can follow it without you in the room.

• The cause, named as an OWASP agentic risk
• A regression test for the attack
• An owner and a date for each follow-up
• Evidence and timeline kept together

Before the next one: what to have ready.

The first hour goes faster when the basics exist before it starts. Keep an inventory of your agents with an owner for each, and give each agent its own credential, so you can tell which one acted and stop just that one without touching the others.

Decide containment limits in advance and write them into the controls, not into a wiki page. Rehearse the playbook on a copy of the agent, not on production, and check that the people who must approve a stop can be reached at night and at weekends. Know which scopes your stop controls have, from one agent to the whole fleet, before you have to choose.

• An agent inventory with owners
• One credential per agent
• Containment limits set in the controls
• A rehearsed playbook and reachable approvers

Where ColossalX fits in the first hour.

ColossalX is an AI security and governance platform, delivered as SaaS. In an agent incident it helps in specific places: an agent inventory with owners and a label saying how each agent was found, a credential per agent, and containment that ranges from suspending or quarantining one agent to the ColossalX Kill Switch at 4 scopes, each step kept with who acted and why.

For the scope step, session recordings replay an agent’s requests one by one. Incident playbooks are real workflows that you can rehearse safely before you need them. A fix is proven by re-sending the same probes that got through, and the evidence is graded and timestamped. ColossalX does not replace your SIEM or your incident process; it feeds your SIEM with alerts and keeps its own record.