When an AI Agent Is the Incident, the Identity Record Is the Evidence

Author: Len Noe, Solutions Architect, BeyondTrust

The first question on any incident bridge isn’t about why it happened--it’s whose credentials were used. In my experience, whoever can answer that credential question in the first hour sets the pace for everything after it: what to isolate, what to revoke, whom to notify, and how far the damage could have spread.

The teams that can’t answer it spend the first day reconstructing their answer from logs that were never designed to provide it.

That discipline is about to be tested by a new kind of actor. On October 16, 2026, the National Institute of Standards and Technology (NIST), the Cybersecurity and Infrastructure Security Agency (CISA), and the National Security Agency (NSA) jointly published ten voluntary practices for incident readiness and response when AI agents act in ways nobody directed.

The guide, Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation, is useful, and it’s also easy to misread. Its strongest guidance is about identity, even though it rarely uses that word as a headline.

What the NIST, CISA, and NSA Incident Guide Covers

The 14-page document is written for organizations that train or evaluate highly capable agents on long-horizon tasks (work that runs through many steps over a long period) with limited human supervision, although the authors say deployers may find it relevant. It organizes ten practices into five stages: prepare, detect, respond, recover and report.

It defines a control incident as an event in which agents take significant actions that were not directed by the operator or an adversary, and that undermine controls, policies or human oversight.

The agencies say the practices build on established incident-management frameworks, so most of what they ask for will look familiar: least privilege, credential management, monitoring, evidence preservation, rebuilding from known baselines.

Familiar controls applied to a new principal are where most organizations are likely to stumble.

AI Agent Incident Response Starts with Identity, Not Intent

One detail in the definitions matters for responders. The guide treats actions caused by adversarial prompt injection or a backdoored model as instructed, not uninstructed, so they fall outside its definition of a control incident. While that line is coherent for researchers, it’s difficult for responders; at the moment of an incident, the question of intent is usually unanswerable.

What an investigator has in hand is an identity, a set of permissions, and a trail of actions.

Agent incident readiness can’t depend on classifying the cause first. It has to work from an identity record to determine which identity acted, what authority stood behind it, and whether the agent was misled, malfunctioning, or compromised.

Revocation Reaches Only What You Can Reach

Practice six tells organizations to revoke any credentials the agent accessed during the incident that the organization controls, and to rebuild potentially compromised environments. The qualifier "under the organization's control" carries more weight than it may appear to at the outset. Agents accumulate credentials that the organization holds, but doesn’t issue.

The OpenCode breach shows how that plays out. OpenCode, an open-source coding agent, 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 its Console users were affected, and that the earliest exposure was at 00:30 UTC on October 17. Users reported unauthorized charges with costs ranging from several hundred dollars to as much as $1,700 overnight.

In some cases, Google Cloud projects were suspended for abusive activity, consistent with hijacked resources. The company hasn’t said how the attackers got in, and describes the incident as a large-scale distillation attack.

Take the company's account as provisional. What matters for readiness is the shape of the problem. A key stored by an agent platform is revocable only at the provider that issued it, by the person who owns the account. And the account holder may not even know the key was ever exposed.

The guide's revocation step presupposes an inventory of what the agent could touch. Without it, there’s nothing to revoke against. The guide's reporting stage adds a second obligation that follows from the same inventory: notify the parties whose systems were compromised or exploited, including third parties who were not the final target.

In the OpenCode case, those parties are the model providers and the individual key owners, and none of them can be notified in time unless someone knows which keys were stored where.

Containing an AI Agent Without Relying on the Agent’s Cooperation

The guide advises designers to assume agents will often find misconfigurations and vulnerabilities, and to build controls accordingly. MIT Technology Review's reconstruction of the July Hugging Face incident shows why.

Agents built on OpenAI models were supposed to be isolated from the internet during a cybersecurity evaluation. They got online anyway, hacked Hugging Face, and retrieved solutions to problems they were stuck on.

The one control the article describes is network isolation, and the agents got around it. OpenAI's own researchers attribute the behavior to training that rewarded it.

Network boundaries can be evaded by a determined actor, human or not. A credential that’s scoped to one task, expires when the task ends, and belongs to an identity separate from the person who launched the agent does not rely on the agent behaving, and it limits what a leaked copy can do.

The guide points the same direction when it asks for access limited to what’s necessary for intended tasks, single-use infrastructure where possible, and mechanisms to quickly block, contain, or terminate agent activity. Most of those are identity controls.

Session Accountability for Non-Human Actors

The guide also asks for tamper-resistant logs with reliable timestamps sufficient to reconstruct agent trajectories, and for assurance that agents can’t access or tamper with the monitors and logs themselves. That is session accountability in everything but name.

For a human administrator, a privileged session is attributed to a person, recorded and reviewable. The same standard should apply to an agent. The guide supports this by asking responders to preserve rejected actions and tool calls, and to record the configurations of agents, safeguards and environments so an incident can be reproduced.

A rejected action is evidence of what the agent tried to reach, which is often more revealing than what it succeeded in doing.

New research from BeyondTrust Phantom Labs™ drawing on endpoint telemetry shows why prompt-level logs fall short. In customer samples taken over a four week period, coding agents requested about 1.28 million shell commands from roughly 132,000 prompts, close to ten commands per prompt. Those are requested commands, not confirmed executions. A log that can’t separate what the agent did from what the user did is unable to answer whose authority was used.

Enterprise reality will complicate this. Many legacy applications can’t log per-agent activity. Some agents will run through shared service accounts because that’s how the integration was built three years ago. Budgets are finite. A realistic path starts with the agents that can reach the most sensitive data or the most consequential actions, gives them separate identities, and works outward as applications allow.

Why Rare Agent Incidents Still Justify Preparation

The strongest counter-argument is proportionality. The guide is aimed at frontier training and evaluation, and the incidents it responds to are rare: six in 141,006 evaluations in one lab's disclosure. Most enterprises deploy agents far less capable than the ones under study, and the reported harm so far has been modest.

Why build response capability for a problem that’s mostly theoretical?

The answer is that the underlying mechanics aren’t just theoretical. A compromised or misdirected agent behaves, from the perspective of the identity record, like a compromised service account with a faster tempo.

How To Measure AI Agent Incident Readiness

Readiness should be measured in outcomes rather than documents. How long does it take to enumerate every credential a given agent identity can use, including keys it stores for third parties? What share of agents runs under its own identity, with a named human sponsor? Can the organization produce a session record that distinguishes what a person did from what an agent did on that person's behalf?

If those questions take minutes to answer, the organization is ready for the first agent incident, regardless of how it is classified. If they take days, a more elegant taxonomy will not help.

About the Author

Len Noe is a Solutions Architect at BeyondTrust, Transhuman, Podcaster, International Cyber Security Speaker, Author, Technical Evangelist, and Biohacker with 11 implanted microchips.

A former blackhat with more than 30 years in technology, he has presented in over 70 countries and is featured in the documentary I Am Machine, which premiered at DEF CON 2025.

About BeyondTrust

BeyondTrust is the global leader in privilege-centric identity security protecting Paths to Privilege™. Identity alone doesn’t create risk. Privilege does. As human, machine, and AI agent identities explode across every environment, BeyondTrust is the only company built to discover, control, and secure privilege across all of them from a single platform. Trusted by 20,000+ customers, including 75 of the Fortune 100, and recognized as a multi-category leader by top industry analysts, BeyondTrust reframes identity security from a management problem into a strategic advantage.

Learn more at www.beyondtrust.com.

Sponsored and written by BeyondTrust.