Systems engineering
Teams ask assistants about requirements, interfaces and designs. Fragments can still constitute controlled technical information.
Engineers paste controlled technical data into AI coding tools. Programme managers share CUI with AI assistants. Cleared personnel use unsanctioned AI for briefing prep. Your CMMC boundary does not cover these tools. A DNS log audit finds them.
Sample report
View all 11 pages
Opens in your browser · PDF
Defense contractors handle controlled unclassified information, ITAR-regulated technical data and classified programme details. Every unsanctioned AI tool creates CMMC violations, ITAR breaches and the risk of controlled data reaching adversary-accessible systems.
Engineers paste weapons system specs, avionics parameters and munitions data into AI tools. ITAR-controlled technical data reaching a commercial AI server constitutes a deemed export violation.
Programme managers share controlled unclassified information with AI assistants for briefing prep and report drafting. CUI leaves your CMMC boundary and enters systems without NIST 800-171 controls.
Systems engineers use AI to review requirements, generate test procedures and analyse architecture docs. Programme-of-record data and system vulnerabilities reach external AI platforms.
Business development teams paste RFP responses, cost proposals and technical approaches into AI for polishing. Proprietary pricing, teaming arrangements and programme strategy leak through AI sessions.
Embedded software teams paste mission-critical code into AI coding assistants. Weapon system firmware, avionics code and encryption implementations reach commercial AI servers.
Procurement staff share supplier capabilities, sole-source justifications and DFARS flow-down data with AI tools. Defence industrial base information leaks to potentially adversary-accessible AI platforms.
| Requirement | Source | Shadow AI Risk | What the Audit Produces |
|---|---|---|---|
| ITAR / EAR Controls | 22 CFR 120-130 / 15 CFR 730-774 | Technical data in AI = deemed export to server jurisdiction | AI tools mapped to hosting jurisdiction |
| CMMC Level 2+ | DFARS 252.204-7021 | CUI in AI tools outside CMMC boundary | AI services for CMMC boundary assessment |
| NIST 800-171 | DFARS 252.204-7012 | AI tools lack required security controls for CUI | AI tools flagged against 110 NIST controls |
| Insider Threat | NISPOM / 32 CFR 117 | AI tools as unmonitored data exfiltration channels | AI usage patterns for insider threat assessment |
| Supply Chain Risk | DFARS 252.204-7018 | AI vendors may use prohibited components (SCRM) | AI vendor origin and infrastructure assessment |
| Classified Spillage | DoD Manual 5200.01 | Classified data in AI constitutes spillage incident | AI tools in classified-adjacent network segments |
Sample excerpt from a shadow AI audit of a mid-tier defense contractor (2,000 employees, CMMC Level 2).
AI adoption rarely begins as a formal platform project. It begins when a person finds a faster way to finish a familiar task. For engineers, program teams, analysts, suppliers, field staff and corporate functions, that convenience can put CUI, controlled technical information, designs, mission details, source code and supply-chain records into services the organization has not assessed.
Teams ask assistants about requirements, interfaces and designs. Fragments can still constitute controlled technical information.
Code assistants receive mission logic, vulnerabilities, libraries and comments that identify a protected program.
Staff summarize schedules, risks and customer correspondence containing sensitive performance information.
Buyers and quality teams process drawings, supplier issues and part data subject to flow-down obligations.
Proposal teams use AI on requirements and solution text before release or award, exposing competitive and government information.
Personnel troubleshoot equipment through mobile tools where location, configuration and operational context can be revealed.
A useful program does more than count domains. It connects observed use to data, purpose, identity and vendor terms. That context lets security, export control, program leadership, legal, contracts and counterintelligence choose a proportionate action and explain it later.
| Question | Why it matters | Practical outcome |
|---|---|---|
| Is the tool approved? | Approval confirms that ownership, terms and intended use were reviewed. A familiar brand is not evidence that the account or feature in use is sanctioned. | Label the service approved, restricted, under review or blocked. Record the account tier and approved purpose, not only the vendor name. |
| What data could reach it? | The same assistant can be low risk for public research and high risk for CUI, controlled technical information, designs, mission details, source code and supply-chain records. | Define prompt examples by data class. Give users concrete red lines and a safe route for the useful workflow. |
| What do the terms say? | Training, retention, subprocessors, location, deletion and administrative controls vary by plan and can change over time. | Capture a dated vendor decision. Recheck material services on renewal and whenever the report shows a new domain or product. |
| Who is using it? | Ten hits from one lab, practice or branch call for a different response than ten hits spread across public-research roles. | Start with the highest-risk identity cluster. Ask about the task before deciding whether to coach, migrate, investigate or block. |
| Does an existing tool cover the need? | Shadow adoption often signals that an approved platform is unavailable, difficult to use or poorly communicated. | Remove friction, publish the approved route and measure whether users migrate during the next comparable audit window. |
The strongest first audit is narrow enough to explain and repeat. Use a normal operating period, preserve the source details and state the limits of DNS or proxy evidence in the report.
Start with 14 to 30 days that avoid a shutdown, migration or major outage. Record the dates, networks, identity coverage and exclusions. That scope statement makes comparisons honest and prevents a partial export from being mistaken for an enterprise census.
From approved-network DNS, boundary gateways, contractor access, VDI and managed endpoint telemetry, retain timestamp, hostname, action and the most useful identity field available. Do not add URL paths, request bodies or prompt content. Inventory work needs enough attribution to act, not the maximum amount of personal data.
Remove known test traffic, shared resolvers and infrastructure identities before interpreting user counts. Look for repeated use over several days and clusters within a team. A single lookup may be an email link or background process; a stable pattern deserves a conversation.
Meet the relevant team with neutral questions: what task is being completed, what information is entered, which account tier is used and why the approved route does not work. Document the answer beside the technical observation so reviewers can distinguish evidence from inference.
Block services built for abuse or those with unacceptable terms. Migrate useful work to an enterprise product when controls can make it safe. Coach occasional low-risk users, and escalate suspected disclosure through the existing incident process rather than inventing an AI-only procedure.
Use the same source and similar window after remediation. Compare tool prevalence, active identities and sanctioned share. A decline supports closure; persistent traffic can reveal browser extensions, mobile devices, alternative domains or a workflow the replacement failed to solve.
Shadow AI crosses technical, contractual and operational boundaries. A central policy works only when each function knows which decision it owns and where to send an exception.
Maintain discovery coverage, investigate technical anomalies and operate access controls. Security should explain what the logs prove and where visibility ends. It also checks whether sanctioned services support identity, logging, retention and configuration standards.
Translate observed workflows into data, confidentiality and notification questions. Review terms for training, retention, location and subprocessors. When facts suggest a disclosure, use the established legal and privacy assessment process rather than deciding from a domain count.
Prioritize services that employees actually use. Confirm the exact plan, contracting entity and product features because one vendor can offer several materially different data practices. Preserve the assessment date and schedule a review for important services.
Explain the task, data and reason for adoption. Decide whether the workflow is valuable enough to sanction, redesign or replace. Owners also nominate local guidance, test approved alternatives and confirm that remediation works in daily practice.
Give employees examples they recognize, a simple approved-tool directory and a route to request new uses. Communications should avoid implying that DNS reveals prompts. Training is more credible when it solves the workflow that led users to the tool.
Test whether scope is documented, findings have owners, exceptions expire and follow-up runs verify change. Assurance can sample the chain from source export to final disposition without needing access to every identity in the operational report.
In defense, the relevant obligations can include ITAR and EAR controls, CMMC requirements, DFARS safeguarding clauses, classification rules, contract-specific security controls. A domain inventory does not satisfy those frameworks by itself. It supplies a dated factual layer that existing governance processes can use.
Identify the log source, dates, included networks and available identity types. List known blind spots such as unmanaged mobile data, direct IP connections or sites that use a different resolver.
This keeps later readers from giving the numbers more certainty than the collection method supports.
Keep the service name, matched domains, category, first and last observation, identities and sanctioned status. Store dated vendor-term research beside the observation rather than silently overwriting old decisions.
The result becomes a practical subset of the wider AI system inventory.
For each material tool, name an owner, intended use, permitted data, account requirement and disposition. Include the reason for approval, restriction or blocking in language a business user can follow.
A short rationale is more useful than a color with no explanation.
Attach tickets, procurement decisions, configuration changes, user guidance and incident references where applicable. Link each artifact back to the finding it addresses.
This traceability shows that discovery led to controlled action rather than a report that was filed and forgotten.
Some teams need a restricted tool temporarily. Record the business reason, data limits, accountable owner, compensating controls and expiry date.
Time-bound exceptions prevent urgent workarounds from becoming permanent, invisible policy.
Preserve a comparable later report and explain major changes in scope. Track whether targeted identities moved, whether alternative domains appeared and whether approved services gained adoption.
Trend evidence makes the control testable instead of merely aspirational.
A large raw hit count is rarely a useful board metric because DNS caching and automated traffic distort volume. Favor stable measures tied to coverage, decisions and follow-through.
No. It proves that a covered identity or network resolved a domain during the selected period. Confirm the workflow through interview, endpoint evidence or the vendor’s administrative logs before making a disclosure finding.
Immediate blocking can interrupt legitimate work and push users to personal devices or less visible services. Discovery first lets the organization protect urgent risks, preserve useful workflows and provide an approved alternative users will actually adopt.
No. The inventory tells vendor risk which services are actually present and which deserve priority. Procurement, privacy, legal and security still need to assess terms, controls, subprocessors, location, retention and the intended data.
Quarterly is a practical baseline for a stable environment. Monthly review suits fast adoption, active remediation or higher-risk groups. Repeat after major policy, network or approved-tool changes, using comparable scope whenever possible.
Keep the device identity and map it through the asset system only when investigation requires it. Network-level attribution is still useful for locating a site or function, and the report should state that it does not represent a unique-user count.
Explain the business purpose, data sources, fields used, retention, who can see results and how findings will be validated. Clear notice supports trust and prevents a domain observation from being presented as surveillance of prompt content.
Name the product and account tier, approved purposes, permitted data classes, required settings, owner and review date. A vendor-level approval is too broad when consumer and enterprise plans have different training and administrative controls.
Use the organization’s existing incident criteria. Escalate when validation indicates that protected information entered an unauthorized service, credentials were exposed or contractual and regulatory duties may apply. The domain match alone is a lead, not the final conclusion.
Every AI tool with a verdict for defense contractors, as a CSV and ready block lists, from our sister site AI Tools Blocklist. One-time $790.
Upload your DNS or proxy logs and get a CMMC-mapped shadow AI inventory with ITAR and CUI flags.
Start Your Free Audit