Trust Model

How ORGN enforces confidentiality through hardware isolation, cryptographic attestation, and explicit data boundaries — not vendor policy alone.

ORGN's trust model is built on a single principle: not through policy. Through math.

Most AI development tools ask you to trust a vendor's Terms of Service — a promise that your code and prompts won't be logged, trained on, or exfiltrated. ORGN replaces that promise with cryptographically verifiable guarantees where the product architecture supports them, and makes the boundaries explicit everywhere else.

Four-layer stack

Layer	Product	Trust mechanism
IDE	ORGN CDE	Local + cloud execution inside TDX Trust Domains
Platform	ORGN Studio	Project workspaces, agent sessions, repository indexing in TDX
Inference	ORGN Gateway	TEE models (hardware isolation) + ZDR models (contractual zero retention)
Audit	ORGN Scanner	Attestation explorer — verify compute and inference evidence independently

Each layer has a distinct responsibility. This page is the canonical reference; product docs link here rather than restating the full model.

Execution environments

Gateway exposes two inference execution types. Choose based on your assurance requirements.

Trusted Execution Environment (TEE)

TEE models run on NEAR AI and Phala Network infrastructure using Intel TDX confidential virtual machines (and NVIDIA GPU attestation where applicable).

Guarantee: Hardware-enforced isolation.

Prompts and completions are encrypted in memory — invisible to the host OS, hypervisor, cloud operator, and ORGN operators
Each request can produce a cryptographic attestation receipt verifiable against Intel and NVIDIA public PKI
No plaintext inference data stored or logged by Gateway

Use when: You need independent proof that inference ran inside an isolated Trust Domain — regulated workloads, proprietary IP, government contracts, or any scenario where "trust us" is insufficient.

Verify at: scanner.orgn.com → Verify a request

Zero Data Retention (ZDR)

ZDR models run through Vercel AI Gateway to frontier model providers.

Guarantee: Policy-enforced zero data retention.

Vercel and upstream providers contractually agree not to store, log, or train on your inference data
Broadest model catalog (Claude, Gemini, GPT-class, open-weight models)
No hardware attestation receipt — assurance is contractual, not cryptographic

Use when: You need frontier model access with strong data-handling agreements but do not require hardware-level proof of execution.

	TEE	ZDR
Hardware isolation	Yes	No
Attestation receipt	Yes	No
Data retention	None	None (contractual)
Verification	Cryptographic, independent	Policy + contractual
Infrastructure	NEAR AI, Phala	Vercel AI Gateway

Compute trust (CDE and Studio)

Development workloads — your source code, terminal sessions, agent tool calls — run inside Intel TDX Trust Domains, not generic cloud VMs.

A Trust Domain is an isolated execution unit at the VM boundary:

Memory is encrypted and inaccessible to the host OS and hypervisor
The runtime generates a signed attestation report proving what code is running and that it has not been tampered with
Attestation is verifiable by you, not just ORGN

Terminology: TDX uses Trust Domains, not SGX enclaves. They share a goal (confidential compute) but differ in scope, deployment model, and attestation mechanism. Do not conflate them in security reviews.

CDE desktop and Studio cloud workspaces share this compute boundary. Agent sessions inherit the same isolation — agent output does not leave the Trust Domain unattested.

Data boundaries

Understanding what crosses each boundary is essential for security reviews and procurement questionnaires.

What ORGN cannot access (TEE paths)

Plaintext source code inside an active Trust Domain workspace
Plaintext prompts and completions on TEE model routes
Memory contents of a running confidential sandbox

What ORGN can access (control plane)

Account metadata (id-orgn identity, team membership, billing)
API request metadata on Gateway routes (model ID, token counts, latency, attestation status)
Project configuration you explicitly set (environment variable names — not values, which are injected at runtime)
Repository metadata for indexed projects (file paths and structure for context — stored within your workspace boundary)

What you control

Which models to call (TEE vs ZDR)
Which repositories to import
When to run code security scans
Whether to export attestation artifacts for compliance archives

What ORGN Scanner shows vs hides

Scanner is the audit layer for inference and compute evidence:

Visible	Hidden
Request ID, model, provider, status	Prompt contents
Token usage, latency, cost	Model outputs
Attestation status and cryptographic hashes	Plaintext inference data

This is intentional — auditability without surveillance.

Code security vs ORGN Scanner

Two different products answer two different questions:

	Studio Code Security (Shannon)	ORGN Scanner
Question	"What vulnerabilities exist in my codebase?"	"Was this inference request executed in a verified Trust Domain?"
Scope	Repository static/dynamic analysis	Gateway inference + sandbox attestation audit
Output	CWE findings, remediation guidance	Attestation receipts, verification status

See Code security and Scanner overview.

Shared responsibility

ORGN mitigates:

Unauthorized access to code and inference data inside TEE paths
Infrastructure-level compromise of Trust Domain memory
Unverifiable provider claims (via hardware attestation on TEE routes)
Insider access to plaintext inference data on attested paths

ORGN does not guarantee protection against:

Compromised client machines or leaked API keys
Malicious prompts or unsafe model behavior
Data exposure before it enters ORGN or after you receive the response
Vulnerabilities in model weights or training data
Misconfiguration of your own secrets or repository access

Identity boundary

All products authenticate through id-orgn SSO. A single identity spans CDE, Studio, Gateway console, and Scanner — no separate credential silos. See SSO.