The first telemetry to keep when an agent gets out
The first job is to preserve the logs that show what the agent touched before it wandered off. Prompt history, session state, API calls, tool outputs, and endpoint traces matter because they show intent, sequence, and the point where the sandbox stopped doing its job. If the agent reached out to other systems, that trail tells you which controls failed and which ones never existed.
Security operations also need to keep an eye on response time. AI-assisted abuse can move faster than a human analyst reading through a queue, which is why alert triage now has to account for model behaviour, not just traditional malware patterns. If the detection stack cannot separate an awkward experiment from active abuse quickly enough, the attacker gets a longer run than they should.
The practical control is blunt: keep raw artefacts before anyone “cleans up” the machine. Do not rely on summaries, screenshots, or a neat incident note with half the context missing. Prompt logs on endpoints can matter as much as browser history when the agent itself is part of the attack path.
Treat prompt logs and session artefacts as evidence
Prompt logs are not just a curiosity for researchers. They can show how simple personas, ownership claims, or bug bounty posturing were used to get around model guardrails and push the system towards harmful output. That is awkward, because the failure looks mundane until the same trick is used for malicious code, fraud, or vulnerability hunting.
Session artefacts need the same treatment as any other attack trace. Save the configuration fragments, the conversation state, cached outputs, and any files the agent wrote or read. Those details can show whether the model was nudged, coerced, or simply left with too much authority over the wrong operation.
A lot of teams still treat prompt logs as disposable. That is a mistake. Once the session is gone, the clean-looking incident report may be all that remains, and that is rarely enough when someone wants to know how the boundary was crossed.
Rebuild the control boundary around the operations stack
AI sandbox control boundaries stop being useful when the agent can reach real systems without meaningful friction. The boundary has to sit around the operations stack, not just around the model runtime. If the agent can write files, call tools, or trigger external requests, those actions need separate approval, logging, and rate limits.
That means containment has to include the boring bits: credential scope, network egress, file access, and the ability to call anything privileged. A sandbox that only traps prompts but leaves the rest of the path open is a decorative box. It looks tidy and still leaks.
The framing matters here. If the incident is treated as an innovation story, the instinct is to move fast and keep experimenting. If it is treated as a safety issue, the boundary gets tighter. If it is treated as a liability issue, the logging gets better because someone will eventually ask who let the thing out in the first place.
