Ask an organization whether it has an AI security plan and the answer may include a model inventory, a chatbot for analysts, a warning about deepfakes and a slide about responsible innovation. Those items belong in the same meeting only if somebody can say which problem each is meant to solve. NIST's August 2026 Cyber AI Profile workshop report supplies a useful separation: protecting AI systems, using AI to defend other systems, and confronting attackers who use AI.
The report records discussion from an April 2025 workshop. NIST is working toward a community profile built around the Cybersecurity Framework. Workshop participants raised governance, supply chain, provenance, incident response and measurement questions. This document is not a final standard. It explicitly says the summarized takeaways are not formal recommendations. Treating a participant's suggestion as a mandate would corrupt the very evidence chain the profile is meant to improve.
Job one: protect the AI system itself
An AI application is a system with components: data sources, models, prompts, APIs, credentials, connectors, deployment infrastructure and people allowed to change them. It has suppliers and update paths. A public-facing agent that reads external documents has an attack surface different from a sealed classifier operating on curated inputs. In the workshop's first focus area, the practical task is to identify these dependencies and defend the boundaries between them.
That may mean tracing the origin of a model and its libraries, checking whether input data can be poisoned, limiting what an agent may call, and ensuring incident responders can reconstruct which version produced a decision. A generic “we monitor AI” line is not evidence of any of those controls. The test is whether the organization can name an owner, show a dependency record and demonstrate that an untrusted input cannot quietly become privileged instruction or authorized output.
Job two: measure AI used for defense
An AI tool may summarize logs, rank alerts or draft an incident timeline. It can make analysts faster, but its performance is a measured claim, not a product adjective. Workshop participants called out the lack of standardized benchmarks and the cost of false positives and false negatives. A detector that sounds brilliant in a demonstration may bury an analyst in noise. One that rarely interrupts anyone may simply fail to find the incidents that matter.
Before claiming a security win, a team should specify the task, its comparison point and the error that is expensive. How many true incidents were detected at a given alert burden? How quickly did investigators reach the original evidence? Did automation preserve a human ability to reverse or explain its action? Those are proposed evaluation questions drawn from the workshop's measurement concerns. The report does not publish a universal score for AI security tools, and we should not invent one.
Different organizations can reasonably choose different tradeoffs. A hospital, a small manufacturing shop and a cloud provider will face different consequences from a missed event or an unnecessary shutdown. That is why a modular profile could be useful if it gives teams common terms while leaving room for sector-specific risk.
Job three: understand hostile use without making AI a magic word
Attackers can use AI to scale convincing social engineering, process stolen data or adapt malicious content. Some attacks against AI systems also use prompt injection or poisoning. The workshop discusses both, and the distinction matters. An AI-assisted phishing campaign is an adversary using a tool against people; prompt injection is an adversary attempting to redirect an AI system through material it consumes. The defenders, evidence and containment measures differ.
Participants warned that many hostile uses amplify familiar crimes instead of creating an entirely new physics of attack. A faster email scam remains a scam; the changed variables may be production cost, personalization and reach. A useful security report should state which variable shifted. Counting every phishing message as proof of a new autonomous threat would make trend data worse.
The incident report is the stress test
A plan that looks tidy in a governance document should survive a deliberately awkward incident exercise. Suppose a defensive AI system recommends isolating a production service based on a cluster of unusual log entries. What evidence was in its context, and can an analyst find it without trusting the summary? Did the system have permission to isolate the service itself, or only to recommend action? If a later review finds that a poisoned log field shaped the recommendation, can the team identify every downstream decision that used it?
The same exercise exposes a supplier problem. A model or data pipeline may be operated by a third party, while the affected organization's responders hold only the application logs. If contracts do not provide version history, event retention and a route to emergency support, a nominal incident plan can stop at the organizational boundary. Workshop participants' emphasis on supply chain provenance is therefore more than a procurement slogan: it changes whether investigators can reconstruct an event.
We would also want the organization to repeat the exercise without AI assistance and compare outcomes. If the tool saves minutes but increases unsupported confidence, the trade is not automatically favorable. If it improves triage while retaining a reviewable evidence trail, that is an actual operational claim. NIST's workshop did not run these comparisons for everyone. It supplied the categories that let a team design its own test.
Governance has to connect the lanes
NIST's workshop also heard calls for multidisciplinary ownership. Legal and procurement staff can affect the terms under which data enters a model; security staff may hold the logs; engineers can define connector permissions; investigators need provenance when something goes wrong. No single team sees the whole failure path automatically.
The three lanes can share an inventory and incident process, but each needs a different test. For an AI application: can its dependencies and authority be mapped? For a defensive tool: does it improve a defined task against a baseline without unacceptable errors? For hostile AI use: what changed in an actual attacker's capability, and what evidence distinguishes that change from ordinary automation? If the plan cannot answer those questions, it may be a branding exercise with a firewall somewhere in the background.
The missing piece is real-world evaluation. The workshop records priorities and concerns, not settled performance or a completed profile. NIST still has to turn community input into usable guidance, and organizations still have to test it in their environments. Until then, the honest approach is to separate the three jobs and keep the receipts for each.
Combining the three areas in one vague AI-security program can obscure which control or outcome is being tested. The workshop summary is not a final community profile or measured evidence that any proposed practice works.