Gateway Security Model and Threat Boundaries
How ORGN Gateway enforces privacy through TEE (hardware-isolated, cryptographically verifiable) and ZDR (policy-enforced zero data retention via Vercel). Threat model, key management, and data handling.
The security model of ORGN Gateway is designed around explicit trust boundaries and minimized assumptions. Rather than relying on policies or access controls alone, Gateway uses hardware-enforced isolation and cryptographic verification where you select TEE models.
This section defines what Gateway is designed to protect against and what it intentionally does not.
Security by execution type
Gateway exposes two types of model execution environments, each with a distinct security model.
Trusted Execution Environment (TEE)
TEE models run on NEAR and Phala infrastructure using Intel TDX confidential virtual machines and NVIDIA H100 GPU attestation. The security guarantee is hardware-enforced:
- Prompts and responses are encrypted in memory, invisible to the host OS, hypervisor, cloud provider, and Gateway operators
- Every request produces a cryptographic attestation receipt independently verifiable against Intel and NVIDIA public PKI
- Zero data retention: no prompts or outputs stored or logged
TEE is the appropriate choice when you need verifiable, hardware-backed proof that inference ran inside an isolated environment and was not accessible to any third party.
Zero Data Retention (ZDR)
ZDR models run on Vercel's AI infrastructure. The security guarantee is policy-enforced:
- Vercel's AI gateway enforces that model providers do not store, log, or use your inference data
- No training on your prompts or responses
- No attestation receipt or cryptographic proof of execution
ZDR provides strong contractual data handling guarantees and access to the broadest frontier model catalog, but without hardware-level isolation or independent verification capability.
| Feature | TEE | ZDR |
|---|---|---|
| Hardware isolation | Yes | No |
| Attestation receipt | Yes | No |
| Data retention | None | None |
| Verification | Cryptographic, independent | Policy and contractual |
| Infrastructure | NEAR, Phala | Vercel |
Threats Gateway is designed to mitigate
Gateway is built to mitigate the following classes of risk:
-
Unauthorized access to prompts and outputs
For TEE models: prompts and responses are processed exclusively inside hardware-isolated Trust Domains. They are never exposed to Gateway services, operators, or underlying infrastructure outside the Trust Domain.
For ZDR models: zero data retention agreements with Vercel and the underlying model providers prevent storage or logging of any inference data.
-
Infrastructure-level compromise (TEE)
Host operating systems, hypervisors, and cloud administrators cannot inspect TEE inference data due to hardware-enforced memory isolation.
-
Malicious or curious insiders
Gateway operators and provider personnel do not have access to plaintext TEE inference data, reducing insider risk to the control plane only.
-
Unverifiable provider behavior (TEE)
Hardware attestation provides cryptographic proof that inference was executed in a trusted environment, removing blind reliance on provider claims.
-
Post-hoc trust failures (TEE)
Each TEE request produces verifiable artifacts, enabling after-the-fact audits and independent validation in Scanner.
Threats outside Gateway's scope
Gateway does not attempt to solve or guarantee protection against:
- Compromised client environments or API key leakage
- Malicious prompts or unsafe model behavior
- Data exposure before requests are sent or after responses are received
- Vulnerabilities inside model weights or training data
- Non-attested execution paths (ZDR routes, or execution outside supported TEEs)
These exclusions are intentional and allow security teams to reason clearly about shared responsibility.
Insider, provider, and infrastructure risks
| Risk surface | Gateway mitigation |
|---|---|
| Gateway operators | TEE: confidential execution prevents access to prompts and outputs. ZDR: policy retention agreements |
| Model providers | TEE: verifiable attestation. ZDR: Vercel ZDR enforcement |
| Cloud infrastructure | TEE: hardware-enforced isolation and encryption-in-use |
| External attackers | Encrypted transport, authenticated access, verified TEE execution |
Encryption and key management
Gateway enforces specific, verifiable encryption protections across the request lifecycle.
Encryption in transit
- All communication between clients, Gateway, and model providers uses industry-standard encrypted transport (TLS).
- Requests, responses, and attestation artifacts are protected from network-level interception.
Encryption in use (TEE)
- Prompts and responses are encrypted in memory while being processed inside TEEs.
- Data remains inaccessible to the host OS, hypervisor, and control plane services.
- Decryption occurs only inside the trusted execution boundary.
Control plane protections
The Gateway control plane handles:
- Authentication and authorization
- Request routing to the user-selected model
- Metadata and verification coordination
It does not process or store plaintext prompts or outputs. Control-plane access is restricted and auditable.
Key ownership and handling
- Encryption and attestation keys are hardware-backed and managed by the underlying TEE platforms.
- Signing keys used for attestation are rooted in vendor-specific hardware trust anchors.
- Gateway does not manage or rotate keys that can decrypt customer inference data.
This design removes Gateway as a key custody risk.
Data handling and retention
Gateway follows a strict zero-retention model for inference content.
Prompts and responses
- Prompts are not stored
- Responses are not stored
- No prompt or output content is logged
- No replayable inference data is retained
Once a request completes, plaintext inference data exists only transiently inside the execution environment and is then discarded.
Logging behavior
Gateway logs non-sensitive operational metadata only, such as:
- Request identifiers
- Model name
- Provider
- Execution status
- Latency and token counts
- Attestation and verification status
This metadata is sufficient for observability and auditing without exposing content.
Console dashboards and visibility
The Gateway console and ORGN Scanner may display:
- Aggregate request counts
- Model and provider usage
- Latency and cost metrics
- Attestation status (e.g., Verified, Pending, Failed)
- Cryptographic hashes and signatures for verification
They never display prompts or responses. Anyone viewing Scanner can see verification outcomes and attestation artifacts, but cannot reconstruct or infer the underlying data.
Retention defaults and controls
- Inference content: not retained
- Attestation artifacts: retained for verification and audit purposes
- Operational metadata: retained for monitoring and billing
This separation enables transparency and auditability without compromising confidentiality.
By combining zero content retention, hardware-backed encryption on TEE routes, and verifiable execution, Gateway provides a security model that is auditable, defensible, and suitable for regulated environments — without requiring customers to trust the platform blindly on TEE paths.
Image & Video Models
Image and video generation models on ORGN Gateway via the OpenAI-compatible API — not wired into the AI SDK provider interface.
Verifiable Privacy and Attestation
How ORGN Gateway provides cryptographic proof of execution integrity for TEE model requests using Intel TDX and NVIDIA GPU hardware attestation — and what ZDR routes do not prove.