Vendor-Blind AI Deployment Patterns That Make Prompt Exposure Architecturally Impossible

Zero-trust AI architecture for enterprise makes prompt confidentiality a property of the deployment. Self-hosted inference removes vendors from the data path, Trusted Execution Environments protect data from privileged hosts, and separated agent flows constrain what untrusted content can cause. Prompt exposure becomes structurally impossible only for the paths these controls actually close, so the guarantee depends on their composition and implementation.

Why prompt confidentiality cannot be achieved through policy alone

LLMs merge instructions and user inputs in the same context. This is a design characteristic. When trusted instructions and untrusted content share that context, the boundary between them is semantic. The model must interpret which text has authority, while a policy document has no means to enforce that distinction during execution. Confidentiality therefore requires controls outside the model’s interpretation of the prompt.

The same distinction separates governance from enforcement. Bokkasam & Durgalakshmi’s September 2026 paper describes an attestation deficit, in which organizations have governance policies but cannot prove to regulators that those policies are enforced. NIST AI RMF, ISO/IEC 42001, and the EU AI Act define organizational obligations. Certifications have a boundary problem of their own. A vendor’s certification covers its systems, while an AI data pipeline can extend beyond them.

That pipeline can disclose confidential data inside a provider’s observability stack, beyond the organization’s own telemetry. Contractual restrictions on training do not establish technical proof that submitted data stays out of training systems. Encryption protects traffic on its journey, but the SaaS provider still processes it at the destination. Who can read the prompt once it arrives?

The boundary must keep an actor from accessing data or keep untrusted content from gaining authority over how that data is used. Those are different controls, but they respond to the same structural weakness. Every pattern that follows moves a boundary out of promises or interpretation and into the system that executes the work.

How the exposure surface actually fractures across a modern AI stack

Prompt exposure occurs through a chain of handoffs. Browser interactions, API requests, agents, and SaaS embeddings create different surfaces, each with controls that may leave the others uncovered. A browser control does not, by itself, govern an API integration. Similarly, protection at the model boundary does not establish what an agent can send through a tool. The unit of analysis is the complete data path.

A guardrail inspecting prompt injection or sensitive-data leakage must read the full prompt, response, and tool calls. If that inspection runs as SaaS, the security vendor receives a copy of the traffic being protected. Long-lived contexts and provider-side caches introduce further copies that may never have been explicitly inventoried. Model-level prompt hardening cannot close these paths through which the infrastructure can access data.

Samsung’s experience makes the boundary failure concrete. Within weeks, three employees pasted sensitive material into ChatGPT, including source code in two incidents and a meeting transcript in one.

Xi’s August 2026 work explains that retention terms depend on both the provider and the channel through which a model is accessed. An anonymous model therefore creates uncertainty about more than capability. Its identity determines which data-handling terms apply, leaving a supply-chain gap when that identity cannot be established. Before a confidentiality claim can be judged, the architecture must show who gets the data at every handoff.

Self-hosted inference: how do enterprises keep vendors out of the data path?

Self-hosted inference removes the external application vendor as a recipient of prompts, responses, and tool calls. That is the first architectural break with trust-based confidentiality. The decisive condition is not the label on the deployment, but whether anyone outside the organization handles the data. A service described as private can still fail that test if its vendor receives the traffic.

“On-prem” in 2026 often means vendor software running in the organization’s own cloud account or VPC. Location alone does not settle access. An in-region SaaS service meets a residency requirement while leaving the vendor able to receive, operate on, and potentially be compelled to produce data. The deployment spectrum runs from SaaS through self-hosting in a VPC and an on-premises data center to an air-gapped environment. Each step takes another outside party out of the process and changes the work needed to run it.

Self-hosting the model while sending prompts to a SaaS guardrail preserves an external disclosure path through the security system. Running the inspection engine in the organization’s own Kubernetes cluster removes that security vendor from the data flow. The model’s location cannot compensate for another component exporting the same prompt.

There is an operational price for that control. GPU nodes need to be run, upgrades scheduled, and some cloud-first features become available later. Self-hosting fits workloads with a hard data requirement, while a hybrid deployment can keep regulated workloads self-hosted and use SaaS for the rest. Removing vendor access is necessary to eliminate that recipient without confidential-computing protections, while securing the whole workflow also requires protection against prompt injection and agent-layer leakage.

Samsung’s later trajectory exposes this distinction at the application tier. Three years after the incidents, Samsung returned to ChatGPT Enterprise for general tasks. Enterprise platform controls still do not govern everything placed into prompts by custom agents, internal copilots, and CI/CD integrations. Those applications have their own boundaries and ways of handling data.

Trusted Execution Environments: making prompts invisible even to the host

Self-hosting changes who operates the application, but infrastructure privilege remains a separate question. What happens if the host itself is outside the trust boundary? A Trusted Execution Environment, or TEE, creates a hardware-encrypted enclave whose memory is inaccessible to the operating system, hypervisor, and privileged host administrators while code executes. This extends protection beyond the application vendor. Confidentiality no longer depends solely on denying outsiders an application account.

Commercial implementations include Intel TDX, AMD SEV-SNP, and NVIDIA’s confidential computing mode on H100/H200 GPUs. The Petridish system demonstrates confidential prompting on a TEE-backed Confidential Virtual Machine, or CVM, as a first step toward end-to-end confidential inference. Its scope is important to retain. Protecting prompts inside a CVM is not, by itself, evidence that every handoff in a larger deployment is protected.

Huang et al.’s 2026 Talaria paper demonstrates a partitioned approach to confidential inference. Sensitive, weight-independent operations run inside a client-verified CVM, while weight-dependent computations run on cloud GPUs. Reversible Masked Outsourcing, or ReMO, obscures intermediate data before it crosses that boundary. Talaria reduces token reconstruction accuracy from over 97.5% to a negligible average while preserving output identical to the original model.

Remote attestation supplies the verification step before disclosure. Users can use cryptography to check the model’s hash and the TEE’s security properties before sending sensitive inputs. NVIDIA’s H100/H200 confidential computing runs at close to native performance while it protects model weights, training data, and inference inputs. Production use need not entail prohibitive overhead. Nevertheless, performance claims and isolation claims depend on how the complete system is implemented.

A 2026 result identifies the danger of shortcuts in partial TEE-shielded inference. Precomputed static secret bases used to accelerate cryptographic operations introduce reuse of secret keying material, creating a key-reuse vulnerability. Hardware isolation cannot fix flaws in the protocol around it. Even a correctly implemented TEE leaves another route untouched, because a prompt-injected agent can disclose protected data through its own outputs or tool calls. The host may be unable to read memory while the application still has permission to reveal what it holds.

Dual-LLM separation and Prompt Flow Integrity: making prompt injection structurally ineffective

Agent-layer protection starts by separating authority from content. Filtering text before it reaches an LLM cannot reliably keep that boundary in place once instructions and data share the same context. The alternative is to constrain execution regardless of what the model reads. Can an untrusted document change the plan, invoke a privileged tool, or redirect sensitive data? Architectural protection answers through permissions and data flow rather than through the apparent harmlessness of the document.

CaMeL divides these roles between two LLMs. A Privileged LLM receives the trusted user query and generates a plan in restricted Python, while a Quarantined LLM extracts structured information from untrusted sources without access to tools. An interpreter executes the plan and invokes tools. Extracted values remain capability-tagged variables, so an injection reaching the Quarantined LLM cannot issue instructions back to the Privileged LLM.

The Prompt Flow Integrity framework keeps the same boundary in place with Data IDs that separate trusted and untrusted flows and prevent privilege escalation. PFI achieved zero percent Attacked Task Rate across all tested models and benchmarks, preventing both prompt injection and data injection in that evaluation. Baseline agents reached vulnerability rates of 100% on some benchmarks. The contrast is substantial, but its scope remains empirical. The tests support the architecture but do not prove that it is safe from every possible attack or flaw in how it is built.

Both patterns constrain what the agent can do. Capability-based design and typed tool calls through MCP extend that principle to tool access, because an agent cannot leak through a tool it has no authority to call. The objective is to prevent malicious instructions from reaching privileged execution even if the model processes them. This closes a route that infrastructure encryption leaves open.

The ACE paper explains that IsolateGPT does not attempt to defend against attacks occurring entirely within one application, including prompt injection during input processing. Hub-and-spoke isolation reduces cross-application contamination while leaving intra-application injection unaddressed. Trusting raw application outputs can still expose an LLM to malicious instructions. Isolation must therefore be assessed by which transfers of authority it forbids.

What no single pattern covers, and how layered deployment closes the remaining gaps

The strongest objection to architectural impossibility is that every proposed pattern has limits. That objection is correct when the claim lacks a defined exposure class. Self-hosting removes vendor-side access, while TEEs address privileged infrastructure access. Neither constrains the semantic behavior of an agent. Conversely, dual-LLM separation and PFI constrain agent flows without preventing an infrastructure operator from reading unprotected prompts.

Composition connects these protections into a deployment architecture. Self-hosted or TEE-backed inference closes the relevant infrastructure access paths, separated agent flows block untrusted content from gaining execution authority, and capability-limited tools constrain output routes. Security inspection must stay within the same protected data boundary. Otherwise, the inspection service reopens the very path the inference design removed. The guarantee belongs to the assembled system.

Governance can then produce evidence through enforcement itself. Bokkasam & Durgalakshmi’s AGIL framework proposes a Policy Enforcement Gateway for inline permit, deny, or modify decisions at sub-100ms latency. Its Continuous Attestation Engine generates tamper-evident audit trails as a byproduct of enforcement. The proposed architecture still requires deployment evidence. Its contribution is to connect organizational rules to runtime decisions that can be examined.

Supply-chain attribution still needs its own checks. Xi reports that 45.83% of third-party API endpoints failed identity verification in independent audits and proposes a black-box forensic audit protocol as a technical complement to architectural controls. For buyers, the corresponding criteria are data-path coverage, protected execution, separated authority, constrained tools, and evidence of enforcement. A feature ranking cannot establish those properties. Nor can a browser-only control account for API and agent traffic outside its reach.

A defensible claim of structural impossibility must name the recipient or action made impossible and the mechanism that prevents it. Evaluation results, cryptographic boundaries, and deployment topology answer different parts of that claim. None should stand in for the others. Privacy by design means arranging those boundaries before sensitive data enters the workflow, so confidentiality follows from what the system cannot do rather than from what its operators promise not to do.