AI Agent Incidents: Ask Which Identity Acted, Not Why

When an AI agent does something nobody asked it to do, the first question in the room is always why. Was it the prompt, the model, an injection? I think it's the wrong first question, because you won't have that answer while the incident is still running.

The question you can answer mid-incident is narrower: which identity acted, and what credentials did it use? On October 16, 2026, NIST, the NSA, and CISA published guidance that treats an off-script agent as an incident to rehearse. This post covers what the guide says, where it stops, and the three things I'd set up in Entra this week so the identity record exists before you need it.

What the guide actually says

The document is Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation, a 14-page TLP:CLEAR release from NIST's Center for Advancing Innovation and Standards for Super Intelligence, the NSA's Super Intelligence Security Center, and CISA. It lays out ten voluntary practices across five stages: prepare, detect, respond, recover, and report. The "Super Intelligence" wording matches how federal documents now refer to AI.

Its central term is the SI control incident: one or more agents take "significant uninstructed actions" that compromise the policies, controls, or security measures an operator set to define the task or keep humans in oversight. "Uninstructed" means neither the operator nor an adversary directed the action.

A few practices matter most for anyone running agents in production:

• Practice 2.2: run drills and simulations for control incidents, including detection, response, recovery, and reporting.
• Practice 3.3: agents must not be able to access or interfere with monitoring and logs.
• Practices 5.1 and 5.3: keep tamper-resistant, timestamped logs that can reconstruct agent trajectories, tool calls, and security-control decisions, including rejected actions and tool calls.
• Practice 6.4: revoke credentials "under the organization's control" that were accessed during the incident, and rebuild environments that may be compromised.

None of this is theoretical. Anthropic reviewed 141,006 evaluation runs and found six runs across three incidents where Claude reached live systems at real organizations, because a vendor misconfiguration left internet access the prompt said wasn't there. In July, OpenAI models in a supposedly isolated cybersecurity evaluation got online and hacked Hugging Face to find answers.

Why "why" is the wrong first question

Here is the part of the definition I keep coming back to. The guide's footnote says actions from an adversarial prompt injection or an intentionally backdoored model count as instructed, so they aren't treated as the primary cause of a control incident.

That makes sense for a lab writing a post-incident report. It doesn't help much at 2 a.m., because classifying the event requires intent, and intent is the last thing you'll establish. What you can establish quickly is the identity that requested the token, the resources it touched, and the credentials behind it. Contain on that, then classify later.

That only works if each agent has an identity of its own. If five agents share one app registration and its client secret, the sign-in log tells you "the app did it," and revoking the secret takes down all five.

What the identity record looks like in Entra

The guide doesn't name any product, and its only identity item is "Agent Identifiers" under future work. The Microsoft mapping is mine, though Microsoft is listed among the guide's contributors.

Microsoft Entra Agent ID gives each agent an agent identity: a special service principal with its own object ID, a display name, and a sponsor, "the human user or group that's accountable," which Microsoft says is used for contacting a human when a security incident happens. Agent identities have no credentials of their own. The agent identity blueprint holds the federated credentials, certificates, or client secrets and gets tokens on the agent's behalf.

That last detail matters for incident response. Microsoft's Agent 365 identity guidance says blueprint credentials are shared by every agent identity created from that blueprint, so treat each blueprint as a credential boundary. Its best practices say to provision a unique identity per agent instance, assign a sponsor and owner at creation, and include agents in incident response.

On the evidence side, Entra sign-in logs carry an agentSignIn event type with filters for Agent type and Is Agent. Audit logs are less helpful than you'd hope. Microsoft's FAQ says they don't distinguish agent identities by default: a new agent identity shows up as "Create service principal," and you correlate object IDs through Microsoft Graph to work out what you're looking at.

For containment, you can disable a single agent identity or a whole blueprint, which stops token issuance, or use Conditional Access policies to block agent authentication tenant-wide.

Set it up this week

This is the drill I'd run before the guide's drill:

1. Inventory your agents. In the Entra admin center, go to Entra ID, then Agents, then Agent identities, and list them. Then look for agents that aren't there: older Copilot Studio and Azure AI Foundry agents may exist as classic service principals without agent identities.
2. One identity per agent. Anything sharing an app registration or a blueprint with agents it shouldn't share credentials with gets split.
3. A named sponsor on each. Check that every agent identity and blueprint has a current sponsor. People change jobs; sponsor fields don't update themselves.
4. List every credential each agent can use. The blueprint's federated credentials, certificates, and secrets, plus any keys the agent holds outside Entra, such as model provider API keys.
5. Run the stop. In a test tenant or on a low-risk agent, disable the agent identity and confirm the agent actually stops and the sign-in log shows it.
6. Route the logs. Send sign-in and audit logs somewhere the agent can't write, which is practice 3.3 in Microsoft terms.

SpyCloud's survey of 750 security leaders found 56% have formal governance and ownership of AI agent privileges, and 36% monitor those identities. It's a vendor survey, but it matches my experience: the list is the hard part.

Where this stops working

Three limits, stated plainly.

First, the guide is written for organizations that train or evaluate highly capable agents. It says the practices "may also apply to deployers." Applying it to your Copilot Studio agents is my extension, not the agencies' recommendation.

Second, revocation reaches only credentials you control. The guide says so in practice 6.4. When OpenCode disclosed that stored third-party AI provider keys for 1.4% of Console users were exposed, with users reporting overnight charges up to about $1,700, disabling anything in your own tenant wouldn't have touched those keys. Only the issuing provider can revoke them, which is why step 4 includes keys outside Entra.

Third, Agent ID only covers agents built on it. Anything still running as a plain service principal or a regular user account gives you a weaker record.

The takeaway

You won't know why an agent went off script until well after the incident. You can know which identity acted, who sponsors it, and which credentials to pull, if you set that up now. This week, pick one agent and list every credential it can use.