AI Security and Governance for Defense Contractors Means More Than Blocking AI

Most DIB organizations reach for the same first move when AI comes up. Block it. Lock down the network, ban the apps, tell staff to stay away from anything with a chat window. With CUI, export control, and data confidentiality obligations already on the table, that instinct makes sense.

It also doesn’t hold up. AI tools are already accessible from a phone in someone’s pocket, and a policy built entirely around prohibition tends to produce shadow use instead of compliance. The organizations getting this right aren’t blocking AI. They’re governing it.

The Instinct to Block AI Entirely

It’s easy to see why a full block feels like the safe answer. Many public and consumer AI tools function as data pipelines to systems outside your organization’s security boundary. For an organization already managing CUI, FCI, and export-controlled information, sending protected data into an unapproved AI service creates a real and immediate risk, not a hypothetical one.

There’s also no single AI-specific control family in NIST SP 800-171. Most CMMC-focused organizations have spent years building policy around established security requirements, and AI introduces new ways those requirements can be tested. Access control, information flow, system use, incident response, and data protection requirements still apply when an AI tool processes, stores, or transmits CUI. A blanket block can feel like the simplest defensible position while organizations determine how to apply those requirements to a fast-moving category of technology.

That instinct isn’t wrong. It’s just incomplete. A block is a starting point, not an end state.

Why Just Block It Doesn’t Hold

Brian Drake, CTO at Accrete AI and former Director of AI at the Defense Intelligence Agency, on The Watchers, Episode 47.

Brian Drake, who served as the Defense Intelligence Agency’s first Director of Artificial Intelligence and drafted the agency’s AI strategy before moving into the private sector, makes this point directly in the clip above.

His argument, and it’s one worth taking seriously if you’re the one writing the policy, is that technology adoption doesn’t reverse once it’s already in people’s hands. You can constrain how something gets used. You can’t fully undo the fact that it exists and that people already know how to reach it. Applied to AI in a DIB environment, that means a hard ban tends to last exactly until an employee needs to get something done quickly and finds a way around it, usually with a personal device and a public tool that has none of your organization’s controls attached to it. At that point you have less visibility into AI use, not more.

For more conversations like this, subscribe to Sentinel Blue on YouTube.

What Governance Looks Like Instead of a Ban

The goal isn’t to stop AI use. It’s to define, clearly and in writing, which AI tools are approved for each data classification, under what conditions they may process that data, and what security, contractual, and handling requirements must be satisfied first.

A workable acceptable-use policy for a DIB environment usually needs to answer a few direct questions:

• Which data classifications are off-limits to public, consumer-facing AI tools entirely?
• What approved AI tools, if any, are sanctioned for lower-sensitivity data, and what technical and contractual conditions apply to their use?
• Who reviews and approves a new AI tool request before an employee starts using it?
• What happens when someone violates the policy, and how is that different from a data spill under existing incident response procedures?

None of this replaces your existing NIST SP 800-171 requirements. It sits alongside them. CMMC does not create an AI-specific control set, but the requirements that govern access, information flow, system use, incident response, and protection of CUI still apply when AI tools enter the environment. AI governance gives employees and control owners a practical way to apply those requirements consistently to tools that were not part of most security programs a few years ago.

Where AI Actually Creates Risk in a CMMC Environment

The most common risk isn’t a sophisticated attack. It’s an employee copying a paragraph of CUI into a public AI tool because it’s faster than doing the work manually and no sanctioned alternative exists. That’s shadow AI, and it’s functionally the same risk as shadow IT has always been, just with a much lower bar to start using it.

There’s also a data handling and residency question that does not have a single answer for every tool. Depending on the provider, product tier, account type, and contractual terms, submitted information may be retained, processed outside your approved environment, or handled under terms that do not meet your CUI or export-control requirements. For an organization tracking how CUI is processed, stored, and transmitted as part of an 800-171 or CMMC assessment, that is not a minor detail.

This isn’t a distant, hypothetical problem. Large language models are already being deployed in controlled and classified U.S. government environments.

The technology is operational today, not years away, which means the governance conversation is overdue rather than premature.

Building an AI Governance Policy Without Slowing the Business Down

A functional AI governance policy doesn’t need to be exhaustive to be effective. It needs to give people clear answers to the questions they’ll actually ask. NIST’s AI Risk Management Framework and Generative AI Profile can also provide a useful governance layer alongside the cybersecurity requirements that already apply to CUI.

• Maintain an approved-tool list, reviewed on a set cadence, so employees know what’s sanctioned without having to ask each time.
• Tie AI use restrictions to your existing data classification scheme instead of writing a separate one from scratch.
• Train staff on what CUI and FCI look like in practice, not just in policy language, so the restriction is something people can actually apply.
• Revisit the policy on a regular cycle. AI tooling changes fast enough that a policy written a year ago may already be missing tools your staff are using today.

This is exactly the kind of work that fits naturally into an existing cybersecurity program rather than becoming a standalone initiative. If your organization already has a vCISO or a strategy and maturity program in place, AI governance is a natural extension of that work, not a new department.