Can CMMC Save Us from Artificial Intelligence Killing Us All?

Did you just finish doomscrolling to learn how state based actors and criminal actors use AI to “hack” everything? What if I told you some common sense controls may have prevented almost every attack highlighted in the September 2026 threat intelligence report by Anthropic?

An attacker should not gain access to your company’s engineering knowledge simply because an employee connects a laptop to hotel Wi-Fi or loses control of an email account. Those events should meet several barriers before they become a business-threatening loss.

AI did not hack these devices. Stupidity allowed the exfiltration. You do not travel with sensitive IP to a hotel, and you do not connect a device containing sensitive IP or Controlled Unclassified Information to public wifi. Ever.

While NIST-SP-800-171 only protects the confidentiality of CUI, you can use the requirements to protect your sensitive intellectual property. Furthermore, many of the controls you design for 171 will have a halo effect on availability and integrity.

NIST-SP 800-171 has practical value.. Its requirements give organizations a foundation for controlling information, restricting access, hardening devices, and responding when something goes wrong. Applied well, those safeguards can prevent some attack steps and limit the damage from others.

In its September 2026 threat intelligence report, Anthropic describes AI-assisted cyber operations involving stolen credentials, exposed API keys, vulnerable services, malicious downloads, and bulk data theft. In one espionage case, attackers compromised hospitality vendors, changed DNS records, and used hotel Wi-Fi redirection to deliver malicious lures. They also stole drone manufacturers’ mailboxes and a proprietary vision-system software development kit. Other cases involved exposed secrets and compromised software providers that opened paths into customer environments. AI helped attackers automate and accelerate their work.

Every single one of these attacks could be prevented and Artificial Intelligence had nothing to do with it.

Now we only have access to reported observations. Nobody performed controlled pentests of NIST implementations. We cannot calculate how many incidents 171 would have prevented. We can identify specific opportunities to interrupt the cyberattacks and explain what effective implementation would look like.

These attacks were caused by stupidity and the rush to GSD, not frontier models.

Control Information Worth Stealing

Before selecting another security product, ask where your sensitive information lives. Can someone find the entire product design in ordinary email attachments? Does every engineer have access to every project? Can an account export a complete repository without additional restrictions? Do employees synchronize sensitive files onto every device they use?

For a small manufacturer, like the drone makers in Ukraine, I would begin with a simple information map: what needs protection, who needs it, which systems may hold it, and where it may travel. That map should drive the permissions and technical restrictions.

(It never gets to travel to a hotel without authorization, and if so the device can NEVER connect to public wifi)

The relevant Rev. 2 requirements include:

• 3.1.1 and 3.1.2 Restrict access to authorized identities and permitted functions.

• 3.1.3 Enforce authorized flows of CUI.

• 3.1.5 Apply least privilege.

• 3.13.16 Protect CUI at rest.

• 3.1.19 Encrypt CUI on mobile devices and computing platforms.

Keep sensitive engineering files in an approved, restricted repository and use authenticated sharing links. Keep data out of email. It would limit exports, restrict external sharing, and use data-loss prevention where the available technology supports the required restrictions. A project engineer would receive access to the projects they support. Routine email access would not automatically confer access to the complete design library.

A sharing link only helps if the repository independently enforces access. Anonymous links or broad permissions can recreate the same exposure. Likewise, encryption at rest does not prevent an attacker from reading files through a compromised, authorized session.

Make public Wi-Fi an Authorization Decision

Many cybersecurity experts bemoan the calls to stay off Public wifi, but attack after attack such as “Dark Hotel” demonstrates that public wifi connections can breach your devices.

The Anthropic report raises a straightforward question: why should a device used for sensitive work connect to a network that the company has not approved?

Under NIST-SP-800-171 this would not happen. 3.1.16 addresses wireless authorization, 3.1.17 addresses wireless authentication and encryption, and 3.1.20 addresses external-system connections and use. Rev. 2 does not impose a universal public-Wi-Fi ban. A company can adopt that restriction as part of its implementation. NIST SP 800-171 Rev. 2 . If your computer holds the spec to your drone vision system, do not allow public wifi. Large language models had nothing to do with the exfiltration. It was caused by shitty data protection policies.

For a small defense supplier whose employees travel with access to sensitive designs, I would recommend prohibiting hotel, airport, and café Wi-Fi on those work devices. Provide an approved cellular connection, disable automatic connections to unknown networks, and enforce restrictions through device configuration. Where an exception is necessary, define who approves it and what protections must operate before work begins.

The enforcement details matter. An approved network name alone does not prove that an access point is authentic. Test whether employees can add another network, override the restriction, or connect before management controls apply.

Avoiding hotel Wi-Fi removes that particular exposure for a traveler who follows the rule. It does not protect a vendor’s infrastructure or prevent a phishing message delivered over cellular service. The organization still needs endpoint and identity protections.

If you do travel with a device do a factory reset when you get home, before connecting to your house or office network. If you travel in high risk countries bring a burner device and leave it before returning home.

Protect the Session as Well as the Password

Anthropic also describes device-code phishing and token theft. Those techniques make “we have MFA” an incomplete answer: the attacker may obtain usable access through a legitimate authentication process rather than simply guess a password. Anthropic’s report

3.5.3 requires MFA for the specified account access, while 3.13.15 addresses communications-session authenticity. NIST SP 800-171 Rev. 2

I would implement phishing-resistant MFA where supported, restrict device enrollment, review application permissions, and require approved devices for sensitive access where the service supports that enforcement. Those measures address different opportunities for account abuse; none makes an already compromised device trustworthy.

If you use phishing-resistant MFA on managed devices, you stop all AITM token thefts. The AI did nothing special. These attacks could be prevented.

Device-code phishing deserves a specific decision. Microsoft recommends blocking device-code flow as broadly as possible and retaining only documented, secured exceptions. Organizations can first audit usage and test the restriction before enforcing it. This is a concrete example of translating an access-control objective into a configuration that addresses the observed technique. Microsoft’s Conditional Access guidance

A password reset also needs a response procedure around it. Investigators should examine active sessions, application grants, newly enrolled devices, and other persistence mechanisms instead of assuming that a new password ends the intrusion.

Stop the RMM Hacks

A user who encounters a fake troubleshooting page should have two opportunities to stop: recognize the deception, then encounter a technical restriction if they attempt to follow it.

NIST-SP-800-171 requirements for 3.2.1–3.2.2 for awareness and training, 3.4.7 for restricting nonessential functionality, 3.4.8 for software execution policy, and 3.4.9 for user-installed software could all prevent Remote management hacks.

According to Huntress RMM attacks grow in frequency. For this threat, training should use concrete examples: a Wi-Fi portal asking someone to paste a command, a document viewer demanding a security change, or an unexpected update requesting software installation. Give employees a clear action: stop, close the page, and contact the designated support person through a known channel.

My technical preference would be application allowlisting, denying non-essential functions so you have restrictions on unnecessary script interpreters, and separate administrative accounts. Rev. 2 permits different execution-policy approaches. Use allowlisting and deny by default. Test the policy against misuse of approved tools as well as unknown executables. An attacker may use an existing interpreter, and malware may run with ordinary user permissions.

A company gains more protection when training and configuration support each other. Employees should not need administrator rights to complete routine work, and a fake repair should not gain those rights simply by asking.

Close Exposed Services and Protect Secrets

Under 3.11.2–3.11.3 you need to address vulnerability scanning and remediation. 3.14.1 requires a company to addresses timely flaw correction. 3.4.6–3.4.7 supports reducing unnecessary functionality

For implementation, inventory internet-facing services and assign someone to act on relevant advisories. All external connections get identified under NIST-SP-800-171. Include network appliances and externally hosted applications in the review. Relying on Defender or another endpoint scanning agent cannot establish the condition of every service your business uses. Verify remediation, and restrict or remove an exposed service when a timely fix is unavailable.

Treat API keys and service credentials as access to production systems. My recommended safeguards include secret scanning before publication, managed secret storage, narrowly scoped credentials, and prompt revocation after exposure. Removing a secret from the latest version of a repository does not invalidate copies that someone already obtained.

Apply the same discipline to company AI integrations. Give an assistant only the information, tools, and permissions its task needs. Keep production secrets out of environments that do not need them. NIST’s general access-control principles help constrain the consequences of misuse, but implementing Rev. 2 does not by itself solve prompt injection or every AI-specific vulnerability.

Limit What a Compromised Provider Can Reach

A supplier relationship should have an explicit access boundary. For every integration, ask which accounts, files, mailboxes, and administrative functions the provider can reach. Decide how to revoke that access and who can do it during an incident.

I would use scoped application permissions, separate service identities, restricted administrative access, and periodic reviews of unused integrations. A tool with a narrow business purpose should receive permissions that match that purpose. A provider’s security assessment can inform the decision, but it cannot make an unnecessarily broad permission safe.

These are practical applications of 3.1.5 and 3.1.20. Document the connections and responsibility boundaries in the system security plan under 3.12.4. CMMC Level 2 Assessment Guide

Detect Theft and Rehearse Containment

Prevention can fail. The business needs a way to recognize suspicious access before an attacker finishes collecting everything the account can reach.

3.3.1, 3.3.3, and 3.3.5 support audit records, review, and correlation. 3.14.6–3.14.7 address attack monitoring and unauthorized use. 3.6.1–3.6.2 address incident handling, tracking, and reporting. CMMC Level 2 Assessment Guide

I would prioritize alerts for unusual mailbox access, bulk repository downloads, unexpected forwarding, new application grants, and unapproved device enrollment. Include changes that disable security tools or interrupt updates. Assign each alert an owner and a response expectation appropriate to the risk. All of the attacks Anthropic noted should have gotten flagged. None of the methods relied on novelty.

Then rehearse a scenario: an employee reports a suspicious hotel login page, and monitoring shows unusual cloud access. Can the responsible person isolate the device, revoke access, investigate affected information, and coordinate with the provider? Can they do it after hours? Logging becomes useful protection when someone can act on it.

Turn Requirements into Barriers

For a small manufacturer, the first priorities are concrete: control sensitive information, restrict travel connectivity, protect identities, constrain software execution, and prepare to contain a compromised account or device.

An assessment result cannot establish that every attack will fail. Effective implementation can remove easy entry points, reduce what one compromised identity exposes, and give defenders a chance to interrupt theft. The value of NIST SP 800-171 appears in those operational decisions especially when the attacker works faster than the company can afford to respond manually.

That is all AI, and Large Language Models did. They took advantage of poorly designed systems. All of this, with some security engineer could be prevented.

Image credit: “Attack!” flickr photo by Masked Builder flickr.com/photos/ma… shared under a Creative Commons (BY 2.0) license