Privacy-First Architecture

Privacy is Our Core Mission

RedPill was built from the ground up with privacy as the foundation, not an afterthought. Every architectural decision prioritizes protecting your data with hardware-level security guarantees.

Privacy Layers

Layer 1: TEE-Protected Gateway

The entire gateway infrastructure runs in Trusted Execution Environments: All pink nodes run inside TEE - your data never leaves hardware protection.

Layer 2: Transport Encryption

All connections use TLS 1.3
Perfect forward secrecy (PFS)
Strong cipher suites only
Certificate pinning available

Layer 3: Memory Encryption

Inside TEE, all data is encrypted in memory:

AES-256 encryption
CPU-enforced isolation
No swapping to disk
Secure deletion after processing

Layer 4: Confidential AI Models

Optional Phala models run entirely in GPU TEEs:

Model weights protected in TEE
Inference in secure enclaves
No model extraction possible

What We Protect

Your Prompts

All user messages and system prompts

Model Responses

Complete AI-generated responses

Function Calls

Function names and parameters

Embeddings

Input text for embeddings

Images

Vision model image data

Metadata

Custom metadata and headers

Privacy Guarantees

What RedPill CANNOT Access

Even with full system administrator access, RedPill operators cannot see:

Data Type	Accessible to RedPill?	Protection
Prompt content	❌ No	TEE-encrypted
Response content	❌ No	TEE-encrypted
API keys	❌ No (hashed)	Hashed with bcrypt
Function parameters	❌ No	TEE-encrypted
Embedding inputs	❌ No	TEE-encrypted
Image data	❌ No	TEE-encrypted
Custom metadata	❌ No	TEE-encrypted

What RedPill CAN See

For operational and billing purposes only:

Data Type	Purpose	Details
User ID	Account management	Hashed identifier
Model selected	Billing	e.g., “gpt-4”
Token count	Billing	Number only, not content
Timestamp	Rate limiting	Request time
Error codes	Debugging	No sensitive data
IP address	Rate limiting	Hashed for privacy

Data Retention

Data Type	Retention Period
Request content	0 days - Never stored
Response content	0 days - Never stored
Billing metadata	90 days
Error logs (no sensitive data)	30 days
Attestation reports	Available on request

Threat Model

Threats We Protect Against

1. Malicious Cloud Provider

Threat: Cloud infrastructure provider tries to access your data.Protection: TEE ensures even the host OS cannot access enclave memory. Your data remains encrypted and inaccessible.

2. Compromised RedPill Operator

Threat: A rogue RedPill employee tries to steal data.Protection: Operators have zero access to TEE memory. Administrative access cannot decrypt TEE-protected data.

3. Server Breach

Threat: Attacker gains root access to RedPill servers.Protection: TEE isolation prevents root users from accessing enclave memory. Attestation proves genuine TEE execution.

4. Memory Dump Attack

Threat: Attacker tries to dump server memory to steal data.Protection: TEE memory is hardware-encrypted. Memory dumps show only encrypted data.

5. Supply Chain Attack

Threat: Malicious code injected into gateway software.Protection: Attestation includes code measurements. Modified code produces different attestation hash.

6. Man-in-the-Middle

Threat: Network attacker intercepts traffic.Protection: TLS 1.3 with PFS encrypts all traffic. Certificate pinning prevents MITM.

Trust Assumptions

You must trust:

CPU Vendor (Intel, AMD, ARM) - TEE hardware correctness
Cryptographic Algorithms - AES, RSA, ECDSA security
Open Source Gateway Code - Auditable on GitHub

You do NOT need to trust:

❌ RedPill operators
❌ Cloud infrastructure provider
❌ Operating system
❌ Other applications on the server

Compliance & Regulations

RedPill’s TEE architecture supports compliance with major regulations:

HIPAA (Healthcare)

✅ Covered Entity Requirements:

Encryption at rest and in transit
Access controls (TEE isolation)
Audit logs
Data integrity guarantees

✅ Business Associate Agreement:

Available for healthcare customers
TEE attestation as audit evidence

✅ Data Protection Requirements:

Data minimization (zero retention)
Purpose limitation
Privacy by design (TEE architecture)
Right to erasure (no data stored)
Data portability

✅ Security Measures:

Pseudonymization (hashed IDs)
Encryption
Ability to restore availability
Regular testing

SOC 2 Type II

RedPill is pursuing SOC 2 certification:

Principle	Status
Security	✅ TEE provides technical controls
Availability	✅ Load balancing & redundancy
Processing Integrity	✅ Attestation proves correct execution
Confidentiality	✅ TEE encryption
Privacy	✅ Zero data retention

Other Regulations

CCPA (California) - Consumer privacy protection
ISO 27001 - Information security management
PCI DSS - Payment card data (for future features)

Privacy-Preserving Features

1. Zero-Knowledge Architecture

RedPill cannot know what you’re processing:

# Your code
client.chat.completions.create(
    model="openai/gpt-4o",
    messages=[
        {"role": "user", "content": "My secret trading strategy: ..."}
    ]
)

# RedPill sees:
# - model="openai/gpt-4o"
# - tokens_used=150
# - timestamp
# BUT NOT YOUR CONTENT

2. No Logging of Sensitive Data

// What gets logged (no sensitive data):
{
  "user_id_hash": "a3f8...",
  "model": "openai/gpt-4o",
  "tokens": 150,
  "status": "success",
  "timestamp": "2025-01-15T10:30:00Z"
}

// What NEVER gets logged:
// - Your prompts ❌
// - Model responses ❌
// - Function parameters ❌
// - Any request content ❌

3. Cryptographic Proof

Get verifiable proof of privacy:

# Request attestation report
curl https://api.redpill.ai/v1/attestation/report \
  -H "Authorization: Bearer YOUR_API_KEY"

# Returns:
# - TEE hardware measurements
# - Code integrity hash
# - Cryptographic signature
# - Certificate chain

Verify Attestation

Learn how to verify TEE execution →

Privacy Best Practices

For Developers

Use Environment Variables

Store API keys securely, never hardcode

export REDPILL_API_KEY="sk-..."

Implement Rate Limiting

Prevent abuse and protect your quota

Verify Attestation

For high-security workloads, verify TEE execution

Use HTTPS Only

Never make unencrypted requests

For Enterprises

Conduct Security Audit

Review RedPill’s open source gateway code
Verify attestation implementation
Test with sample sensitive data

Implement Access Controls

Separate API keys per team/environment
Use role-based access control (RBAC)
Rotate keys regularly

Monitor Usage

Set up usage alerts
Review audit logs
Track API key usage patterns

Data Classification

Use RedPill for sensitive data requiring TEE
Use regular APIs for non-sensitive workloads
Document data handling procedures

Open Source Transparency

Auditable Code

RedPill’s gateway is open source on GitHub:

git clone https://github.com/redpill-ai/gateway
cd gateway
# Review TEE integration
cat src/tee/attestation.ts
# Review privacy controls
cat src/privacy/isolation.ts

Community Audits

Security researchers welcome
Bug bounty program
Public disclosure of vulnerabilities
Regular security updates

View on GitHub

Audit the code yourself →

Comparison with Competitors

Privacy Features Matrix

Feature	RedPill	Tinfoil	OpenRouter	Direct APIs
Gateway in TEE	✅ Yes	❌ No	❌ No	❌ No
All requests protected	✅ Yes	❌ Only specific models	❌ No	❌ No
Cryptographic attestation	✅ Yes	✅ Yes	❌ No	❌ No
Open source gateway	✅ Yes	❌ No	❌ No	❌ No
Zero data retention	✅ Yes	✅ Yes	❌ Unknown	❌ Provider-dependent
Multi-provider support	✅ 218+ models	❌ Limited	✅ Yes	❌ No
Verifiable privacy	✅ Yes	✅ Yes	❌ No	❌ No

FAQs

Can RedPill employees read my prompts?

No. Prompts are processed inside TEE. Even system administrators cannot access TEE memory.

Is my data stored anywhere?

No. Request and response content is never stored. Only billing metadata (token counts, model names) is retained for 90 days.

What happens if there's a data breach?

TEE isolation means attackers cannot access your data even with full server access. At most, they could see encrypted metadata.

Can I audit RedPill's privacy claims?

Yes! The gateway code is open source. You can also request attestation reports to verify TEE execution.

Does using OpenAI through RedPill protect my data from OpenAI?

RedPill protects data in transit and during gateway processing. However, once forwarded to OpenAI, their privacy policy applies. For full end-to-end TEE protection, use Phala confidential models.

How does this compare to using VPN?

VPN only protects network traffic. RedPill provides hardware-level protection during processing, which VPN cannot offer.

Next Steps

TEE-Protected Gateway

Learn about TEE architecture

Attestation & Verification

Verify TEE execution cryptographically

Confidential AI Models

End-to-end TEE protection

Get Started

Start building with privacy-first AI

Get Started

Core Concepts

Guides

​Privacy is Our Core Mission

​Privacy Layers

​Layer 1: TEE-Protected Gateway

​Layer 2: Transport Encryption

​Layer 3: Memory Encryption

​Layer 4: Confidential AI Models

​What We Protect

Your Prompts

Model Responses

Function Calls

Embeddings

Images

Metadata

​Privacy Guarantees

​What RedPill CANNOT Access

​What RedPill CAN See

​Data Retention

​Threat Model

​Threats We Protect Against

​Trust Assumptions

​Compliance & Regulations

​HIPAA (Healthcare)

​GDPR (Europe)

​SOC 2 Type II

​Other Regulations

​Privacy-Preserving Features

​1. Zero-Knowledge Architecture

​2. No Logging of Sensitive Data

​3. Cryptographic Proof

Verify Attestation

​Privacy Best Practices

​For Developers

​For Enterprises

​Open Source Transparency

​Auditable Code

​Community Audits

View on GitHub

​Comparison with Competitors

​Privacy Features Matrix

​FAQs

​Next Steps

TEE-Protected Gateway

Attestation & Verification

Confidential AI Models

Get Started

Privacy is Our Core Mission

Privacy Layers

Layer 1: TEE-Protected Gateway

Layer 2: Transport Encryption

Layer 3: Memory Encryption

Layer 4: Confidential AI Models

What We Protect

Privacy Guarantees

What RedPill CANNOT Access

What RedPill CAN See

Data Retention

Threat Model

Threats We Protect Against

Trust Assumptions

Compliance & Regulations

HIPAA (Healthcare)

GDPR (Europe)

SOC 2 Type II

Other Regulations

Privacy-Preserving Features

1. Zero-Knowledge Architecture

2. No Logging of Sensitive Data

3. Cryptographic Proof

Privacy Best Practices

For Developers

For Enterprises

Open Source Transparency

Auditable Code

Community Audits

Comparison with Competitors

Privacy Features Matrix

FAQs

Next Steps