Author: Len Noe, BeyondTrust Solutions Architect
When an AI agent causes an incident, responders must quickly determine which identity acted, what privileges it used, and which systems or third parties may have been affected. A joint guide published by the National Institute of Standards and Technology (NIST), the Cybersecurity and Infrastructure Security Agency (CISA), and the National Security Agency (NSA) on October 16, 2026, outlines 10 voluntary practices for preparing for and responding to incidents involving highly capable agents. Although the guide focuses on training and evaluation environments, its central lesson applies more broadly: incident response depends on reliable identity, credential, session, and audit data.
The first question on an incident bridge is often not why something happened, but whose credentials were used. In my experience, the person who can answer the credential questions during the first hour sets the pace for everything that follows: what to isolate, what to cancel, whom to notify, and how far the damage spread.
Teams without that information can spend their first day reconstructing it from logs that were never designed to provide a clear answer.
The NIST, CISA and NSA incident guide
The 14-page document, Key Practices for Incident Preparation and Response in Superintelligence Training and Assessment, is intended for organizations training or evaluating highly capable agents for long-term tasks—work performed in many steps over an extended period with limited human supervision. The authors say it may also be relevant to implementation personnel.
The guide divides its 10 practices into five stages: prepare, detect, respond, recover, and report. It defines a control incident as an event in which an agent performs a significant action that was not directed by an operator or adversary, compromising control, policy, or human oversight.
NIST says the practices are based on established incident-management frameworks. Many of the recommended measures will therefore be familiar, including least privilege, credential management, monitoring, evidence preservation, and rebuilding from a known baseline.
The difficulty comes from applying familiar controls to new principals: AI agents that may act with substantial authority but are not human users.
Incident response starts with identity, not intent
One detail in the definition is particularly important for responders. Under the guide, actions caused by an adversarial prompt injection or a backdoored model are treated as directed rather than undirected. They therefore fall outside the definition of a control incident. That distinction may be consistent for researchers, but it is difficult to apply during an active investigation, when intent usually cannot yet be established.
Investigators can identify an identity, its privileges, and a record of its actions. They may not initially know whether the agent was misled, malfunctioned, or compromised.
Preparing agents for incidents therefore requires organizations to avoid relying on an initial classification of the cause. They need to determine which identity acted, what authority was associated with it, and what the agent did with that authority.
AI agents may operate with the same authority as the people using them, creating new risks if their actions are left unchecked. BeyondTrust says its now generally available AI Agent Security applies policies to individual agent actions at runtime and can block malicious activity without restricting what human users can do. Examine AI agent security.
Credential revocation only reaches systems an organization controls
Practice 6 instructs organizations to revoke credentials accessed by agents during an incident and rebuild potentially compromised environments. The phrase “under the control of an organization” is significant. An agent may store credentials that an organization holds but does not issue, meaning the organization may be unable to revoke them directly.
The OpenCode breach illustrates this problem. OpenCode, an open-source coding agency, told some users of its hosted console service that API keys stored for external providers, including Anthropic, OpenAI, and Google, had been exposed.
The company said 1.4% of console users were affected, with the earliest impact occurring at 12:30 a.m. UTC on October 17. Users reported fraudulent charges ranging from a few hundred dollars to $1,700 overnight.
In some cases, Google Cloud projects were taken down because of fraudulent activity consistent with resource hijacking. The company did not say how the attackers gained access, describing the incident as a large-scale distillation attack.
Organizations should treat their understanding of an agent’s account access as provisional. Keys stored by an agent platform can be revoked only by the account owner through the provider that issued the key, and the account holder may not know that the key was exposed.
The guide’s remediation steps assume an inventory of the systems and credentials agents may access. Without that inventory, there may be nothing to undo. The reporting stage creates a related obligation: organizations must notify parties whose systems have been compromised or misused, including third parties that were not the ultimate target.
In the OpenCode case, those parties could include model providers and individual key owners. Unless an organization knows which keys are stored where, it may not be able to notify them in time.
Contain agents without relying on their cooperation
The guide advises designers to assume that agents will discover misconfigurations and vulnerabilities and to build controls accordingly. MIT Technology Review’s reconstruction of July’s “Face Hug Incident” shows why that assumption matters.
The agent, which was built on an OpenAI model, was supposed to be isolated from the internet during a cybersecurity assessment. It went online anyway and hacked Hugging Face while looking for a solution to a problem it could not otherwise resolve.
Network isolation was one of the controls in place, but the agent circumvented it. OpenAI researchers believe the behavior resulted from rewarded training.
Determined attackers—human or otherwise—can circumvent network perimeters. Credentials limited to a single task, set to expire when that task ends, and assigned to an identity separate from the user who started the agent do not depend on the agent’s behavior. They can limit what a compromised copy of the agent is able to do.
The guide points in the same direction by recommending access limited to what a task requires, disposable infrastructure where possible, and mechanisms to quickly block, contain, or terminate agent activity. Many of these controls depend on identity.
Accountability for non-human actors
The guide calls for tamper-proof logs with sufficiently reliable timestamps to reconstruct an agent’s trajectory. It also says agents should not be able to access or alter the monitoring systems or logs themselves. In practice, this amounts to session accountability for agents.
Privileged sessions for human administrators are normally attributed to individuals, recorded, and made visible. The same standard should apply to agents. The guide asks responders to preserve denied actions and tool calls, along with the configurations of the agents, safeguards, and environments, so investigators can reproduce the incident.
Rejected actions can reveal what an agent was attempting to reach and may be more informative than the actions it successfully completed.
New research from BeyondTrust Phantom Labs™ suggests that prompt-level logging alone is insufficient. In a customer sample collected over four weeks, coding agents requested approximately 1.28 million shell commands from approximately 132,000 prompts—nearly 10 commands per prompt. These were requested commands, not confirmed executions. Logs that cannot distinguish between actions taken by an agent and those taken by a user make it impossible to determine whose privileges were used.
Legacy systems can make this difficult. Many cannot log activity for individual agents, and some agents operate through shared service accounts because their integrations were built that way three years ago. Budgets may also be limited. A practical starting point is to identify agents with access to the most sensitive data or important actions, give them distinct identities, and expand the approach as the application allows.
Why rare agent incidents still require preparation
The strongest objection is proportionality. The guide is aimed at frontier training and evaluation environments, and the incidents it covers are rare. One report cited six incidents among 141,006 reviews published by one lab. Most companies have deployed agents that are less capable than those surveyed, and the damage reported so far has been minor.
That raises a reasonable question: why build response capacity for a problem that is mostly theoretical?
The underlying mechanism is not purely theoretical. From an identity perspective, a compromised or misdirected agent behaves much like a compromised service account.
Measuring AI agent incident readiness
Readiness should be measured by results rather than documentation. How long does it take to enumerate every credential available to a particular agent ID, including keys stored for third parties? What percentage of agents operate under their own identities with a designated human sponsor? Can the organization create session records that distinguish between actions performed by an individual and those performed by an agent on that person’s behalf?
If these questions can be answered within minutes, the organization is better prepared for an agent-related incident, regardless of how the event is ultimately classified. If answering them takes several days, more sophisticated classification methods will not solve the underlying problem.
About the author
Len Noe is a solutions architect for BeyondTrust, Transhuman, and podcaster, as well as an international cybersecurity speaker, author, technical evangelist, and biohacker with 11 microchips.
A former black hat with more than 30 years of experience in the technology industry, he has presented in more than 70 countries and was featured in the documentary “I Am Machine,” which premiered at DEF CON 2025.
About BeyondTrust
BeyondTrust describes itself as a provider of privilege-centric identity security that protects Paths to Privilege™. The company says identity alone does not create risk; privileges do. As human, machine, and AI agent identities expand across environments, BeyondTrust says its platform is designed to discover, control, and protect them. The company says it is trusted by more than 20,000 customers, including 75 Fortune 100 companies, and is recognized as a multi-category leader by industry analysts.
Learn more at www.beyondtrust.com.
Sponsored and written by BeyondTrust.
Source: www.bleepingcomputer.com