Zero Trust for Files is the application of Zero Trust principles to the file itself. A Zero Trust architecture re-verifies identity, device, and network on every request, and then accepts a file’s own declaration of what it is. Zero Trust for Files closes that gap. It decides on what a file actually contains, at the boundary the file is crossing, before anything reads it.

Why it needs to exist

NIST SP 800-207 defines a Policy Enforcement Point, and the signals it enforces on are identity, device, and network. That is the whole list. None of them opens the file.

So an authenticated user, on a compliant device, over a trusted network, can move a file carrying something nobody looked at. The access layer reasons about who and where. It never reasons about what is inside. You cannot decide whether a package is a bomb by checking the courier’s badge.

That was survivable while a document was inert. It is not survivable now that every organization has an ambient interpreter that will read, decode, and act on whatever a file contains. The friction that used to do the defending is gone, and the content your English-and-patterns tooling cannot read is exactly the content an AI reads fluently.

The seven tenets

Each one links to the argument for it.

  1. A file’s verdict comes from its content, not its declared type. The extension, the MIME type, and the magic bytes are assertions from an untrusted party. Type is established by cross verification, and a mismatch is a finding rather than a routing problem.
  2. Inbound and outbound are the same object. A file layer judges both. A payload concealed in an image arriving and a credential set concealed in an image leaving are the same inspection. Direction is an org chart, not a property of the problem.
  3. Verdict is a function of content and position, not identity. The same file can be fine in one place and blocked in another. The question is whether this content may cross this line, not whether this person may act.
  4. Enforcement binds to the path, not the device. Device-bound coverage is a roster, and the roster is always missing the machine you would most want on it. Nothing on the endpoint means nothing on the endpoint to switch off.
  5. The flow is protected without an inventory. You do not need to know a file exists to stop it crossing. Coverage is bounded by topology, not by discovery, so the share nobody mapped is covered by the same act that covers the ones they did.
  6. Same file, same verdict, every time, with a reason you can read. No drift, no per-user state, and a per-signal explanation a person can repeat to an auditor. A control you cannot explain is a control you cannot defend.
  7. Nothing outside the boundary sits in the decision path. No cloud, no feed, no license check. If deciding requires uploading the file, the decision already moved the file off your boundary.
None of these names a vendor. Any control that satisfies all seven is doing Zero Trust for Files.

We have not found one that does, which is why we built one. But the framework does not belong to the product. It is written to be implemented, argued with, and held against us as readily as against anyone else.

Where it deploys

A file enforcement point binds to the path a file travels, not to the device that holds it. So it lives at the boundaries a file crosses, and nowhere else.

  • Inbound. Email, uploads, and managed file transfer, where a file enters.
  • Outbound. The egress gateway or web proxy, where data leaves.
  • Internal. Between one enclave or segment and another.
  • The AI boundary. The moment a file becomes a model’s memory or is handed to an agent.

Because it lives on the path, it needs no endpoint agent. There is nothing to roll out across a fleet, and nothing on the endpoint for an adversary to disable. It also reaches the machines an agent never covers: unmanaged laptops, contractor devices, operational technology, and air-gapped systems that cannot run one. Coverage is a function of where you place it, not of which devices you enrolled.

These crossings are the asynchronous, store-and-forward points, where holding a file for the seconds it takes to read it costs nothing. That is not an accident of deployment. It is the only place a control can hold a file long enough to actually read it.

What this is not

Worth being explicit, because the nearest categories are close enough to be mistaken for this one.

  • It is a verdict, not a rewrite. Zero Trust for Files does not modify your file. It does not strip, sanitize, disarm, or reconstruct. That is a different category, and it makes a different trade: content disarm and reconstruction rebuilds the file and hopes the threat was in the part it stripped. A spec-compliant payload survives that rebuild. Reading what the file is and deciding does not require destroying it, and it leaves the evidence intact.
  • It is not antivirus. Signature and reputation matching against known threats is a different job, done well by other tools. This layer is about concealment, which is not a signature and never appears on a list.
  • It is not discovery or classification. There is no map of your estate, by design. See tenet five.
  • It is not an access control. It judges the file, not the person. It sits alongside your identity layer rather than replacing any part of it.

Honest boundaries

A framework that only lists its strengths is marketing. These are the edges.

  • Coverage is boundary placement, not omniscience. This protects the boundaries you put it on. A file that never crosses one is not in scope, and no amount of tenets changes that.
  • Deterministic does not mean no statistics. The signals are statistical. The claim is no drift, no per-user state, and an auditable per-signal reason.
  • Concealment and language are different problems. A cipher dressed as non-English gibberish is caught now, without needing to know the language it is pretending to be.
  • Holding the file long enough to read it is an architectural claim, and hardware is the limit. Real content-truth on a large media file takes seconds to minutes. An async boundary can afford that where an endpoint or an inline device cannot. That is a statement about what the architecture permits, not a claim that any given build transcribes a feature film today.
  • Encrypted content gets a boundary decision, not a content verdict. We cannot read what is sealed, so we do not verdict on the contents of encrypted or password-protected files, and the coverage report declares that instead of passing them silently. The fact of encryption is still actionable at the boundary, and unreadable content leaving an egress point is often a stop in its own right. Encryption itself is a control other layers own: where a file is sealed by Microsoft Purview or a rights-management layer, we respect the seal rather than breaking it. We read what those tools cannot label; they seal what we cannot read. Complementary, not overlapping.

An implementation

Subtext is ours. It is a self-contained container that sits at a boundary, reduces a file across every modality to the text an AI would read, and returns pass, review, or block with a per-signal reason. No cloud, no threat feed, no external call in the decision path. It runs air-gapped.

It exists because we wanted the seven tenets to be true of something. If you build one that satisfies them too, the framework has done its job.