If I had to pick one CMMC control that catches more small defense contractors off guard than any other, it would be NIST 800-171 §3.1.20.

It is short. It is plain English. And almost every shop I walk into is failing it without realizing.

What the control says

NIST SP 800-171 §3.1.20: "Verify and control/limit connections to and use of external systems."

That is the whole requirement. Six determination statements unpack it:

  • Connections to external systems are identified.
  • Use of external systems is identified.
  • Connections to external systems are verified.
  • Use of external systems is verified.
  • Connections to external systems are controlled or limited.
  • Use of external systems is controlled or limited.

"External system" is defined broadly. It is any system outside your organization's authorization boundary that your people or your systems connect to. Cloud services, partner networks, employee personal devices, vendor portals, AI tools you did not deploy yourself. All of it.

The companion control, §3.1.21, narrows in on portable storage on those external systems. Same idea, smaller surface.

Why it catches everyone

Most contractors read 3.1.20 as a network rule. It is not. It is a behavior rule.

Your people use external systems all day. The control says you must know which ones, verify they are appropriate for the data flowing into them, and put limits in place. Without that, every laptop in your shop is a potential CUI leak point and you have no documented control over it.

Here are the everyday patterns I see in defense shops:

  • Personal cloud storage. Someone uploaded a contract document to their personal Dropbox or Google Drive "just to print it at home." That account is an external system. It is now in scope.
  • Personal email forwarding. A PM forwards a thread with FOUO markings to their Gmail to read on a trip or commute. External system. In scope.
  • AI tools. An estimator pastes proposal text into ChatGPT or Copilot Pro for a quick rewrite. If that text contained CUI, the AI vendor is now an external system that processed it.
  • Subcontractor and prime portals. Your team logs into the prime's portal to download drawings, then saves a local copy. The portal is in scope as a connection. The local copy is in scope as data flow.
  • Vendor remote support. An ERP consultant connects in through TeamViewer or AnyDesk to debug a problem. Their machine is an external system reaching into yours.
  • Bring-your-own-device. The owner's iPad has the company email account on it. The iPad is an external system. So is the home Wi-Fi it sits on.

None of these are exotic. All of them happen weekly in a 20-person defense shop.

What "verify and control/limit" actually means

To pass an assessment on 3.1.20, you need to be able to show three things:

  1. An inventory of approved external systems. Mail, file storage, AI tools, portals, remote support tools, BYOD. With CUI handling notes for each.
  2. Agreements or rules of behavior for each one. Either contractual (an MSA, a CSP terms page, a portal access agreement) or internal (an Acceptable Use Policy that names the system and what people can and cannot do with it).
  3. Technical controls that enforce those limits. Conditional access. DLP rules that block CUI from leaving. Browser policies. MDM. Block-by-default categories like personal email and consumer file sharing.

If the answer to "show me your external systems list" is a shrug, you do not have 3.1.20.

The trap with AI tools specifically

This deserves its own paragraph because it is the fastest-moving risk in 2026.

Every member of your team has access to general-purpose AI now. ChatGPT. Claude. Copilot. Gemini. Most of them treat it like a smarter Google. They paste in emails, contracts, drawings, proposal sections, and ask the model to clean it up.

The moment CUI hits a non-equivalent AI vendor, you have a 3.1.20 finding and likely a 7012 incident. Some of those vendors retain prompts. Some train on them. Most do not give you a Body of Evidence.

You need a deliberate answer to "where can my team use AI, and where can they not." Saying nothing is not the answer.

How we built Tentacle Ops around this control

Tentacle Ops itself is exactly the kind of tool 3.1.20 is asking you to scrutinize. Any ops automation vendor reaching into your environment is a candidate external system. So we designed around the control rather than against it:

  • Per-customer isolated stack. Each customer gets a dedicated instance. No shared multi-tenant control plane reaching across customers.
  • The agent works inside your boundary. Tentacle Ops operates within the customer's existing CUI enclave (GCC High, on-prem, or hybrid). It does not pull CUI back into a Tentacle Ops cloud.
  • Documented interfaces. Every connection the agent makes is named, scoped, and logged so it can be added to your external systems inventory cleanly.

The point is not that Tentacle Ops gets you to 3.1.20 by itself. The point is that we should be one of the easiest external systems on your list to document, not one of the hardest.

What to do this week

  1. List every external system your team uses to touch CUI or FCI: cloud storage, mail, ERP portals, prime portals, AI tools, remote support tools, BYOD.
  2. For each, decide: approved, prohibited, or conditional. Write it down.
  3. Update your AUP and have everyone re-sign. Add AI tools by name.
  4. Where you can, enforce technically: conditional access, DLP, browser policy, MDM.
  5. Put the inventory in your SSP. Review quarterly.

3.1.20 is not a network control. It is a control over what your people are allowed to do with the data they were trusted with.

Most contractors fail it because they have never written that down.

Tentacle Ops is an autonomous operations agent built for CMMC-bound manufacturers. Learn more at tentacleops.ai.