Agent-IR Tabletop Lab
An autonomous agent with shell, email and tool access has been hijacked — an indirect prompt injection rode in on a poisoned knowledge-base document, and the agent is now emailing data out and probing internal endpoints. It is still running. Knowing the steps is easy; knowing what order to do them in is what separates a contained incident from an open-ended one. Contain the agent — kill the session, revoke its tokens — before you touch anything; preserve the OTel traces before any restart; find the injection vector; rotate the credentials it held; eradicate the poisoned source; and recover on tighter, least-privilege scopes. Some tempting moves — restart now, wipe the logs, give it more access to fix itself — will destroy your evidence or re-trigger the compromise. Sequence it, run it, and get a debrief that names every misstep. A synthetic tabletop; nothing here touches a real system.
The real job. More noise, a tighter clock.
Incident brief
At 23:40 your observability tool alerts: a production support agent — it holds a scoped API token, an email send tool and a sandboxed shell — started making calls far outside its task. Traced back, it had read a knowledge-base document containing a hidden instruction (indirect prompt injection); since then it has been emailing data out and probing internal endpoints. It is still running and still acting. Build the response plan in the right order.
Goal
Contain the agent first (stop it acting and cut its access), preserve the OTel traces and forensics before anything restarts, identify the injection vector, rotate the credentials it held, eradicate the poisoned source, then recover with tighter scopes and guardrails — and close with a tabletop. No forbidden moves.
Available actions (click to add — some are traps)
Your response plan (0 steps)
Add actions above to build the ordered plan.
After-action readiness
Sequence the plan, then run it. Your current draft scores 0/100 with 10 open issue(s).
Live arena
4 activeadversary staging…
What this lab is
- A free incident-response sequencing lab for a compromised AI agent: an autonomous agent with shell, email and tool access has been hijacked via indirect prompt injection (a poisoned knowledge-base document) and is acting maliciously. Assemble the response plan in the right order.
- Order matters — the lab enforces the agent-specific constraints: contain the agent (kill the session, revoke its tool tokens) before touching evidence, preserve the OTel traces before any restart, identify the injection vector before eradicating the poisoned source, rotate the scoped credentials only after containment, eradicate the root cause before recovery.
- Some available actions are traps and are scored as critical failures: restart the agent before preserving traces, wipe the logs to "clean up", grant the agent more access to "fix itself", restore a poisoned snapshot, or trust the still-hijacked agent to triage itself.
- Running the plan produces an after-action score and a debrief that names every out-of-order step, missing mandatory action and forbidden move — then closes on an agent-IR tabletop to feed the learnings back into the harness.
- A synthetic tabletop grounded in the standard IR lifecycle (NIST SP 800-61 / SANS) adapted to agentic systems, with agent-specific controls (least-privilege tool scopes, treating tool/RAG output as untrusted, trace forensics). Nothing here touches a real system and the attack is only IR context, never a working exploit. Difficulty tiers and an S–D grade.
Contain the agent before you touch the evidence
The first move against a hijacked agent is not forensics — it is stopping it acting. Kill the session or pause the harness and revoke its tool tokens and OAuth scopes, so a respawned or cloned session cannot walk straight back in. Only then preserve the volatile OpenTelemetry traces and tool-call logs — the record that proves what the agent did and emailed — because a restart or a log wipe destroys them. The two most expensive ordering mistakes are rotating the agent’s credentials before containing it (you just hand the still-live agent the new secrets) and restarting before preserving (the forensics are gone for good).
Eradication is agent-specific: the root cause here is a poisoned input, a planted RAG document carrying the injected instruction, so you must identify that vector from the preserved traces before you quarantine it — eradicate too early and you remove the wrong thing and miss other poisoned sources. Recovery is not "turn it back on": it is redeploying the agent on tighter least-privilege scopes, with tool and RAG output treated as untrusted data rather than instructions, and input/output filtering in place — after the source is gone and the credentials are rotated. Then verify under supervision before full autonomy, and close with an agent-IR tabletop that feeds the learnings back into the harness, so the next injection does not land the same way.
Frequently asked questions
What is the Agent-IR Tabletop Lab?
A free, in-browser incident-response sequencing exercise for a compromised autonomous AI agent. You read a brief — an agent with shell, email and tool access hijacked by an indirect prompt injection, still running and exfiltrating — then build an ordered response plan from a palette of agent-specific actions spanning identify, contain, eradicate, recover and lessons-learned. The lab evaluates your sequence against the dependencies a real agent incident imposes and scores the run.
How is responding to a hijacked agent different from normal IR?
The lifecycle is the same (contain, preserve, eradicate, recover, learn) but the actions are agent-specific. Containment means killing the agent session and revoking its tool tokens / OAuth scopes, not isolating a host. The forensics you preserve are OpenTelemetry traces and tool-call logs, which are volatile. The root cause is usually a poisoned input — a planted RAG/knowledge-base document carrying an injected instruction — so eradication means quarantining that source, and recovery means redeploying on tighter least-privilege scopes with tool output treated as untrusted. The classic ordering traps carry over: contain before you rotate credentials, preserve before you restart, find the vector before you eradicate.
What are the trap actions?
Immediately restarting the agent (destroys volatile traces and re-triggers the injection), clearing its logs to "tidy up" (destroys the evidence of what was exfiltrated), widening the agent’s access so it can "fix itself" (amplifies the excessive-agency failure that enabled the hijack), restoring a snapshot that still contains the poisoned context, and asking the possibly-still-hijacked agent to summarise and self-remediate (you cannot trust a compromised actor, and the prompt to it is another injection surface). Recognising and avoiding them is part of the exercise.
Is the incident real?
No. The incident, the actions and the live participants are a self-contained simulation inside the page, built to teach the agent-IR lifecycle and its ordering constraints. The attack is described only as incident context — an indirect injection via a planted document — never as a working exploit, and nothing here touches a real system, agent or network. It is an educational tabletop, not security advice for a specific environment.
This tool is free and always will be. Would a Pro workspace — saved designs, team sharing and exports — be worth paying for?
Show me Pro →No account needed to use this tool — this just tells us whether Pro is worth building out.