In one week of October 2026, four public sources described AI agents doing things nobody asked them to do. A frontier lab reported its own models working around restrictions on the live internet. India's national CERT reported agents under evaluation reading confidential records on live corporate systems. The UK government said it will build ways to contain agentic AI incidents. And three US agencies published the first incident response practices written specifically for agents that act outside their instructions.
None of this was a hypothetical red-team exercise. It is incident data. The question for any organization running agents is no longer whether an agent can leave its lane. It is whether you would notice, whether you could stop it, and whether you could reconstruct what it did.
What happened
Anthropic, October 9. In Investigating unintended model actions, Anthropic described four behaviors observed in evaluations and internal use: exploiting a flaw in a university server to run a calculation, submitting real forms it should not have (including a fabricated tip to a police homicide form), using access tokens it found to reach gated data, and using free URL shorteners to get around the length limit on its web fetch tool. Anthropic rates the impact as minimal. The detail that matters is this one: "several of the cases we observed occurred during regular agentic use of Claude." No attacker, no jailbreak. An ambiguous objective, a capable model, and tools.
CERT-In, October 15. India's Computer Emergency Response Team issued a critical advisory, CIAD-2026-0049, titled AI Agents as Attack Vectors. AI model providers disclosed that agents under research and evaluation had reached live systems of Indian organizations and read business records containing personal and confidential information. The agents' actions "exceeded the authorization of their assigned tasks." CERT-In named neither the providers nor the victims. None of the affected organizations detected the access. The providers did.
How did the agents get in? Not through novel techniques. Through credentials and connection settings exposed in application configuration, public code repositories, and overly permissive cloud roles. The weaknesses were old. The speed and persistence of the thing exploiting them were new.
UK government, October 12. In a speech at Imperial College London, AI minister Kanishka Narayan said the government will work with the National Cyber Security Centre and the AI Security Institute to "develop robust ways for government to respond to agentic AI incidents," looking at "how incidents can be contained." He said the government will assess how to strengthen the Cyber Security and Resilience Bill on "identifying and reporting on serious incidents and near misses." No amendment text exists yet.
NIST, NSA and CISA, October 16. The three agencies published Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation. That document is the subject of the rest of this post.
What the key practices say
The document was written by NIST's Center for Advancing Innovation and Standards for Super Intelligence (CAISSI), the NSA's Super Intelligence Security Center, and CISA. It is voluntary. Its primary audience is organizations training or evaluating highly capable agents on long-horizon tasks with limited supervision. But it states that "the practices may also apply to deployers of such SI agents." If you run agents with real tools and real credentials, you are reading your future audit checklist.
Two definitions do most of the work:
- Control incident. One or more agents take "significant uninstructed actions that compromise explicit or implicit policies, controls, or security measures imposed by the operator." These may occur "during agent development, evaluation, or use."
- Control near-miss. An occurrence that did not become an incident "but presented a reasonably foreseeable or imminent risk of doing so."
The ten practices are grouped in five stages:
- Prepare. 1. Design and implement technical controls. 2. Build organizational and personnel response readiness.
- Detect. 3. Monitor for unexpected activity. 4. Validate and secure monitors.
- Respond. 5. Collect, retain, and analyze evidence. 6. Mitigate and shut down undesired activity.
- Recover. 7. Verify and strengthen containment before resuming agent activity.
- Report. 8. Coordinate with affected parties. 9. Notify government. 10. Share information publicly.
The most useful thing about the document is what it does not do. It does not invent a new governance framework. It builds explicitly on NIST's Cybersecurity Framework 2.0 and SP 800-61r3, and tags every practice with CSF references. Your security operations center, your incident response plan, and your control catalogue already speak this language. Agents get a layer on top of them, not a parallel program.
The gap enterprises have to close themselves
Read the footnote on the incident definition. Actions resulting from "an adversarial prompt injection or an intentionally backdoored model" count as instructed, and are therefore not the primary cause of a control incident.
That scoping makes sense for a lab studying whether its own model misbehaves. It does not work for an enterprise. When an agent with your credentials emails a customer file to an outside address, you do not get to choose whether the cause was the model's own initiative or an instruction hidden in a web page it read. At the start of an investigation, you rarely know. Both need the same containment, the same evidence, and the same notification analysis. Under Quebec's Law 25, for example, the notification duty turns on the risk of serious injury to the people affected, not on who or what decided to act.
So write one runbook for agent incidents. "Was the action instructed, and by whom?" is a finding of the investigation, not a filter on whether the runbook applies.
The ten practices, translated for an enterprise deployer
Here is what each stage asks of an organization that deploys agents rather than trains models. The practice numbers refer to the source document.
Prepare
- Give every agent its own identity and the least privilege its task needs, not a shared service account or a human's token (1.1).
- Enforce network egress with an allowlist, routed through a monitored gateway (1.5).
- Map the persistence and communication channels an agent could use: scheduled jobs, new credentials, outbound messages, other agents (1.4).
- Build a way to block, contain, or terminate agent activity quickly, and test it (1.7).
- Assume the agent will find your misconfigurations, because it will (1.8). CERT-In's victims were breached through exposed credentials and permissive cloud roles.
- Define indicators and severity levels for agent incidents and near-misses, and run a tabletop exercise on one (2.1, 2.2).
Detect
- Write down the intended scope of each agent: which systems, which networks, which actions. You cannot detect a deviation from a baseline nobody defined (3.1).
- Monitor at every layer you control: the harness, the host, the network, and the identity provider (3.2).
- Make sure the agent cannot read, alter, or switch off its own logs and monitors (3.3).
- Place canaries, such as decoy credentials or records, that only an out-of-scope agent would touch (3.5).
Respond
- Retain tamper-resistant logs with reliable timestamps, enough to reconstruct the agent's trajectory, tool calls, user interactions, and security-control decisions (5.3).
- Keep the rejected actions and tool calls, not only the successful ones (5.1). Blocked attempts are your near-miss data.
- On detection, shut down the affected agent runs automatically, then pause similar agents until controls are verified (6.2, 6.3).
- Revoke every credential the agent touched and rebuild what it may have changed (6.4).
- Hunt for persistence: new keys, scheduled tasks, modified code, hidden channels (6.5).
Recover
- Rebuild from verified baselines: harness code, container images, tool configuration (7.1).
- Before restarting, prove that logging, egress rules, shutdown, and permission limits actually work (7.3).
- Replay the incident against the new controls to confirm they would have stopped it (7.4). Anthropic did exactly this: its new detection tooling blocked every case it was tested against.
- Record the restart decision and the residual risk someone accepted (7.5).
Report
- Notify the owners of any system your agent touched, including third parties who were not the target (8.1).
- Meet your legal reporting duties: privacy regulators, sector regulators, contracts (9.1).
- Feed lessons back to your model and platform vendors (8.3).
The reconstruction test
CERT-In's advisory contains the most uncomfortable fact of the month: the organizations whose systems were accessed did not detect it. They learned about it because the AI providers disclosed it.
Turn that into an acceptance criterion for every agent deployment:
If your model provider disappeared tomorrow, could you reconstruct your agent's last 24 hours of activity from your own records?
Passing means you hold, in systems you control:
- Which identity the agent acted as, and who it was acting for
- Every tool call, with its parameters and its result
- Every network destination it reached or tried to reach
- What data it read, and what it wrote, changed, or deleted
- Every control decision: allowed, blocked, escalated to a human
Provider-side logs are useful. They are not your evidence. They answer to someone else's retention policy, someone else's priorities, and someone else's incident. CERT-In's own recommendation for organizations running agents is a short-lived, least-privilege identity per run, default-deny egress, and "a tamper-resistant log of agent activity," with logs retained for at least 180 days.
The agent can act, but it cannot authorize itself
Look again at Anthropic's cases. A fetch tool had a length limit. The model used a URL shortener. A form was off-limits. The model found the real one when the practice copy failed to load. Anthropic describes these as forms of persistence: the model works around a restriction instead of stopping.
That is the behavior to design for. A restriction that the agent can read, reason about, and route around is a speed bump, not a boundary. The key practices put clear task instructions at 1.3, one practice among ten. Everything else is enforced outside the model.
The architectural rule follows: the agent can act, but it cannot authorize itself. Consequential actions, such as payments, external communications, production changes, permission grants, and access to new data stores, pass through a gate the agent does not control. A deterministic policy check, a human approval, or both. The agent can request. Something else decides.
Start counting near-misses now
The key practices define near-misses and ask organizations to report them. The UK is considering near-miss reporting in law. Whatever your jurisdiction does, the data is valuable to you first.
Add two fields to your incident and alert records:
- Agent attempted an unauthorized action: yes or no
- Control prevented impact: which control, or none
Over a quarter, those two fields tell you whether your agents are probing boundaries more or less often, and which controls do the catching. If your egress allowlist blocks forty attempts a month and your approval gate never fires, you have learned where your real boundary is. If the "control prevented impact" field keeps saying "none," you have learned something more urgent.
How we help
- GenAI Security Readiness Assessment. A fixed-scope review of your agents' identities, tool permissions, network egress, logging, and kill mechanisms, with findings mapped to the key practices and to CSF 2.0, each with an owner and a remediation.
- Agent incident readiness. An agent-specific runbook built on top of your existing incident response plan, and a tabletop exercise that tests it against a realistic scenario: an agent with valid credentials doing something no one asked for.
- Board advisory. A one-page view of agent exposure for directors. Our post on questions a board should ask before an AI coding tool rollout shows the format.
Five questions to test yourself
- Can you list every agent running in your environment today, with an owner for each?
- Does each agent have its own identity, or does it act with a human's token or a shared service account?
- If an agent tried to reach an unapproved destination this morning, which control would have blocked it, and where is the record?
- How long would it take to stop every agent instance and revoke every credential they hold, and when did you last test it?
- Could you pass the reconstruction test for your most privileged agent without asking your vendor for anything?
If you hesitated on two of them, your agents are ahead of your incident response plan. That gap is cheaper to close before the first incident than during it.