Origin Docs
Security

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.

FeatureTEEZDR
Hardware isolationYesNo
Attestation receiptYesNo
Data retentionNoneNone
VerificationCryptographic, independentPolicy and contractual
InfrastructureNEAR, PhalaVercel

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 surfaceGateway mitigation
Gateway operatorsTEE: confidential execution prevents access to prompts and outputs. ZDR: policy retention agreements
Model providersTEE: verifiable attestation. ZDR: Vercel ZDR enforcement
Cloud infrastructureTEE: hardware-enforced isolation and encryption-in-use
External attackersEncrypted 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.

On this page