The National Institute of Standards and Technology is quietly building something that could shape how every company secures its AI deployments: a set of cybersecurity controls written specifically for AI systems, rather than borrowed from the general IT playbook. According to reporting from GovCIO Media & Research, the agency is working on tailored controls that acknowledge something practitioners have complained about for two years—that conventional security frameworks don’t map cleanly onto models, training pipelines, and the sprawling supply chains behind them.
This matters more than a typical standards update. For most of the AI boom, security teams have done what they always do with a new technology: stretched existing controls until they sort of fit. A large language model gets treated like a web application. A training pipeline gets lumped in with any other data workload. A model file gets dropped into a registry the same way you’d store a container image. None of that is wrong exactly, but none of it addresses what makes AI different, and the gaps keep showing up in incident reports.
The core problem is that AI systems have an attack surface that traditional controls were never designed to see. Training data can be poisoned in ways that are nearly invisible until a model behaves strangely in production. Model weights themselves are valuable and stealable, and a compromised model file is a very different artifact than a compromised binary. Prompts and outputs create a whole channel for manipulation that has no real analogue in conventional software. Then there’s the supply chain: open-weight models pulled from repositories, third-party APIs, fine-tuning services, and datasets of uncertain provenance, all layered together. Securing that stack with a checklist built for servers and endpoints is like inspecting a house by looking only at the front door.
NIST’s move to write AI-specific controls is an implicit admission that the stretch job has limits. The agency has already done foundational work in this space through its AI Risk Management Framework, which laid out a vocabulary for thinking about AI risk across design, development, and use. But a risk framework is not a control catalog. It tells you what to worry about; it doesn’t tell you which configuration settings, logging requirements, or access restrictions actually mitigate the worry. That’s the gap the tailored controls appear designed to close.
The timing is hard to ignore. The past year has brought a run of AI-enabled security incidents and research findings that have rattled confidence—critical vulnerabilities in widely used software, reports of AI-assisted exploitation, and a steady drumbeat of research showing that models can be manipulated in ways defenders struggle to detect. Security vendors, meanwhile, have rushed to market with AI security products, some genuinely useful and some repackaged monitoring tools with new labels. A credible set of government-authored controls would give buyers a reference point, and it would give auditors something to check against. That’s precisely why the details will be fought over.
There’s a balance NIST has to strike, and it’s not an easy one. Controls that are too generic will be dismissed as reheated IT guidance. Controls that are too prescriptive risk being obsolete before they’re published, given how fast model architectures and deployment patterns change. The agency has signaled it wants something adaptable, organized around functions rather than specific products, which is the sensible path but also the harder one to write. Anyone who has watched standards bodies try to keep pace with fast-moving technology knows the failure mode: the document arrives, everyone nods, and the actual practices have already moved on.
For enterprises, the practical question is what to do in the meantime. Most security leaders aren’t waiting for federal guidance, and the savvier ones are already treating AI systems as a distinct category in their risk registers—mapping where models come from, what data touched them, who can query them, and what happens when they misbehave. That work is worth doing regardless of what NIST eventually publishes, because it forces teams to answer questions that generic frameworks let them skip. The tailored controls, when they land, will likely formalize much of what mature practitioners have already concluded on their own.
What’s genuinely notable here is the shift in posture. Governments spent the first phase of the AI era writing principles and voluntary commitments. Tailored cybersecurity controls are a different kind of document—closer to engineering than to ethics, and harder to satisfy with a press release. If NIST gets it right, it could become the reference framework that both vendors and buyers quietly converge on, the way earlier control catalogs became the lingua franca of enterprise security. If it gets it wrong, it becomes one more PDF in a folder nobody opens. Either way, the fact that the work is happening tells you something about where the industry is: past the novelty phase, into the part where things have to actually be defended.