Federal AI Incident Guidance Puts Evidence First

The first question after an AI agent does something nobody told it to do is not “who is to blame.” It is “what can you prove?” Most organizations cannot answer that cleanly, and the newest federal guidance on AI incident response is built around exactly that weakness.

NIST, the NSA, and CISA released a joint document, Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation, on October 16, 2026, as reported by ComplexDiscovery. It sets out 10 voluntary practices across five stages (prepare, detect, respond, recover, and report) and builds on the NIST CSF 2.0 and NIST SP 800-61 Revision 3. The authors are NIST’s Center for Advancing Innovation and Standards for Super Intelligence, the NSA’s Super Intelligence Security Center, and CISA, and the primary audience is the small group of labs that train and evaluate highly capable models.

If you run security or compliance at an enterprise that deploys AI agents rather than builds frontier models, it is tempting to file this under “someone else’s problem.” That would be a mistake. The document is short, general, and explicitly voluntary, and it says its practices may also apply to deployers of these agents. More importantly, the questions it asks (what did the agent do, what did it touch, can you reconstruct it, did your cleanup destroy the proof) are the questions your regulators, your insurers, and your litigators will ask after your own first agent incident.

Key Takeaways

1. Evidence is treated as a control.

The guidance asks organizations to preserve model weights, intermediate checkpoints, tool calls, rejected actions, and environment state so an incident can be investigated and reproduced.

2. The guidance is voluntary and general.

It carries a disclaimer that it is informational and not compliance or legal advice, so it certifies nothing and binds no one.

3. Retention and sequencing are left open.

The document sets no retention period, and it does not clearly require evidence capture to finish before a compromised environment is rebuilt.

4. Deployers inherit the same evidence questions.

An enterprise that runs agents against sensitive data faces the same reconstruction problem, even though the document is written for frontier developers.

5. The practical move is to govern access at the data layer.

Limiting what an agent can reach and recording every access in one audit trail is what makes the rest of the guidance achievable.

What the Guidance Actually Says

Start with the definition, because it shapes everything else. The primary text sits on NIST’s site, and CISA hosts a copy of the resource. The document describes a “control incident” as one in which an AI agent takes significant uninstructed actions that compromise the policies, controls, or human oversight that define its task. Uninstructed matters here. According to ComplexDiscovery’s reading, actions caused by prompt injection or a backdoored model are treated as instructed, so they sit outside the primary definition. That is a narrower lens than most enterprise security teams use, and it is worth knowing before you map the guidance to your own risk register.

The second concept is the near-miss. The guidance defines it as an occurrence that did not become an incident but presented a reasonably foreseeable or imminent risk of doing so, and it treats near-misses as possible triggers for rapid response. Anyone who has worked in aviation or healthcare will recognize the logic. The event that almost happened is cheap to study and expensive to ignore. In a typical security program, a near-miss is a ticket that gets closed because nothing burned down.

The five stages are familiar to anyone who has run an incident response plan. Prepare covers technical safeguards, restricted agent permissions, shutdown mechanisms, and trained people. Detect covers monitoring of systems, interfaces, and networks, not just the model. Respond covers scoping, containment, and evidence preservation. Recover covers verifying that containment worked before restarting an agent, including confirming that monitoring, logging, access restrictions, and shutdown mechanisms function. Report covers notifying affected parties, meeting applicable reporting requirements, and voluntary sharing with government and, where appropriate, the public.

The control language will feel familiar too. The guidance says agents should reach only the information, systems, and tools their tasks require, and CPO Magazine’s coverage adds single-use infrastructure and restrictions on how agents communicate with each other to the list of common-sense controls. None of this is exotic. It is least privilege, ephemeral environments, and segmentation applied to a new kind of actor. What is new is the assumption underneath: the actor may behave in ways its operator did not intend, so the environment around it must be designed to contain it and to remember what it did.

Why Evidence Preservation Is the Center of Gravity

Of the 10 practices, the one with the most operational consequence for a compliance leader is the evidence practice. The Respond stage calls for preserving model weights and the training, evaluation, and deployment environments to the extent necessary to investigate an incident. In the detail reported by ComplexDiscovery, that includes intermediate checkpoints, timestamps, sandbox and network logs, rejected actions and tool calls, and the configuration needed to reproduce what happened. It also describes tamper-resistant logs with reliable timestamps covering agent trajectories, tool calls, user interactions, environment states, and security-control decisions.

Read that list as an auditor would. It is a description of an evidence record, not a monitoring wish list. The phrase “rejected actions” is the one that deserves a second look, because most logging programs record what happened and say nothing about what the agent tried to do and was stopped from doing. That second category is often where the near-miss lives.

The same principle applies to your own deployments, even if you never touch model weights. The equivalent artifacts for an enterprise are the prompts and instructions an agent received, the identity it acted under, the files and records it opened, the tools it called, and the policy decisions that allowed or denied each step. If those live in five different systems with five different retention settings, reconstruction becomes a forensic project instead of a query. A well-run audit log that captures human and agent activity in one place is the difference between those two outcomes.

There is a point about trust that gets lost in the technical detail. Evidence is only useful if someone else can rely on it. That is why the guidance emphasizes tamper resistance and reliable timestamps, and why the language of chain of custody belongs in the conversation. A log your own administrators can edit is a log opposing counsel will question.

The Gaps a CISO or CCO Should Notice

A voluntary document of roughly 14 pages cannot settle every operational question, and the commentary around it has been quick to say so. Four gaps stand out for a security or compliance leader.

No retention clock

The guidance says to preserve evidence to the extent necessary to investigate, but it names no period. For a frontier lab that may be a reasonable position, because the volume of weights and checkpoints is enormous and the right answer depends on the incident. For a regulated enterprise it leaves a hole. Your retention schedule for AI agent records is going to be set by sector rules, contract terms, and litigation exposure, not by this document. If your agent logs roll over every 30 days and a regulator asks about an event from 90 days ago, the guidance will not help you.

Capture versus rebuild

The Recover stage includes rebuilding from verified baselines and revoking credentials that were accessed during an incident. The Respond stage includes preserving evidence. Taken together, those two instructions can collide. If a team rebuilds a compromised environment before the evidence is captured and hashed, the rebuild itself destroys the record. The document says the practices apply throughout the lifecycle, but it does not spell out the order of operations, and ComplexDiscovery’s analysis suggests the safe pattern is to snapshot and hash before rebuilding. Put that sequence in your runbook in plain words. The middle of an incident is a bad time to discover that two good practices conflict.

Litigation is not mentioned

The document does not address legal holds. That is understandable given its audience, but it means a general counsel must supply the missing layer. Once an agent incident creates a reasonable prospect of litigation, preservation stops being a good engineering habit and becomes a legal duty. Your eDiscovery process needs to know that agent transcripts, tool-call logs, and policy decisions are discoverable records, and it needs to be able to place a hold on them without stopping the agent fleet.

Scoring near-misses is harder than naming them

The guidance calls for severity scoring and treats near-misses as triggers. Neither is simple. Severity scoring for an agent that nearly sent a sensitive file to the wrong destination requires a rubric your team has agreed on before the event. Without one, the first near-miss becomes an argument about whether it counts. The practical fix is to adopt a short severity scale now, with examples drawn from your own agent use cases, and to run a tabletop exercise on it.

The commentary has also noted that monitoring tools can introduce their own vulnerabilities and that identifying a rogue agent incident is hard in the first place. Those are fair cautions. They are also reasons to treat the guidance as a starting checklist rather than a program.

Why Deployers Face the Same Questions

Frontier labs and enterprises sit at different points on the risk curve, but the failure pattern rhymes. An agent is given a goal, a set of credentials, and access to data. Something about the task, the environment, or the model’s behavior causes it to act outside its brief. Someone then must explain to a board, a regulator, or a customer what happened.

Survey data suggests most organizations are not ready for that conversation. Schellman’s 2026 State of AI Governance report, based on 525 U.S. professionals at companies with 500 or more employees, found that only 22 percent have defined thresholds for when a human must review an agent’s work, according to the Schellman 2026 State of AI Governance whitepaper. A threshold is a precondition for a near-miss program. If nobody has defined what an agent is allowed to do alone, nobody can say when it has gone past that line.

Confidence about audits tells a similar story. Grant Thornton’s 2026 AI Impact Survey of 950 senior business leaders found that 78 percent lack strong confidence they could pass an independent AI governance audit within 90 days, as reported on the Grant Thornton survey page. Auditors do not ask whether you have a policy. They ask for the record. The federal guidance is, in effect, a statement from three agencies about what a credible record looks like when the actor is an AI agent.

Accountability is the third thread. A survey of executives and technical leaders by Gravitee, summarized in its State of AI Agent Security 2026 report, found that only about 7 percent have a named individual accountable for agent behavior. The figure is a self-reported vendor survey and should be read as directional, but the direction is clear. When an incident happens, the incident commander needs a counterpart on the business side who owns the agent’s purpose and permissions.

None of these three sources was measuring the federal guidance, and none of them proves that organizations will fail an AI incident. Together they suggest the preconditions for a good response (defined thresholds, audit-ready records, named owners) are missing at most enterprises. That is the real value of the guidance for a deployer. It gives you a neutral outside reference to point to when you ask for budget.

Turning the Guidance Into a Working Program

You do not need to adopt all 10 practices to benefit from them. A sensible approach is to translate the five stages into decisions your team can make this quarter.

Prepare by defining the actor and the blast radius

Begin with an inventory. List every AI agent in production or pilot, the identity it uses, the data it can reach, and the person who owns it. Then apply least privilege, which the guidance names directly. An agent that drafts customer summaries does not need write access to the contract repository. Strong access controls on the data itself, not just on the application the agent runs in, keep a misbehaving agent from becoming a data exposure event.

This is also where zero trust security principles earn their keep. Treat the agent as an actor that must be verified on every request, scoped to the task, and denied by default. The guidance’s call for shutdown mechanisms belongs here as well. If you cannot revoke an agent’s access in minutes, you do not have a shutdown mechanism, you have a hope.

Detect by watching the data, not only the model

The guidance says monitoring should cover systems, software interfaces, and networks, not only the model. For most enterprises, the most useful signal is data access. Which files did this agent open, how many, from which sources, and does that pattern match its purpose? Feeding those events into your SIEM gives the security operations team something concrete to alert on, and it avoids the trap of building a separate monitoring stack for agents that nobody staffs.

Respond by capturing first, then containing and rebuilding

Write the capture-before-rebuild order into the runbook. Snapshot the environment, export the logs, hash them, record who handled them, and only then revoke credentials and rebuild. Tie this to your risk assessment so the team knows which agents warrant a full forensic capture and which warrant a lighter touch. Not every incident deserves the same depth, but the decision should be made in advance, not during the event.

Recover by proving the fix before restarting

The guidance asks teams to confirm that monitoring, logging, access restrictions, and shutdown mechanisms work before restarting an agent. Make that a documented checklist with a named approver. This is the step that most often gets skipped under business pressure, because the agent is supporting a live process and everyone wants it back. A signed verification step is cheap insurance.

Report by deciding who hears what, and when

Reporting under the guidance is voluntary beyond whatever the law already requires, which means the enterprise decision is about which obligations apply to you. Sector rules, contract clauses, and state notification laws still govern. Decide in advance who talks to customers, who talks to regulators, and who decides whether to share with CISA or an industry group. Align this with the Govern function in NIST CSF 2.0, which expects leadership to own cybersecurity risk strategy and accountability, not delegate it to the SOC.

Where Data-Layer Governance Fits

It would be a stretch to say any single product satisfies this guidance. It does not certify anything, and no vendor can claim compliance with it. What an enterprise can do is look at the evidence the guidance asks for and ask which part of it can be produced consistently from one place.

Kiteworks secure data exchange approaches this from the data layer. Instead of relying on each application or agent framework to log its own behavior, the platform applies policy where sensitive content lives and records each access in a single set of audit logs. The data policy engine evaluates who or what is asking, what they are asking for, and whether policy allows it. The Secure MCP Server brings AI assistants and agents that connect through MCP under that same policy, so an agent’s access to sensitive content follows the same rules and leaves the same kind of record as a human user’s.

That design maps to two themes in the guidance without claiming to satisfy it. Limiting agent access to what a task needs is a policy decision enforced at the point of access. Preserving a usable record of agent activity is a byproduct of the same enforcement, because the allow and deny decisions are logged where the content sits. The result is an evidence trail a CCO can hand to an auditor and a CISO can query during an incident, built from the governance layer instead of reconstructed afterward.

This approach has limits worth stating plainly. Data-layer controls do not preserve model weights, training environments, or the internal reasoning of a model you run yourself. They address the question most enterprises actually face, which is what an agent did with the sensitive content it could reach. Organizations that train or fine-tune their own models will need additional capture mechanisms for those artifacts.

The same governance applies to human and agent access alike. Treating agents as a separate class with a separate rulebook creates the two-tier problem that audits tend to expose. A single AI data governance approach, where the rules attach to the data and the actor is simply another identity to be verified, is easier to explain and easier to defend.

A 90-Day Plan for Security and Compliance Leaders

Guidance that arrives without a deadline tends to wait. Here is a sequence that fits inside a quarter and does not need new budget to begin.

In the first 30 days, build the agent inventory and name an owner for each agent. Confirm which identities agents use and whether those identities are scoped to their tasks. Review the retention settings on every system that records agent activity and write down the shortest one. That number is your real retention period today, whatever your policy says.

In days 31 to 60, define a short severity scale for agent incidents and near-misses, with three or four examples drawn from your own use cases. Write the capture-before-rebuild sequence into the incident runbook, and involve legal so that legal hold procedures cover agent transcripts and tool-call logs. Decide who can shut an agent down and test that they can do it.

In days 61 to 90, run a tabletop exercise built around a near-miss. Pick a scenario where an agent retrieves content it should not have, or attempts an action that policy blocks. Walk the team through detection, evidence capture, scoping, and reporting. Time the exercise, record what was missing, and bring the gaps to the next risk committee meeting along with the survey evidence above. If the exercise exposes that you cannot reconstruct what the agent did, you have your budget case.

Keep the tone of the exercise practical. The point is not to find fault. It is to learn, before the real event, which records exist, who can reach them, and how long reconstruction takes. Teams that have done this once tend to find that the first hour of an incident goes far better the second time.

What to Watch Next

Three developments deserve attention. The first is whether the guidance grows beyond its short, general form. Commentators have already pointed out the missing retention guidance and the thin treatment of deployers, and a future revision could address either. The second is how sector regulators and auditors borrow from it. Voluntary federal practices often become the benchmark that assessors reach for when a standard does not yet exist, whether or not anyone intended that outcome. The third is how insurers respond. If underwriters start asking whether you preserve agent evidence, the guidance will have moved from optional to expected without any rule being written.

For now, treat the document as what it is, a credible outline from three agencies of what a defensible AI incident record looks like. It does not tell you what to buy or what retention period to choose. It does tell you which questions will be asked, and it gives you time to prepare answers.

See How Governed AI Access Works in Practice

If you want to see how Kiteworks secure data exchange enforces policy on agent and human access to sensitive content and records each access in one audit trail, schedule a custom demo today.

Additional Resources

• Blog Post
  Zero‑Trust Strategies for Affordable AI Privacy Protection
• Blog Post
  How 77% of Organizations Are Failing at AI Data Security
• eBook
  AI Governance Gap: Why 91% of Small Companies Are Playing Russian Roulette with Data Security in 2025
• Blog Post
  There’s No “–dangerously-skip-permissions” for Your Data
• Blog Post
  Regulators Are Done Asking Whether You Have an AI Policy. They Want Proof It Works.