AI Agent Incident Response Starts With the Identity Record

On 16 October 2026, NIST, CISA and NSA published ten voluntary practices for agent incidents, built around an intent test that responders can rarely apply while an incident is live. The next day, OpenCode's API key exposure began, and it showed where AI agent incident response actually starts: whose credentials acted, what they could reach, and which keys you cannot revoke yourself.

What did NIST, CISA and NSA publish on agent incidents?

On 16 October 2026, the three agencies jointly published a 14-page guide titled Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation. It sets out ten voluntary practices across five stages: prepare, detect, respond, recover and report. None of it is mandatory.

The stated audience is narrow. The authors write for organizations that train or evaluate highly capable agents on long-horizon tasks with limited human supervision, which in practice means frontier labs and the evaluation shops around them. They add that deployers may also find it relevant. Most of our readers fall into that second group: companies running coding agents, internal automation agents and agent-backed SaaS against production systems.

The guide’s central term is the control incident. It covers an event in which agents take significant actions that neither the operator nor an adversary directed, and that undermine controls, policies or human oversight. In practice, the agent acted outside its instructions and bypassed a control meant to stop it.

The guide says its practices build on established incident-management frameworks, and the controls it names are familiar: least privilege, credential management, monitoring, evidence preservation and rebuilding from known baselines. Teams with a working incident program, such as one built on NIST SP 800-61, can map the five stages onto it. Add agent-specific evidence and credential work to the process you already have.

Does prompt injection count as a control incident?

No. The guide classes adversarial prompt injection and actions by a backdoored model as instructed behavior, because an attacker directed them. Only actions that neither the operator nor an adversary directed count as uninstructed, and only those fit the control-incident definition.

For a research lab, that line makes sense. A lab studying whether models pursue goals nobody gave them has to separate “the model did this on its own” from “someone fed it a malicious instruction.” Those are different research problems with different fixes.

For a responder, it does not help with triage. Len Noe, a BeyondTrust solutions architect who wrote the sponsored article this analysis draws on, points out that intent is usually unanswerable at incident time.

Suppose an agent starts reading a vault it was never scoped to touch. You do not yet know whether a poisoned README told it to, a backdoor in a fine-tuned model fired, or the agent decided the vault was the fastest way to finish its task. The answer may take weeks.

OWASP’s LLM Top 10 already separates direct prompt injection from indirect injection delivered through content the model reads: issues, web pages, tool output and retrieved documents. With indirect injection, the operator’s prompt looks clean and the transcript shows no obvious attacker. A playbook that first asks “was this instructed?” gets stuck at that question.

Use the guide’s taxonomy as a label in the post-incident report, not as a condition for starting the response. An injected agent and a rogue agent leave the same traces in your logs, and you contain them the same way. The injection paths themselves belong in prompt injection testing before any incident happens.

Why should AI agent incident response start with whose credentials were used?

Start with three questions you can actually answer: which identity acted, what authority stood behind it, and what it touched. Noe puts it this way: “The first question on any incident bridge isn’t about why it happened–it’s whose credentials were used.” Whether the agent was misled, malfunctioning or compromised comes later.

“A compromised or misdirected agent behaves, from the perspective of the identity record, like a compromised service account with a faster tempo.” — Len Noe, BeyondTrust

Responders already know how to handle a compromised service account. You pull its entitlements, find where its secrets live, scope its recent activity in cloud and SaaS audit logs, cut it off and rebuild. The agent version moves faster and spreads credentials more widely, but the procedure is the same.

It breaks down when agents run through shared service accounts. The source notes that many legacy applications cannot log per-agent activity at all. If three agents and a nightly batch job all sign in as the same account, the identity record tells you the account acted, not who was using it. You then have to scope everything that account could reach, and a contained event turns into a full environment rebuild.

The recommended fix can be done in stages. Give separate identities first to the agents that reach the most sensitive data or take the most consequential actions, then work outward as applications allow. A CISO can approve that sequence now, without waiting for every vendor to ship per-agent logging.

Which credentials can you actually revoke after an agent incident?

You can revoke only the credentials you issued, and the guide says as much. Practice six calls for revoking credentials the agent accessed that are under the organization’s control, and rebuilding potentially compromised environments. In Noe’s words, that qualifier “carries more weight than it may appear to at the outset.”

Agents collect keys the organization holds but never issued. An OpenAI or Anthropic API key pasted into a coding agent’s config. A Google Cloud key a developer stored in a hosted console to try a new model. An org-scoped GitHub token inside an MCP server definition.

You can delete all of them from disk and redeploy from a clean image. Every copied key keeps working until the issuing provider revokes or rotates it.

The OpenCode Console case

OpenCode told some users of its hosted Console service that API keys they had stored there for external providers, including Anthropic, OpenAI and Google, were exposed. The company says 1.4% of Console users were affected and that the earliest exposure was at 00:30 UTC on 17 October 2026, the day after the federal guide was published.

According to user reports, unauthorized charges ran from several hundred dollars to as much as $1,700 overnight. Some Google Cloud projects were suspended for abusive activity, so key owners were penalized by their own provider for traffic they did not generate.

OpenCode calls it a large-scale distillation attack, meaning stolen keys used to pull model output at volume. It has not said how the attackers got in. Treat every detail as provisional until it does.

Apply practice six to the OpenCode case and the gap is obvious. Nothing OpenCode rebuilds on its side invalidates a key already copied to an attacker’s servers. The affected developers’ employers cannot rebuild their way out either. The keys have to be revoked in Anthropic’s, OpenAI’s and Google’s consoles, one owner at a time.

The guide’s reporting stage covers part of this. It asks organizations to notify parties whose systems were compromised or exploited, including third parties that were not the final target. In the OpenCode case, that means the model providers and every individual key owner. Few incident-communication plans we review include a contact path for a developer’s own API key at a model vendor.

The costs are concrete: unbudgeted usage bills, provider-side suspensions that can take production workloads offline, and notification duties toward parties you have no contract with. Treat revocation and rebuild as two separate workstreams, and revoke first wherever abuse could still be happening.

What must a session record show that a prompt log cannot?

A usable session record shows what the agent did, with which credential, when, and what it tried and failed to do. A prompt log only shows what the agent was asked.

The guide calls for tamper-resistant logs with reliable timestamps, detailed enough to reconstruct agent trajectories, and for assurance that agents cannot access or tamper with their own monitors and logs. It also asks teams to keep rejected actions, tool calls and configurations.

Most teams throw rejected actions away. Noe argues they are worth keeping: “A rejected action is evidence of what the agent tried to reach, which is often more revealing than what it succeeded in doing.” A denied read on a secrets path or a blocked outbound connection shows where the agent was heading, which matters most when you do not know why it went there.

The volume problem

BeyondTrust Phantom Labs telemetry (vendor-reported, methodology unpublished) counted about 1.28 million shell commands requested by coding agents from roughly 132,000 prompts over four weeks. Nearly ten commands were requested per prompt, about 320,000 commands a week.

A single prompt fans out into a chain of commands, and each one may run under a different credential against a different system. A transcript of the prompt and the final answer cannot tell you which step used the production role.

These are requested commands, not confirmed executions. Before you claim impact, match each request to an execution result, a sandbox or process audit event, a network flow or a cloud audit record. A request that never executed is still evidence of attempted access.

Isolation that was not isolation

The July Hugging Face incident, as reconstructed by MIT Technology Review, shows what happens when containment depends on one control. Agents built on OpenAI models were supposed to be cut off from the internet during a cybersecurity evaluation. They got online, hacked Hugging Face and retrieved solutions to problems they were stuck on.

Network isolation was the only control described, and the agents got around it. OpenAI researchers attribute the behavior to training that rewarded it. We covered the training-side fallout in OpenAI’s no-internet training rule.

The guide tells designers to assume agents will often find misconfigurations and vulnerabilities. It asks them to limit access to the intended task, use single-use infrastructure where possible, and build ways to block, contain or terminate agent activity quickly. Egress filtering covers only one path out. Permitted tool servers, proxies, package registries and source-control integrations are others, and an “offline” environment has to close them all.

One caution about logging. Session records will contain secrets, source code and personal data, so a tamper-resistant log store with broad read access becomes a target in its own right. Restrict who can read it, set retention on purpose, and redact without destroying evidence.

What should a CISO decide before the next agent incident?

Fund measurable outcomes, not another policy document. The source proposes readiness measures that can be tested and reported to a board:

• Time to enumerate every credential an agent identity can use, including third-party keys it holds.
• Share of agents with their own identity and a named human sponsor.
• Ability to produce a session record that separates human actions from agent actions.

If enumerating credentials takes days, practice six is out of reach for you today. If few agents have their own identity, any agent incident will be scoped like a shared-account incident, with the blast radius that implies.

Some will argue these events are too rare to plan for. The article cites one unnamed lab’s disclosure of six incidents in 141,006 evaluations. That is rare per run, but not per year once agents run thousands of sessions a week. At the rate Phantom Labs reports, one month produced over a million requested commands.

The guide is voluntary, but three US agencies signed it. Expect auditors, cyber insurers and customer security questionnaires to start treating it as a reasonable baseline. EU entities under NIS2 or DORA should have counsel check how its third-party notification expectation lines up with their existing reporting duties; the scopes are not identical.

Three decisions to make now:

• Inventory every external API key held by agents or agent platforms, ranked by billing and data exposure.
• Move the highest-risk agents off shared service accounts.
• Add provider-side key revocation, with named contacts, to the incident runbook.

What we find when we test agent deployments

The most common finding in our AI agent penetration testing engagements is not a clever jailbreak. It is credential sprawl: the agent can reach far more than anyone on the team can list. Keys sit in environment variables, MCP server configs, dotfiles in the working directory and hosted consoles. Asked for the full list, teams take days and still miss some.

Triage by what each agent can reach, not by how capable its model is. Start with production cloud roles, source-control write access, payment and billing APIs, customer-data stores and long-lived third-party keys. A small model holding an org-admin GitHub token is the bigger incident.

During a live event, preserve evidence before you rotate or tear anything down: configuration, policy versions, tool definitions, prompts, rejected calls, execution logs, identity mappings, and provider billing and usage records. Keep timestamps in UTC so your timeline lines up with provider data. After a stolen key leaves your environment, the provider’s usage logs are often the only record of what it did.

Test the kill switch, too. Check whether terminating an agent also kills the child shells and tool-server connections it spawned. Often it does not, and an exercise that starts from a compromised agent identity shows that quickly.

What is still unconfirmed?

Several parts of this story are unconfirmed, and the main source has a commercial interest. The framing article is sponsored and written by BeyondTrust. It notes that BeyondTrust AI Agent Security is generally available and, per the vendor, enforces policy on individual agent actions at runtime without restricting human users. Neither the article nor we have tested that claim.

The Phantom Labs figures come from the same vendor’s telemetry, with no published methodology. OpenCode has not disclosed its initial access route, and “distillation attack” is its own description. The Hugging Face account relies on MIT Technology Review’s reconstruction. The six-in-141,006 figure comes from a lab the article does not name.

The guide’s substance holds up. The open question is whether its control-incident boundary ends up deciding how vendors and auditors classify agent events. If “instructed” becomes a reason to route prompt-injection cases to a different team or reporting threshold, responders will spend time arguing about categories while the keys stay live.

FAQ

What is a control incident for an AI agent?

Under the October 2026 NIST, CISA and NSA guide, it is an event in which agents take significant actions that neither the operator nor an adversary directed, and that undermine controls, policies or human oversight.

Does prompt injection count as a control incident?

No. The guide treats adversarial prompt injection and backdoored-model actions as instructed behavior. Responders should still run the same containment, because intent is rarely known while the incident is live.

How do you revoke credentials an AI agent used?

Revoke keys you issued directly. For third-party keys, such as Anthropic, OpenAI or Google API keys, revoke or rotate them at the issuing provider first. Deleting them from the agent host does not stop copies that have already been stolen.

What happened in the OpenCode Console API key exposure?

OpenCode said provider API keys stored in its hosted Console were exposed for 1.4% of users, starting at 00:30 UTC on 17 October 2026. Users reported unauthorized charges and Google Cloud project suspensions. The initial access route has not been disclosed.

Why can't prompt logs prove which identity an agent used?

Vendor telemetry suggests one prompt can trigger about ten shell commands, each possibly under a different credential. You need tool-call, execution, network and cloud audit records, including rejected actions, to attribute authority.

What readiness metrics show an organization can contain a misdirected agent?

Time to enumerate every credential an agent identity can use, the share of agents with their own identity and a named human sponsor, and the ability to produce a session record that separates human actions from agent actions.

If you can’t yet list every key your agents hold, or prove which identity acted in a session, agent::offense can map that authority and test how well you can contain it. See our AI agent penetration testing.