The Case for Confidential Computing in Software Development

TL;DR

• AI coding tools send more than code. Accumulated context, schemas, auth logic, internal service names, and architecture patterns are all processed on shared infrastructure under policy-based protections.
• Self-hosting solves data egress but hits a hard capability ceiling at the model sizes that matter for serious work.
• Enterprise internal clusters push the perimeter further in, but add real maintenance overhead and still don't solve tool-calling exposure.
• MCP and agent tool calls are the gap nobody has closed. Agents construct queries from your codebase context and send them to external services; self-hosting the model doesn't prevent this.
• Confidential computing moves the enforcement point from vendor policy to hardware. Your code is processed inside an encrypted execution boundary that even the infrastructure provider can't inspect, with cryptographic proof of execution rather than a contractual promise.

The Privacy Problem AI Coding Tools Quietly Created

Somewhere between the first autocomplete suggestion and the tenth AI-assisted refactor, most engineering teams crossed a line they didn't notice: their codebase started living in someone else's infrastructure.

AI coding tools are genuinely useful. They're also, by design, context-hungry. To give good suggestions, they need to understand your code, not just the file you have open, but the schema it queries, the service it calls, the auth logic it sits behind. That accumulated context is exactly what makes them useful. It's also exactly what's being sent through infrastructure you don't own, processed in memory you can't inspect, on hardware shared with everyone else using the same platform.

Most teams handle this the way they handle most vendor security questions: they read the privacy policy, note the SOC 2 certification, and move on. That's a reasonable response to a contractual question. It's not a sufficient response to a technical one. A privacy policy tells you what a vendor promises to do. It says nothing about what their infrastructure is capable of doing, and those are different things.

This piece is about that gap: specifically, how AI-assisted development creates exposure that standard workarounds don't fully close, and what it would actually take to close it.

What Developers Are Actually Sending Through AI Tools

The instinct most developers have is to think about AI tool exposure in terms of files, a specific function, a component, a config. That's not how context windows work in practice.

A real working session is additive. You open a file, the tool pulls in imports. You ask about a bug, it needs the schema. You ask about the schema, it needs the service that writes to it. By the time you're twenty minutes into debugging a non-trivial problem, the model's context contains a cross-section of your system that no single file would reveal on its own.

Consider a developer debugging a failure in a payments webhook. The context window at that point likely contains: the webhook handler, the retry logic, the transaction table schema, and the error logs from the last failure. None of those is incidentally sensitive, together, they describe exactly how your payment system is built and where it's fragile.

Or a developer building a KYC verification flow. The prompt context includes the identity verification logic, the third-party API integration, and the edge-case handling. The competitive value of that code is in precisely those details, the decisions made around the edges, not the happy path.

In a typical AI-assisted session, the context window can contain:

• Database schemas with field names that reveal business logic
• Authentication and authorization flows
• Internal service names and architecture patterns
• API integration details and credentials in environment variable references
• Incident reproduction steps with production data shapes
• Proprietary model architectures or training pipeline logic

The point isn't that any one of these is catastrophic in isolation. It's that AI tools are specifically designed to accumulate and connect exactly this kind of context, and that accumulated picture is what's being processed on shared infrastructure, under policy-based protections, every session.

Three Ways Developers Try to Manage This and Where Each Falls Short

Most engineering teams aren't ignoring the exposure problem, they've just landed on responses that solve part of it. The issue is that each response was designed for a simpler version of the threat: one in which the risk is the model endpoint; data either reaches it or it doesn't, and controlling that boundary is enough. That framing worked when AI tools were used as an autocomplete. It doesn't hold anymore. Here's where each approach lands today.

Accepting the Vendor's Privacy Policy and Moving On

This is the default. The vendor has a SOC 2. The enterprise agreement has a no-training clause. Privacy mode is on. Most security reviews stop there, because those are the right questions to ask of a SaaS vendor in most contexts.

The problem is that these are contractual guarantees, not technical ones. Your code is still decrypted and processed in plaintext memory on shared GPU infrastructure. The host OS, the hypervisor, and the observability stack all have visibility into that execution. The policy says the vendor won't look. Nothing in the architecture prevents them from looking, or from a misconfigured logging system doing it accidentally.

A company can sign a thorough enterprise agreement, pass a security audit six months later, and, when the auditor asks, "What were the isolation guarantees for this code?" the honest answer is: shared cloud infrastructure under a contractual no-retention promise. That's a policy posture. It's not an enforcement boundary.

Self-Hosting the Model

The instinct is correct: if the model runs on your hardware, the data doesn't leave your environment. For individual developers on capable workstations, or small teams running 7B–13B models locally via Ollama or LM Studio, this works.

It stalls at the point where the work gets serious.

The models that handle complex, multi-file, production-grade coding tasks are 70B+ parameters or mixture-of-experts architectures. Running a properly quantized version of those locally means real capability degradation, missed cross-file dependencies, more hallucinated API calls, and more prompt engineering to reach the same output quality you'd get from a hosted frontier model. The privacy win is real. The capability cost is also real, and it compounds as tasks become harder.

The team dimension makes it worse. Self-hosting for one developer is a personal setup. Self-hosting for a fifteen-person engineering team means GPU procurement, inference server management, and model version control, and someone's plate now has a platform engineering problem that didn't exist before.

Building an Internal Enterprise Cluster

Larger organizations do this properly: a private GPU cluster, VPN-gated access, an internal API gateway, and team-scoped keys. A 400-person fintech running an internal Llama 3.1 70B deployment with VPN-only access is genuinely more secure than a vendor policy promise. This is the right instinct taken to its logical conclusion.

It solves the external exposure problem but it doesn't solve the internal one.

The cluster admins, the hypervisor layer, and the logging stack still have visibility into execution-time data. "Internal" doesn't mean "zero visibility", it means the trust perimeter moved inward. An insider threat or a compromised internal system still has access to what's being processed. And the maintenance overhead is real and ongoing: GPU driver updates, inference server reliability, cost allocation between teams, model updates. Internal AI platform teams routinely spend more engineering hours maintaining the cluster than developers using it save.

Neither approach, self-hosting nor internal clusters, has solved the problem that comes next.

Why Agent Tool Calls Are the Data Boundary Problem Nobody Has Properly Solved Yet

The previous section covered three responses to AI privacy exposure, each reasonable, each with real gaps. But all three share an assumption worth making explicit: that the risk lives at the model endpoint. Control what reaches the model, and you've controlled the exposure. That assumption was never perfectly true, and for teams using AI agents today, it's broken entirely.

Modern AI agents don't just process code, they act on it. They call tools: web search, GitHub, Jira, Slack, internal documentation systems, database queries, external APIs. The Model Context Protocol has made this dramatically more capable and, critically, dramatically less transparent about where data goes.

The exposure mechanism is specific. When an agent constructs a tool call or a web search query, it assembles that query from the context it holds. That context is your codebase, your error messages, your internal service names, your architecture patterns. The query that leaves your environment isn't raw code; it's built from it and carries the shape of your system in ways that aren't obvious until you look closely.

Two concrete examples make this clearer:

Example 1: A developer uses an AI agent to debug a production authentication failure. The agent runs a web search with a query that includes the internal service name, the specific JWT validation error signature, and enough structural detail that someone reading the query could infer meaningful things about the system architecture. That query goes to a public search API. The model is self-hosted. The data left anyway.

Example 2: An enterprise team has an AI agent connected to both an internal documentation MCP server and a public GitHub MCP server. The agent decides what context to include in each call. The developer has no log of what was assembled and sent to which endpoint. The boundary between "internal" and "sent externally" is now the agent's decision, not a human's, and it's not auditable afterward.

This is the gap that neither self-hosting nor internal clusters close. If your locally running model makes tool calls to external services, data leaves your controlled environment through those calls, regardless of where the model runs. The perimeter has a hole in it by design, because usefulness requires external calls, which require sending context.

The gap expands as agents get more capable. More tools means more surfaces through which context leaves. And right now, most teams have no visibility into what's being assembled and sent.

What Confidential Computing Actually Changes About This Problem

The previous sections built up a clear picture of where exposure occurs: shared infrastructure at the model endpoint, internal visibility within enterprise clusters, and context leaking through agent-constructed tool calls. Confidential computing doesn't address all of these equally, but it shifts the enforcement boundary in ways that matter for each.

The core mechanism: confidential computing runs workloads inside a Trusted Execution Environment (TEE), where memory is encrypted and access is restricted at the CPU level. The host OS, the hypervisor, and the infrastructure provider's observability stack cannot inspect what's being processed inside the enclave, not because of a policy, but because the hardware enforces the boundary.

How it maps to each problem:

Problem

What Changes With Confidential Computing

Shared infrastructure visibility

Code is processed inside an encrypted hardware boundary. The vendor's policy is no longer the primary control; the CPU enforces isolation regardless of how logging or observability is configured.

Internal cluster visibility

Cluster admins and internal observability stacks lose visibility into execution-time data. The enclave boundary holds at the CPU level, not the network level. VPN perimeter and TEE isolation are not the same thing.

MCP tool call assembly

If the model and agent orchestration layer runs inside a TEE, the host system cannot inspect the context being assembled before a tool call goes out. The external call still happens, but the assembly is protected.

Audit evidence

Attestation produces a cryptographic record of what ran and where. Security reviews stop relying on policy documents and start relying on hardware-generated proof.

What confidential computing doesn't do:

• It doesn't prevent data from leaving through tool calls once they're made
• It doesn't control where tool-call responses go after they return to the enclave
• It doesn't protect outputs written to insecure downstream systems after execution
• The boundary is at execution, not at every downstream touchpoint

The shift is this: instead of asking "do I trust this vendor's promises about my data?" the question becomes "can I verify, cryptographically, what ran and where?" That's a different class of answer, and it's the one that holds up under audit.

How ORGN Puts Confidential Computing to Work by Default

Most security features in developer tooling are opt-in. You enable them after an audit, after a compliance requirement surfaces, or after something goes wrong. ORGN takes the opposite approach, confidential computing is the default execution model, not a configuration choice.

Every workspace runs inside a TDX Sandbox with Intel TDX-encrypted CPU and memory from the moment it starts. There's no "secure mode" to enable. There's no tier of the product where isolation is a premium feature. The hardware boundary is just where execution happens.

What that looks like at the request level:

• ORGN confidential model inference runs with Intel TDX and NVIDIA GPU Attestation verified per request. The attestation status is visible in the ORGN console, a cryptographic record tied to that specific execution, not a general policy statement about the platform.
• Data persistence is off by default. No prompts, code, or outputs are stored or used for AI training. The only data retained is token metadata for billing. Standard gateway models remain subject to their respective provider policies.
• Attestation is per-request, not per-deployment. Teams don't verify the environment once at setup and trust it thereafter, each execution produces its own verifiable record.

The practical result for a developer: access to frontier models, hardware isolation, no local GPU, no cluster to maintain. For a regulated enterprise team: the same isolation guarantees, with cryptographic audit evidence built into every session rather than assembled after the fact from vendor documentation.

Conclusion: Why Hardware Enforcement Is the Only Honest Answer to Runtime Exposure

The through-line of this piece is simple: every response most engineering teams have to AI privacy concerns, accept the policy, self-host, build an internal cluster, was designed for a world where exposure is a perimeter problem. Control what crosses the boundary, and you've controlled the risk.

That world ended when AI tools gained the ability to act. Agents construct queries from your codebase and send them to external services. The boundary between "inside" and "outside" is now a decision the agent makes, not one you enforce at the network level.

Confidential computing doesn't ask you to trade capability for privacy. It moves enforcement from the policy layer to the hardware layer, from what a vendor promises to what a CPU enforces, and makes execution verifiable through attestation rather than assumed through trust.

To go deeper, ORGN's technical breakdown of how TEEs work at the execution layer is a good next read, alongside the documentation on how attestation works in practice and what it produces at the request level. For teams ready to move past documentation, self-serve access starts at $20 in prepaid credits with no subscription at orgn.com.

FAQ

If I self-host a model, isn't my code already private?

Partially, but less than it seems. Self-hosting prevents your code from reaching a vendor's servers, but it doesn't protect execution-time data from the host OS, hypervisor, or any monitoring tools running on your own infrastructure. The bigger gap is in tool calls: if your locally running model queries an external service, data leaves through that call regardless of where the model runs. Self-hosting moves the perimeter. It doesn't eliminate it.

What's the actual risk with MCP tool calls? Isn't the model just doing a web search?

The risk isn't the search itself, it's what the agent includes in the query. Agents construct queries from accumulated context, which can include internal service names, error signatures, schema patterns, and architecture details. A web search query assembled from your codebase context carries information about your system even if you never explicitly shared it. The output of that query also returns into the agent's context, potentially mixing external data with internal state in ways that aren't logged or auditable.

How is confidential computing different from running everything behind a VPN?

A VPN controls network access; it determines who can reach your infrastructure. It says nothing about what happens to data in memory once it arrives at a compute node. Confidential computing protects data during execution, at the CPU level, regardless of network perimeter. An insider with legitimate cluster access, or a compromised internal system, can still reach execution-time data behind a VPN. Inside a TEE, the hardware boundary holds independent of who has network access.

Does this apply to solo developers, or only enterprise teams?

Both. Solo developers handle proprietary code, sensitive architecture decisions, and production context the same way enterprise teams do; they just have fewer resources to build mitigations around it. The capability tradeoff with self-hosting hits individual developers harder, not easier, because there's no platform team to absorb the overhead. ORGN's credit-based pricing, with no subscription, is specifically designed for individual developers who need access to frontier models without the infrastructure burden.

What does attestation actually prove, and can I check it myself?

Attestation produces a cryptographic signature generated by the CPU that proves three things: what code is running, on what hardware, and that the execution environment hasn't been altered from its expected state. It's not a claim the vendor makes about their platform, it's a measurement the hardware produces about a specific execution. For ORGN confidential model sessions, ORGN surfaces attestation status at the request level through the platform interface. Teams can verify that a specific request was processed within a valid enclave rather than relying on a general policy statement on faith.