What is a trust boundary in enterprise AI?
Nadella named the risk. The part he left unstated is how you tell a real trust boundary from a contract that only describes one.
A trust boundary in enterprise AI is the point past which inference, prompts, corrections, and model weights cannot move without explicit consent. It is architectural rather than contractual, enforced by where inference runs (VPC-resident, single-tenant, no data egress) rather than by what a data processing agreement promises. If inference can reach data from outside it, the boundary is not real.
Satya Nadella spent an essay this month naming a risk every enterprise renting an AI model already carries: the expertise you feed a model to make it useful is expertise the model's owner keeps. His proposed fix has a name. A trust boundary is the point inside an enterprise's own tenant past which inference cannot reach without explicit consent. What the essay does not spend time on is what makes a boundary real. Most vendors selling one this quarter have drawn it in a contract. A contract is a promise about behavior. A trust boundary is a fact about where a wire runs, and buyers who cannot tell the two apart are about to sign the wrong one.
What a trust boundary is
A trust boundary has four properties, and a system missing any one of them has drawn something else and called it a boundary.
Inference runs inside the customer's own environment, single tenant. Nothing else shares the machine reading the prompt, and no shared queue or shared cache sits between the prompt and the model answering it.
No data egress. What crosses the line is a status check on whether the deployment is running. A record does not.
Customer-owned weights. The model fine-tuned on a company's interactions belongs to that company, at signing and at exit, with no separate license required to keep using what its own data trained.
A learning loop that closes inside. Every correction and every approved workflow trains a model that lives inside the boundary, not one shared with anyone else renting the same vendor.
The first three properties exist to make the fourth safe. A boundary that nothing leaves still has to keep learning from what happens inside it, or the deployment stops improving at all. Vendors most often get the first three right and treat the loop as a roadmap item, which is exactly the piece that decides whether the rest of the system stays worth deploying. The moat is the data that never leaves your VPC works through what building that fourth property actually costs; this piece is about how a buyer checks whether any of the four exist at all.
The inference-cannot-cross-it test
Stated as a question a procurement team can run without a lab: can inference, in either direction, reach data or judgment from outside the boundary without a named person on the inside choosing to let it cross?
Trace every path separately. The path a prompt takes to the model. The path a correction takes back. The path a model update takes when the vendor ships an improvement. The path an evaluation takes when a team scores the output. A door nobody is watching turns the boundary into a hallway with a sign on it, and the sign is doing all the protecting.
The test is mechanical on purpose, because reassurance is exactly what a promise sounds like right up until the day it is tested. A boundary built to pass this test does not need anyone's word taken for it. An auditor can walk the network diagram and confirm the same thing the sales deck claims, because the diagram and the deck are describing the same wall.
In practice the conversation is unglamorous. A vendor's own engineer pulls up the deployment topology and points to where the inference call terminates, which tenant owns the machine on the other end, and what happens to the request after the model answers it. A vendor who has to reach for a policy document or a signed attestation instead has already failed the test, whatever the document says.
Trust boundary vs a data processing agreement
A data processing agreement is the instrument most enterprises already hold, and the one a trust boundary gets confused with most often. A DPA governs storage: what is retained, for how long, who may read it, and under what request it gets deleted. None of those questions touch the moment inference happens, and what a live interaction teaches a model without ever moving a stored record is ground what is intelligence exhaust? covers in full. The point specific to a boundary is narrower: a signed DPA is evidence of a policy. It says nothing about whether inference can reach data from outside the line, which is the only question a boundary answers.
Trust boundary vs tenant isolation
Most multi-tenant software calls its separation tenant isolation, and inside a database that phrase usually means something real: rows tagged by customer, permissions enforced by a key. Inference does not inherit that guarantee for free.
A shared inference engine serving many tenants through one model sits one configuration change away from a cross-tenant read, whether through a caching layer, a batched fine-tuning job, or a prompt template that leaks a fragment of one customer's context into another customer's session. The isolation is logical: code, reviewed by people, behaving correctly today. A trust boundary replaces that shared substrate with a separate deployment, so there is nothing underneath the separation left to misconfigure. Tenant isolation lives in code that a reviewer has to trust was written and tested correctly. A trust boundary lives in a deployment topology anyone can check without trusting anyone's code at all.
Trust boundary vs an air gap
The opposite failure runs the other direction. An air gap denies a network path entirely, and a system with no network path cannot ingest a call transcript, receive a model update, or act across systems on anyone's behalf. It answers a much narrower question than the one an enterprise AI deployment has to solve.
A trust boundary is not the absence of a door. It is a boundary with exactly one door, opened by a named event a human controls: a workflow approved, a weight update reviewed and accepted, PII stripped and verified before anything moves. Everything else stays closed by default. A fraud-detection model that cannot receive the corrected label on the fraud it just missed learns nothing from the miss, no matter how tightly the rest of the deployment is sealed. An air gap protects by refusing to connect anything. A trust boundary protects by making every connection an event someone signed for.
What crosses, and what never does
Applied correctly, the boundary lets exactly one thing leave on the model-improvement path: weights, after PII is stripped and verified, and after the customer reviews what is leaving. Data never leaves. A prompt never leaves. A correction never leaves in a form anyone outside the boundary can read. When industry-wide improvements exist, what ships back is a better starting point, pooled from other customers in the same industry vertical, validated on synthetic data before it touches a live decision.
A vendor that cannot answer which of those four items moved last quarter, for a specific customer, is describing a policy rather than a mechanism, and a security questionnaire cannot tell the two apart until the moment something goes wrong.
The buyer's version of the test
A buyer does not need a lab to run this. Three questions, put to any vendor claiming a trust boundary, do most of the work a diligence team would otherwise spend weeks on.
Where does inference physically run, and can the vendor show it on a network diagram instead of describing it in a clause? Name every event under which anything crosses the boundary, and who has to approve each one before it happens. If the relationship ends, what belongs to the customer: the weights, the model, or nothing.
A Fortune 500 insurance carrier put a version of this bar to six AI hiring vendors over eighteen months before finding one whose architecture answered it. The carrier's own counsel cleared the seventh in 17 days, and the deployment moved from signed contract to production in 34, because there was a diagram to check rather than only a clause to interpret.
What the diagram tells you that the contract cannot
Nadella named the risk correctly and left the harder part unresolved: a trust boundary is not something a vendor tells a buyer exists. It is something a buyer can trace, path by path, to confirm it does. Ask where inference runs before asking what the contract says about it. The contract describes what someone intends. The diagram shows what is already true.
Sources
Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises.