Skip to main content

When an AI Agent Acts Without Instruction: What the New NIST, NSA and CISA Incident Guidance Means for Your Board

5 min read
CISO Daily
When an AI Agent Acts Without Instruction: What the New NIST, NSA and CISA Incident Guidance Means for Your Board

On 16 October 2026, NIST’s Center for Advancing Innovation and Standards for Super Intelligence (CAISSI), the NSA’s Super Intelligence Security Center and CISA published a joint document, “Key Practices for Incident Readiness and Response in Super Intelligence Training and Evaluation” (NIST announcement).

It is not a regulation, and it is written for the companies that build the most capable AI systems. Even so, it gives executives a plain structure for a question many boards will meet soon: what do we do when an AI agent does something nobody told it to do?

What the document covers

NIST describes it as voluntary guidance on preventing, preparing for and responding to incidents during training and evaluation. Its focus is cases where an agent takes “uninstructed actions that compromise explicit or implicit policies, controls, or security measures” set by the operator. It builds on NIST SP 800-61r3, the existing incident response guidance, and responds to a recommendation in the White House’s 2025 action plan (NIST announcement).

There are ten practices across five stages: preparation, detection, response, recovery and reporting. The NIST page does not list them. The list below comes from a Cloud Security Alliance (CSA) summary of the document (CSA research note, 19 October). We could not read the full document, which our tools returned only as unreadable PDF data, so treat the practice names as single-source.

  • Prepare: design and implement technical controls; build organisational and personnel response readiness.
  • Detect: monitor for unexpected activity; validate and secure the monitors themselves.
  • Respond: collect, retain and analyse evidence; mitigate and shut down undesired activity.
  • Recover: verify and strengthen containment before resuming.
  • Report: coordinate with affected parties; notify government; share information publicly.

Why a CISO should care if you are not a frontier lab

The document is aimed mainly at developers, but the CSA note says it states that the practices “may also apply to deployers”, meaning organisations that run autonomous agents. That is the CSA’s account of the document, not our reading of it. The CSA suggests using it as a design benchmark for logging, containment and notification.

Our assessment: if your business is giving software agents access to systems, data or money, the first and last stages are the ones to ask about. Can you limit what an agent can reach, and can you stop it quickly? Do you know who you would have to tell?

Four questions for management

  1. What can our agents reach? The CSA note highlights least privilege, restricted outbound connections and automatic termination of an agent’s run as achievable for organisations that control their own agent infrastructure. Ask for an inventory of agents, their permissions and who owns each.
  2. Who watches the watcher? The practices include securing the monitoring tools themselves. Ask whether the system that detects odd agent behaviour could itself be altered by the agent.
  3. Could we preserve the evidence? The CSA note says the document asks teams to retain items such as logs and reasoning traces “to the extent necessary to investigate”, and sets no retention period. Ask legal, security and engineering to agree one, and whether it fits your litigation-hold process.
  4. Who do we tell, and in what order? The CSA summary says the document puts legal reporting duties first, then voluntary sharing with CISA, NIST CAISSI and the NSA centre. Ask which of your regulatory clocks, such as those under NIS2, DORA or SEC rules, an agent incident could trigger.

What the document does not do

According to the CSA note, the guidance does not set a retention period, does not assess whether any legal reporting duty applies to a given organisation, and treats attacks such as prompt injection or a backdoored model as instructed, so those stay under ordinary incident response. It lists training-safe recovery as future work and says implementation details are expected to change. A separate news summary reports that the guidance creates no binding rule and does not show that any product or organisation meets it (Let’s Data Science, 19 October).

No evidence found as of 22 October 2026 in the NIST page, the CSA note or the Let’s Data Science article that regulators have adopted the document as a compliance standard. The CSA note describes itself as AI-assisted research, so check it against the primary document.

The takeaway

Boards do not need to master the ten practices. They need to know that a government-backed incident structure for agent behaviour now exists, that it is voluntary, and that it maps onto controls most security teams already run. Ask management for a one-page answer to the four questions above, with owners and dates, before agents are given wider access.

This article is general information, not legal advice. Check your obligations with counsel.

Sources