Security Architecture
A complete, honest description of how persīv codex handles your data, what we can see, and what we can't.
Last updated: February 2026
Contents
01 Architecture Overview
Data Flow Diagram
persīv codex operates as a transparent proxy between your AI client and AI providers (OpenAI, Anthropic). Every request flows through our gateway, where we apply cost optimizations before forwarding to the upstream provider.
Important: Plaintext Visibility in Cloud Mode
In cloud deployment, your prompt and response content is visible in plaintext in our gateway's process memory during request handling. This is a fundamental requirement for caching and optimization to work. Content is encrypted before any persistence and is not written to disk in plaintext. For organizations that cannot accept this, we offer self-hosted deployment.
What is stored: Cache entries (encrypted), metadata (model, token counts, cost, timestamps, request fingerprints), audit logs (configurable content capture level).
What is NOT stored: Plaintext prompts or responses are never persisted to disk or database in unencrypted form. API keys are hashed (SHA-256) before storage.
02 Trust Model by Deployment
Cloud Deployment
| Aspect | Status |
|---|---|
| Content visible during transit | Yes — in process memory |
| Content persisted in plaintext | No — encrypted at rest |
| Metadata stored | Yes — model, tokens, cost, timestamps |
| Encryption | AES-256-GCM with BYOK option |
| Crypto-shred capability | Yes — immediate key deletion |
| persīv codex employee access | Infrastructure access only, no content access |
Self-Hosted Deployment
| Aspect | Status |
|---|---|
| Content visible to persīv codex | No — runs in your infrastructure |
| Data leaves your network | Only to AI providers (your choice) |
| Metadata visible to us | No — unless you opt into telemetry |
| Encryption keys | Fully controlled by you |
| persīv codex employee access | Zero — no access to your infrastructure |
| Air-gap capable | Yes — no phone-home required |
Hybrid Deployment
| Aspect | Status |
|---|---|
| Gateway | Self-hosted in your VPC |
| Dashboard & analytics | persīv codex cloud (metadata only) |
| Content visible to persīv codex | No — gateway is in your network |
| Metadata shared | Yes — aggregated usage metrics for dashboard |
03 Encryption Specifications
Envelope Encryption Architecture
BYOK (Bring Your Own Key)
Customers on Pro and Enterprise plans can provide their own master encryption key. This key is used to wrap/unwrap DEKs and is never stored by persīv codex.
- •Key rotation: Supported. Old DEKs remain wrapped with old master key until content expires or is re-encrypted.
- •Key revocation: Revoking your master key immediately makes all encrypted content unreadable (crypto-shred).
- •Key format: 256-bit key provided as base64 or hex. Transmitted over TLS only during initial configuration.
Transport Security
TLS 1.3 enforced on all connections. TLS 1.2 and below rejected. HSTS enabled with 1-year max-age.
Certificate pinning available for enterprise self-hosted deployments.
04 What Metadata Can Reveal
Honest Disclosure
Even with content encryption, metadata can reveal information about your usage. We believe you should understand what can be inferred from metadata we store.
- • Timestamp of each request — reveals when your team is active
- • Model name — reveals which AI models you use
- • Token counts (input/output) — reveals request complexity and response length
- • Cost — reveals your spend patterns
- • Request fingerprint (hash) — reveals repeated queries (not content)
- • Latency — reveals response time patterns
- • API key ID — reveals which team member made the request
- • Cache hit/miss — reveals repetition patterns
- • Team work schedules and productivity patterns
- • Rough project complexity based on token volumes
- • Technology choices based on model selection
- • Development velocity based on request frequency
For organizations where even metadata is sensitive, self-hosted deployment keeps all data in your infrastructure.
05 Tenant Isolation
Database isolation: All data is scoped by org_id. Every database query includes tenant filtering enforced at the application layer. Row-level security policies provide a second layer of defense.
Cache isolation: Cache keys are prefixed with org:{org_id} ensuring one tenant cannot read another tenant's cached responses. Each org uses a separate encryption key for cache entries.
API key isolation: API keys are hashed (SHA-256) and mapped to a single org. Cross-org access is not possible even with a valid key from another organization.
Network isolation (Enterprise): Enterprise self-hosted deployments run in completely isolated infrastructure with no shared resources.
06 Employee Access Controls
Principle of least privilege: persīv codex employees have access to infrastructure management only. No employee has standing access to customer data, encrypted or otherwise.
Break-glass procedures: Emergency access to production databases requires multi-party approval, is time-limited, and is fully audited. All access attempts are logged.
Content access: Even with infrastructure access, customer content is encrypted. Without the customer's encryption key (or BYOK master key), content cannot be read.
Background checks: All employees with infrastructure access undergo background verification.
Offboarding: Access revoked immediately upon departure. Credentials rotated within 24 hours.
07 Subprocessors
Complete list of third-party services that may process data on behalf of persīv codex customers. We commit to updating this list before adding any new subprocessor.
| Service | Purpose | Data Processed | Location |
|---|---|---|---|
| Fly.io | Application hosting & compute | All request data (in memory during processing) | US (configurable) |
| Neon | PostgreSQL database | Encrypted content, metadata, user accounts | US |
| Upstash | Redis cache | Encrypted cache entries, rate limit counters | US |
| OpenAI | LLM provider (passthrough) | Request content (plaintext, as submitted by user) | US |
| Anthropic | LLM provider (passthrough) | Request content (plaintext, as submitted by user) | US |
LLM providers receive exactly what the user sends. persīv codex does not add, modify, or inject content into provider-bound requests (except for memory injection, which is user-configured and visible in the dashboard).
08 Contact & Security Reporting
Security questions: security@persivcodex.com
Vulnerability reports: security@persivcodex.com — We respond within 24 hours. Please include steps to reproduce and impact assessment.
DPA requests: legal@persivcodex.com — Data Processing Agreements available for Pro and Enterprise customers.
Compliance documentation: Available upon request for Enterprise customers, including penetration test reports, infrastructure diagrams, and access control documentation.