Private AI Agent: Architecture, Attestation, and Where Most Deployments Fail

TL;DR

• If an agent's code and tool calls execute on shared infrastructure, encrypting data in transit doesn't protect it from the operator at execution time. A TDX Trust Domain moves that boundary into hardware, giving the runtime a separately verifiable execution environment rather than relying only on the cloud provider's controls.
• A ZDR agreement answers a policy question about what a provider promises to do with prompts, while a TEE receipt answers a technical question about where an inference actually ran. Teams therefore have to choose between model availability and stronger inference evidence when frontier models lack TEE-backed receipts.
• Checking only the runtime leaves model inference unverified, while checking only inference leaves agent execution unverified. A regulated deployment needs sandbox attestation for the execution boundary and inference receipts for model calls because neither artifact proves what the other one covers.
• Parallel execution becomes an audit problem when agents share a working directory because file collisions and mixed action histories make individual decisions difficult to attribute. Assigning each agent its own worktree and TDX sandbox separates both the filesystem state and the resulting attestation evidence.
• A session-level model choice doesn't guarantee the same inference boundary for delegated work because subagents make their own inference calls. If a sensitive reasoning task such as oracle inherits a non-TEE model, its reasoning call falls outside the cryptographic evidence expected for the primary session.
• Procurement reviews that stop at SOC 2, retention policies, or ZDR agreements miss evidence tied to individual executions. The review needs to establish where tool calls ran, which inference tier processed each request, whether both attestation types can be produced independently, and whether parallel agents have separate audit surfaces.

When "Private" Becomes a Meaningful Claim

Forty percent of enterprise applications will include task-specific AI agents by the end of 2026, up from under 5% in 2025, and the gap between that deployment velocity and actual governance infrastructure is the central compliance problem of the moment. The phrase "private AI agent" should describe a system where data doesn't leave your control at any point in the execution chain. In practice, it describes a marketing category in which the actual boundary lies somewhere between "we don't train on your prompts" and "your code runs inside encrypted hardware." Those aren't the same claim, and regulators in the EU AI Act enforcement window and the 2026 FINRA agentic AI recordkeeping guidelines have started drawing that distinction explicitly.

The problem isn't that private AI agents are hard to build, but it's that the tooling available to most teams was assembled from layers that solved different problems without talking to each other. An AI IDE handles where your code runs. A managed gateway handles where your prompts go. Neither layer, on its own, gives you a private AI agent. A 2026 survey found that enterprise employees still spend roughly 4.5 hours per week correcting AI output, which points to the downstream cost of architectures that weren't actually private but were assumed to be.

This article covers the two-boundary architecture a private AI agent requires, why most configurations inadvertently leave one boundary open, and how ORGN's CDE implements both layers with independently verifiable proof. The specific decisions covered: what runtime isolation actually means versus inference isolation, how sandbox attestation and TEE inference receipts answer different questions, and what a procurement review should be asking that it probably isn't.

The Two Boundaries a Private AI Agent Must Hold

A private AI agent is the intersection of two separate confidentiality guarantees that operate at different layers of the stack and require different evidence to verify.

1. Runtime: Where Your Code and Tool Calls Actually Run

The first boundary is runtime: where does the agent actually act? Every file read, terminal command, codebase search, and API call an agent makes produces an execution trace. On most cloud AI development platforms, that trace runs on shared infrastructure, which means the hypervisor and the cloud operator can read memory while your code is processing. Encryption in transit doesn't close this gap. The data is decrypted when it reaches the compute layer, and on a shared VM, the operator controls that layer.

Intel TDX (Trust Domain Extensions) moves enforcement to the CPU. A TDX Trust Domain is an isolated VM with encrypted memory: the cloud operator, the hypervisor, and, in ORGN's architecture, ORGN itself can't inspect the running state. When you attach to a cloud worktree in ORGN CDE using Open Cloud Project from the Projects sidebar, your repository, terminal, and every Origin Agent tool call run inside a TDX sandbox. The SSH attach lands inside that Trust Domain. Code executing there is processed in hardware-isolated compute, not on a shared cloud instance.

The distinction matters for what "private" means in practice. A developer on a finance team who runs a private AI agent to review draft contracts doesn't want the cloud provider to see those documents mid-execution. A TDX sandbox makes that a hardware guarantee, not a contractual one.

2. Inference: Where Your Prompts Travel and What Proof Exists

The second boundary is inference: when Origin Agent sends a prompt to a model, where does that prompt go, and what evidence do you have about how it was handled?

ORGN's model catalog has two tiers: ZDR and TEE, and the picker surfaces the tier as a badge pulled from the model's live model_info, not inferred from the model string itself. ZDR (Zero Data Retention) is a policy classification: the provider has committed not to store or train on prompts sent to that model. It's worth being precise about what ORGN does with that classification versus what it doesn't: the badge reflects the provider's stated policy, but ORGN doesn't attach a retention flag to the outbound request to enforce it; that field is deliberately never sent on the wire. It's policy trust, not a technical guarantee ORGN layers on top: strong, auditable, useful, but still a contract, and contracts can be amended, acquired, or reinterpreted.

Chat, generate_code, and secure_chat all default to a ZDR model, vercel_claude_sonnet_4_6, which means a normal session produces no TEE receipt unless the model is deliberately switched. That default matters for how to read the rest of this section: TEE isn't a fallback reached for only when a frontier model happens to lack it; it's a separate configuration a team opts into through the model picker when the compliance posture specifically requires it.

TEE models, spanning providers like NEAR, Phala, and Tinfoil, go further: inference runs inside hardware-isolated compute, with a cryptographic receipt generated per request. That receipt is a different evidence type than sandbox attestation, and the two shouldn't be conflated. Sandbox attestation is Intel TDX, verifiable against Intel's PKI specifically. TEE model receipts are provider-specific; NEAR, Phala, and Tinfoil each produce their own attestation format, verifiable against that provider's own scheme, not against Intel's PKI. Both are hardware-signed and independently checkable, but they're not the same proof, and a security review that treats a Phala or Tinfoil receipt as Intel-PKI-verifiable checks the wrong chain.

Frontier models, Claude, GPT-5, Gemini, aren't yet available with TEE receipts, so teams needing the strongest reasoning models default to ZDR unless they explicitly switch. Teams whose compliance posture requires per-request cryptographic proof of where inference ran pick a TEE-tier model instead. A TEE filter in the picker narrows the list to hardware-backed options only, with the ZDR/TEE badge on every option always reflecting live model_info rather than the model string's prefix.

The decision isn't model preference first; it's evidence requirement first. The tree below maps that decision: start with what you need to prove, then work toward which model tier satisfies it.

The "Limited Choice" branch is the one worth bookmarking for procurement conversations. When the required model doesn't have a TEE option, the honest answer is ZDR plus a runtime attestation report from the sandbox, not a claim that the gap doesn't exist.

3. Attestation: The Evidence Layer That Closes Both Gaps

Attestation turns both of these guarantees from vendor claims into verifiable facts. Two separate attestation artifacts cover the two boundaries, and they answer completely different questions.

• Sandbox attestation covers runtime: It proves the TDX Trust Domain your agent acted inside was genuine Intel TDX hardware running an untampered image. In CDE, you fetch it from the status bar TDX shield or via Show TDX Sandbox Attestation in the command palette. The report includes a Sandbox ID, a TDX quote (hardware-signed evidence from Intel), launch-environment measurements, and an issue timestamp. You can verify that report against Intel PKI without calling ORGN. It proves where the agent ran, not what it said.

• Inference TEE receipts cover model calls: for TEE-tier models, each inference request through the ORGN Gateway produces a receipt viewable in ORGN Scanner, verified against that model's own provider scheme rather than Intel's PKI. That receipt proves where the prompt was processed, not where the tool calls executed.

Neither artifact replaces the other; a security review that only checks runtime attestation has a gap in inference. A review that only checks inference receipts has a gap in execution. A complete evidence package for a regulated team includes both, and knowing which answer each artifact provides is the first step toward assembling it.

The sequence below shows how both artifacts are generated in a single agent execution: tool calls produce sandbox attestation from the TDX runtime boundary, and inference requests produce TEE receipts from ORGN Gateway, each traveling a separate path to ORGN Scanner for independent verification.

Steps 8 and 9 in the diagram are the ones most teams skip. Fetching both artifacts at execution time, not during a post-incident review, is what makes a compliance posture hold under audit.

Where Agent Tool Calls Break the Privacy Boundary

Runtime confidentiality is only as strong as the surface where tool calls execute. Most agentic IDE deployments treat inference and runtime as a single boundary, but they're not.

The Execution Surface Most Teams Don't Audit

When an AI agent reads a file, runs a terminal command, or searches a codebase, it's taking an action inside the execution environment, not sending a message to a model. In Open Project mode, those actions run locally on a folder on your machine. No sandbox, no attestation, no hardware guarantee. That's appropriate for teams whose threat model doesn't extend to endpoint security, and CDE's local mode works well for that use case.

On cloud worktrees, the picture is different. Tool calls execute inside the same TDX sandbox as the code. The boundary that covers your repository covers every @file, @folder, and @codebase search Origin Agent performs. A @codebase semantic search on a cloud worktree runs against a workspace index built inside the sandbox; the search doesn't send file contents out to an indexing service. The operational consequence: the agent's action surface and the code's confidentiality surface are the same surface.

The Servers panel in CDE Settings makes the runtime boundary concrete. The active orgn/trial sandbox entry shows a cloud worktree connected through a Daytona proxy; that's the TDX Trust Domain the agent is operating inside. The local project entry at 127.0.0.1 sits alongside it, with no sandbox and no attestation. Two entries, two fundamentally different confidentiality postures, visible in the same view.

The distinction matters operationally: any agent session running against the 127.0.0.1 local entry produces no sandbox attestation report because there's no TDX sandbox to attest. Switching to an orgn/trial cloud entry is what activates the runtime boundary, and the TDX shield in the status bar confirms when SSH attach has completed and attestation is available.

This matters for proprietary codebases as a defense engineering team running an agent to audit a classified software dependency graph can't have that graph leave the hardware boundary during the audit. On a cloud worktree, it doesn't. On a local folder or a shared cloud IDE, the guarantees differ, which might be fine, but the team should know which configuration they're running.

Parallel Agents and the Isolation Problem

Running two agents on the same repository branch at the same time creates a coordination problem that most teams solve by slowing down and running agents sequentially rather than in parallel. The underlying issue isn't a technical preference; it's collision risk. Agents that share a working directory can overwrite each other's file edits, race on terminal commands, and produce an audit trail that can't be cleanly attributed to either agent's decision chain.

The ORGN CDE pattern for parallel execution is one worktree per agent focus. Each worktree in the Projects sidebar maps to a separate branch and a separate TDX sandbox. Two agents on two worktrees don't share a runtime boundary. They can't collide on the file system. Their attestation reports are separate because their sandbox IDs are separate.

The swimlane below makes the architectural split concrete: each agent row carries its own worktree, its own TDX sandbox, its own file system state, and its own attestation artifact. The bottom row shows what the shared-environment alternative produces, mixed attestation that can't support attribution.

"Not auditable" in the shared path isn't a configuration problem you fix later. It's a structural consequence of the architecture. The time to enforce worktree-per-agent discipline is before the first parallel run, not after a compliance review flags the gap.

The FINRA 2026 Magnetic AI guidance and the EU AI Act's high-risk classification for agents in regulated domains both require that actions be attributable. Separate worktrees produce separate audit surfaces by design, not by configuration. Sandbox attestation reports bind to the specific worktree's sandbox ID, so the evidence of what each agent did is already segregated at the hardware level.

Subagent Routing and the Hidden Inference Gap

Origin Agent doesn't run every sub-task itself. For well-defined sub-problems, codebase search, document reading, hard architectural reasoning, it delegates to a subagent: a focused helper that runs that piece and returns the result. Each subagent invocation is a separate inference call. If the subagent model runs on a different tier than the primary session, the inference confidentiality changes mid-task without any obvious signal.

The routing configuration lives at Settings → AI → Agents in CDE. By default, every subagent inherits the session model, which means switching the session model changes every subagent's inference tier. Teams that need oracle, the deep-reasoning subagent used for hard architectural questions, to always run on a TEE model should explicitly pin it, regardless of session defaults. The table below shows the subagent roles and the rationale for pinning decisions:

A team that runs oracle on a TEE-pinned model gets a receipt in Scanner for every architectural reasoning call it makes, separate from the primary session's model receipts. That's a finer-grained audit trail than most compliance reviews think to ask for, but it's exactly what FINRA's new framework requires when an agent's reasoning directly influences a regulated decision.

The oracle subagent is shown with a pinned TEE model selected, while explorer remains on "Inherits session model." This illustrates the per-subagent override behavior documented in the CDE agents page.

What Regulated Teams Actually Need From Attestation

A compliance review that asks "does your vendor have a ZDR agreement?" is asking the minimum question. The question that closes the actual risk is: "What evidence can you produce, independently of the vendor, that proves where this workload ran?"

The Difference Between Policy Trust and Hardware Proof

Policy trust, ZDR agreements, SOC 2 reports, data handling addenda- is a claim that requires trusting the claimant. It's not worthless. SOC 2 Type II audits are meaningful. ZDR agreements from reputable providers are meaningful. But they have one structural limitation: they can change. A vendor updates their terms. An acquisition happens. A government order applies. None of those events are reflected in the ZDR agreement you signed at procurement.

Hardware attestation doesn't have that structural limitation. A TDX quote in a sandbox attestation report is signed by the CPU, verifiable against Intel's PKI, and doesn't change retroactively. If you fetch the attestation report at the time of execution and store it, you have hardware-backed evidence of where that agent ran that's independent of what the vendor says or does later. The report binds to the specific sandbox, the specific worktree, and the specific launch image; it's not a category claim, it's a per-execution record.

That's the evidence that satisfies a procurement questionnaire written by someone who understands the difference. It's also the evidence that satisfies an auditor who's been told that a ZDR agreement is sufficient and knows enough to push back.

Reading a TDX Attestation Report Without Getting Lost

The attestation report CDE fetches for an active cloud worktree contains four fields that are relevant to a security review. The Sandbox ID identifies the specific confidential VM, not the cluster, not the region, the specific trust domain your agent ran inside. The TDX quote is the hardware-signed evidence, verifiable against Intel PKI through ORGN Scanner or directly against Intel's certificate chain. The measurements are digests of the measured launch environment; if the software image was tampered with, the measurements won't match. The issued time records when the report was generated.

The report proves exactly two things: the sandbox ran on genuine Intel TDX hardware, and the software image hadn't been tampered with at the time of attestation. It doesn't prove what the agent did inside the sandbox, nor what model handled the inference. Those require the action logs and the inference receipts, respectively. Security reviews that conflate these three artifacts end up with a false sense of coverage; reviews that treat them as separate evidence categories yield a complete picture.

EU AI Act and FINRA: What the Compliance Surface Now Requires

The EU AI Act's enforcement powers activated August 2, 2026. An autonomous agent used for credit assessment, clinical decision support, recruiting, or critical infrastructure management is a high-risk AI system under Annex III, regardless of the underlying model or deployment pattern. High-risk classification means mandatory human oversight, explainability requirements, and record-keeping that can reconstruct what the agent decided and why.

FINRA's 2026 Annual Regulatory Oversight Report added the first explicit section on agentic AI systems, covering supervision, recordkeeping, testing, and ongoing monitoring for agents executing multi-step tasks autonomously. The core requirement is that you must be able to attribute what happened to a specific agent decision chain, not just produce logs.

An agent that can't generate a sandbox attestation report, because it doesn't run in attested hardware, can't satisfy the "prove where this ran" question. An agent whose subagent inference calls aren't receipt-tracked can't satisfy the "prove what model made this reasoning call" question. Both requirements exist in the current regulatory environment, and both have been verifiable since ORGN added Scanner to the stack. The gap isn't tooling; it's that most teams haven't yet connected their compliance requirements to their infrastructure configuration.

Deployment Patterns That Hold Under a Real Security Review

Teams that have passed CISO reviews and procurement processes with ORGN CDE tend to run two configurations: local Open Project for unclassified work with standard ZDR inference, and cloud worktrees with TEE-pinned subagents for anything touching regulated data. The split isn't a product requirement; it's a practical consequence of matching the security posture to the data sensitivity.

What a Procurement Questionnaire Should Actually Ask

Standard AI tool procurement questionnaires ask about SOC 2, data retention policies, and model training practices. Those questions capture vendor-level commitments. They don't capture per-execution evidence. Four questions add the layer most reviews are missing:

1. Where do tool calls execute, and on what hardware? A vendor that answers "on our cloud infrastructure" hasn't told you anything about isolation. The answer that closes the question: "inside a TDX Trust Domain with per-sandbox attestation available on request."
2. What inference confidentiality tier is available, and what proof does it produce per request? ZDR is policy; TEE is hardware. Both are legitimate, but they're different answers to different questions. Know which one you're buying.
3. Can attestation reports be produced for runtime and inference independently? If the vendor can only produce one or neither, you're working with policy trust for at least one boundary.
4. How are parallel agent sessions isolated from each other? Agents that share a runtime boundary produce an audit trail that can't be cleanly attributed. Separate worktrees, separate sandboxes, separate attestation IDs are the answer that satisfies this question.

ORGN CDE answers all four i.e., local mode is explicit about what it doesn't attest to; cloud worktrees are explicit about what they do. The documentation surfaces the boundary conditions at each layer, which means the security review conversation starts with accurate information rather than vendor marketing.

Private AI Agent Deployments in Regulated Environments

The runtime and inference boundaries a private AI agent must hold aren't difficult to implement. What's difficult is knowing which one you've left open. Teams that assume a ZDR agreement closes the runtime question, or that running on their own hardware closes the inference question, have identified the boundary they care about and assumed it covers the one they didn't think to check.

ORGN CDE's architecture makes the distinction explicit at every level: local mode vs. cloud worktrees for runtime, ZDR vs. TEE badge in the model picker for inference, sandbox attestation via the TDX shield for runtime evidence, and Scanner receipts for inference evidence. The subagent routing page is the place where teams most often discover a misconfiguration, oracle running on a fast session-inherited model instead of the TEE-pinned configuration their compliance policy requires.

The question isn't whether private AI agents are achievable in regulated environments. They are. The question is whether the configuration you're running actually produces two independently verifiable boundaries, and whether you can hand a procurement questionnaire an attestation report and an inference receipt and say: here's where it ran, here's where the prompt was processed, and here's the signed proof for each.

Frequently Asked Questions

1. What's the difference between a private AI agent and a self-hosted AI model?

A self-hosted AI model is about where the model weights live and who operates the inference server. A private AI agent extends that question to the execution environment: where do the agent's tool calls, terminal commands, and file accesses run? Self-hosting a model doesn't prevent tool calls from executing on shared infrastructure unless the runtime environment is also isolated.

2. How do enterprises actually verify that an AI agent didn't expose their data?

Verification requires two independent artifacts: a sandbox attestation report proving the runtime environment was hardware-isolated, and inference receipts proving the prompt was processed in a TEE. A ZDR agreement alone verifies policy, not technical controls. Both artifacts are independently checkable without vendor involvement, though against different roots of trust, sandbox attestation verifies against Intel's PKI, while TEE model receipts verify against each provider's attestation scheme (NEAR, Phala, and Tinfoil each produce their own format).

3. Can a private AI agent still use frontier models like Claude or GPT-5?

Yes. Frontier models aren't yet available with TEE inference receipts, but they're accessible through ZDR-tier models via ORGN Gateway. Teams that need frontier model capability use ZDR for inference and rely on sandbox attestation for runtime evidence. The two tiers serve different assurance requirements and can be combined within the same agent deployment.

4. What does TEE attestation actually prove when an AI agent takes an action, and what gaps does it leave?

Sandbox attestation proves the execution environment was genuine TDX hardware running an untampered image. It doesn't prove what the agent did inside that environment or what model handled the inference. Inference TEE receipts prove a specific model call ran in hardware-isolated compute; they don't prove where tool calls executed. A complete evidence package for a regulated deployment requires both artifacts, covering both boundaries independently.