How to Stop Sensitive Files Entering ChatGPT, Copilot, and Gemini — Without Blocking AI Entirely

A contracts manager at a defense subcontractor opens an active NDA. The counterparty is named. The IP is described. The exclusivity windows are specific. She needs to understand the plain-English implications fast, so she copies the key terms into ChatGPT and asks it for a summary.

That NDA is now in OpenAI's pipeline. Not because a firewall failed. Not because an attacker breached the perimeter. There was no perimeter to breach. The employee made a rational decision using a productivity tool she uses every day, and the file's contents were sent to a third-party AI model with no governance, no audit trail, and no way to retrieve them.

This is the shadow AI data leakage problem. Research from LayerX Security found that 77% of employees have leaked data to AI tools. Threat telemetry from Netskope reports that sensitive data sent to AI tools increased sixfold in the past year. IBM's Cost of a Data Breach Report puts the average cost of a breach involving shadow AI at $4.63M, compared to $3.96M for a standard breach. That $670,000 gap exists precisely because shadow AI exposure is harder to detect, investigate, and contain than conventional breach scenarios.

The question security teams are now working through is not necessarily whether to block AI tools. Blocking doesn't hold: it drives use underground and removes the productivity gains that come from governed AI adoption. The question is what technical control actually prevents sensitive file contents from reaching an AI model. The answer is the file itself.

Why Traditional Controls Can't See What Employees Send to AI Tools

Data Loss Prevention tools operate on network traffic and endpoint activity. They can identify that an employee connected to openai.com. They can flag a large file transfer to an external service. What they cannot do is inspect the content of an HTTPS-encrypted prompt sent to ChatGPT. The payload — the actual text the employee typed or pasted — is encrypted in transit and lands inside OpenAI's infrastructure beyond the reach of any enterprise DLP rule.

Network monitoring has the same blind spot. Your SIEM sees an outbound connection to a known AI service. It cannot see the contract text that accompanied it. URL filtering can block access to ChatGPT entirely, but this creates a parallel problem: employees route around the block. They use personal devices on home networks, access AI tools through mobile browsers, or switch to a less-restricted alternative. The file content still exits the organization. The security team just loses visibility when it does.

Microsoft Copilot introduces a variation of this exposure. Because Copilot is integrated directly into Microsoft 365, employees don't think of it as an external AI tool. When Copilot summarizes a SharePoint document or drafts an email based on an attached contract, that data moves through Microsoft's AI processing layer. Most organizations have assumed that existing Microsoft licensing arrangements adequately govern this. Many have not verified the assumption. For organizations handling ITAR-controlled technical data, EAR-restricted information, or any data governed by CMMC requirements, that gap carries direct regulatory weight.

The core issue is that traditional controls treat the file's destination as the control point. AI tools have broken that model. The connection between employee, file, and AI tool is now a single authenticated HTTPS session — invisible to the controls built for a world where data moved over identifiable network paths to known destinations. 

The File Is the Attack Surface, Not the AI Tool

When an employee pastes a contract into Gemini or uploads a PDF to ChatGPT, the attack surface is not the AI tool. The AI tool is the destination. The attack surface is the file itself — specifically, the fact that the file's contents are readable by anything that receives them.

A PDF of an ITAR-controlled technical document is readable by ChatGPT for the same reason it is readable by the employee who opened it: the contents are in plaintext, or trivially decoded from the PDF container. Once the employee has access to the content, any tool she uses to interact with that content gains the same access. Her clipboard, her AI assistant, her personal email client — all of them. The file has no ability to enforce policy after it leaves the governed environment.

This reframes the problem in a meaningful way. If you try to control which AI tools employees are permitted to use, you are playing a permanent catch-up game against a tool landscape that is expanding faster than any policy cycle. New AI tools appear weekly. Employees will find the ones that aren't on the blocklist. If instead you control what those tools can read, you address the problem at the source. The specific destination tool becomes irrelevant because the content it receives is ciphertext.

What Does File-Layer Encryption Actually Do When a File Reaches an AI Tool?

File-layer encryption means each file is encrypted with its own unique cryptographic key before it leaves the governed environment. The encryption is applied at the object level, not the transport level. When the file moves to cloud storage, email, a USB drive, or ChatGPT, it travels as ciphertext.

Theodosian implements this using per-file AES-256 encryption with FIPS 140-3 validated cryptographic modules. Each file has a unique key. That key does not reside inside the file. It is managed by Theodosian's patent-pending zero-knowledge architecture, meaning that even Theodosian's own infrastructure cannot decrypt a file without an authorized request from an authenticated, policy-cleared identity.

When an employee uploads an encrypted PDF to ChatGPT, what ChatGPT receives is ciphertext. The AI model cannot decrypt it. It reads random bytes. There is no summary to generate because there is no readable content to process. The file's contents remain protected not because the AI tool was blocked, but because the file itself cannot be read without the right cryptographic identity presenting at the right moment under the right access conditions.

This protection holds across every AI tool, every device, and every transfer method. The encryption is not tied to a network path or a specific application. It travels with the file, persistently, regardless of what happens to the container after it leaves your organization.

How Does AI Identity Brokering Let You Permit Governed AI Without Blocking Everything?

The immediate objection to a file-layer encryption model is that it would also block legitimate, governed AI use. If a file is always encrypted, how does an authorized Copilot user summarize a document they are permitted to work with?

AI identity brokering is the answer to that practical constraint. Theodosian's access control layer evaluates not just who is requesting access to a file, but the full context of that request. The identity of the requesting application can be factored into the policy decision alongside the user's identity, geolocation, network context, time of access, and behavioral baselines.

An organization can define a policy that allows a governed Microsoft Copilot instance running on a managed endpoint to request decryption of files within a specific sensitivity classification. The same policy denies that decryption request when it originates from an unmanaged personal device, or from a tool that is not in the organization's governed application registry. An unauthorized or personal AI tool receives either unreadable ciphertext or a flat access denial. The employee using enterprise-managed Copilot within policy receives the content. The two experiences diverge at the cryptographic access decision, not at the URL filter.

The policy is not a blocklist. It is a real-time access decision evaluated at the moment of each file request. If something in the access context triggers Theodosian's behavioral anomaly detection — an unusual access volume, an off-hours request pattern, an unrecognized device — Drop the Gate initiates an autonomous access freeze. Decryption requests from the affected identity and file set are suspended without waiting for manual security review. The file is protected from that moment forward until the incident is resolved.

What Are the Compliance Implications of Shadow AI File Exposure?

For defense contractors and enterprises handling regulated data, the compliance implications of shadow AI exposure are specific and enforceable, not speculative. ITAR requires that controlled technical data be disclosed only to US persons under specific authorized conditions. There is no exception for AI tools. If an employee uploads ITAR-controlled content to ChatGPT, that is a potential ITAR violation regardless of intent. The voluntary disclosure process does not make the violation disappear; it determines how the State Department responds to it.

CMMC Level 2 requires organizations to control access to CUI and to maintain an audit trail of that access. Shadow AI use breaks both requirements: the organization cannot control access it cannot see, and it cannot audit transfers that occur outside managed systems. NIST 800-171 Control 3.1.3 requires the flow of CUI to be controlled. Unmonitored AI tool uploads are, by definition, uncontrolled flows. A CMMC assessor reviewing your system security plan will ask how you prevent unauthorized CUI disclosure. "We block ChatGPT at the URL filter" is not an adequate answer when the bypass vectors are this accessible.

The consequence structure here is not just financial. For defense contractors, a shadow AI incident that exposes controlled technical data can trigger a loss of facility clearance, damage to prime contractor relationships, and direct DoD notification obligations. These are contract-level risks, not just breach cost calculations. The gap between where most organizations are and where they need to be on this issue is specific: the threat mechanism is well understood; the technical control that addresses it at the file level is available; the implementation barrier is organizational rather than technical.

How Does Theodosian Address Shadow AI at the File Level?

Theodosian applies file-layer encryption to sensitive files at the point of creation or ingestion, before any subsequent movement occurs. Each file receives a unique AES-256 key under a FIPS 140-3 validated cryptographic framework. The encryption persists regardless of where the file travels: email, SharePoint, Teams, personal cloud storage, or a third-party AI tool.

Access decisions are context-aware and evaluated in real time against identity, device posture, network, geolocation, time of access, and behavioral baselines established for each user. AI identity brokering extends this governance to approved AI tools, allowing organizations to permit specific, governed AI use cases without creating categorical exceptions that shadow use can exploit. When anomaly detection identifies a potential incident, Drop the Gate initiates an autonomous access freeze — cutting off decryption requests from the affected identity and file set without waiting for manual intervention.

Theodosian runs on FedRAMP Moderate infrastructure and deploys without requiring data migration. A proof of concept is scoped for two weeks, demonstrating the encryption and access control layer on a defined file set within your existing Microsoft 365, Google Workspace, or cloud storage environment. The architecture works alongside existing tooling. There is no forklift migration, and no gap in file access for authorized users during the rollout.

FAQs: AI Data Governance & File-Layer Controls