Skip to main content

Security

Ovexa is designed with a Zero Trust architecture. Every component assumes that other components may be compromised, and security controls are applied at every layer.

Architecture Overview​

┌─────────────┐    TLS 1.3     ┌───────────────────────────────┐    TLS 1.3    ┌──────────────┐
│  Your App   │ ──────────────> │         Ovexa            │ ─────────────> │ AI Provider  │
│             │ <────────────── │  ┌─────────┐  ┌───────────┐  │ <───────────── │ (OpenAI etc) │
└─────────────┘                 │  │ PII     │  │ Routing   │  │                └──────────────┘
                                │  │ Engine  │  │ Engine    │  │
                                │  └─────────┘  └───────────┘  │
                                │  ┌─────────┐  ┌───────────┐  │
                                │  │ Auth    │  │ Usage     │  │
                                │  │ Layer   │  │ Tracking  │  │
                                │  └─────────┘  └───────────┘  │
                                └───────────────────────────────┘
                                         EU Data Center

Data Flow Security​

Prompts and Responses​

  1. In transit -- All connections use TLS 1.3. Ovexa terminates TLS at the edge and re-encrypts when forwarding to AI providers.
  2. PII processing -- PII detection and anonymization happen entirely in RAM. No prompt content is ever written to disk.
  3. Temporary retention -- Original PII values are held in memory for up to 60 seconds during request processing, then discarded.
  4. No content logging -- Ovexa never logs, stores, or caches the content of prompts or AI responses. Only metadata (token counts, model used, timestamps, PII type counts) is persisted.

Provider Keys​

  • Encrypted at rest using AES-256-GCM
  • Encryption keys are stored in a separate key management service, never in the application database
  • Decrypted only in memory at the moment of forwarding a request to the upstream provider
  • Immediately discarded after use

Ovexa API Keys​

  • Stored as SHA-256 hashes -- the plain-text key is never stored
  • Keys follow the vpx_live_ / vpx_test_ prefix convention for easy identification
  • Revocation takes effect immediately

Zero-Knowledge Architecture​

Ovexa follows a Zero-Knowledge Architecture principle: the system is designed so that Ovexa itself never has persistent access to your sensitive data.

  • No content persistence -- Prompts, AI responses, and PII values are processed entirely in RAM and are never written to disk, logged, or stored in any database.
  • Ephemeral PII mappings -- PII-to-placeholder mappings exist only in Redis (in-memory) with a 60-second TTL and are deleted immediately after the response is de-anonymized.
  • Encrypted provider keys -- Your upstream API keys are encrypted with AES-256-GCM. The encryption key is managed separately from the application database. Ovexa decrypts them only in memory at the instant of forwarding a request.
  • Hashed API keys -- Ovexa API keys are stored as SHA-256 hashes. Even with full database access, the original keys cannot be recovered.
  • No training data -- Ovexa never uses your data for training, analytics, or any purpose beyond fulfilling the immediate request.

This means that even in the event of a full database breach, an attacker would find no prompt content, no PII values, no plain-text provider keys, and no plain-text Ovexa API keys.

EU Hosting​

All Ovexa infrastructure is hosted within the European Union:

  • Application servers: EU data centers
  • Database: EU-hosted PostgreSQL with encryption at rest
  • No data replication outside the EU
  • All processing occurs within EU jurisdiction
info

When Ovexa forwards a request to an AI provider, that provider's data processing policies apply. For example, if you use OpenAI, your (anonymized) prompt is processed according to OpenAI's data use policy. Ovexa ensures PII is removed before this happens.

RODO / GDPR Compliance​

Ovexa supports organizations in meeting their RODO/GDPR obligations:

RequirementHow Ovexa Helps
Data minimization (Art. 5(1)(c))PII is stripped before forwarding to AI providers, minimizing data exposure
Purpose limitation (Art. 5(1)(b))Provider keys and settings are scoped per use case
Storage limitation (Art. 5(1)(e))PII is held in RAM for max 60 seconds; no persistent storage of personal data
Integrity and confidentiality (Art. 5(1)(f))AES-256 encryption, TLS 1.3, zero content logging
Special categories (Art. 9)Art. 9 data detection and flagging/blocking
Data processing agreementDPA available for Enterprise customers

Data Processing Agreement (DPA)​

Enterprise customers receive a Data Processing Agreement that covers:

  • Nature and purpose of processing
  • Types of personal data processed
  • Categories of data subjects
  • Sub-processor list
  • Data breach notification procedures
  • Data deletion upon contract termination

Contact [email protected] for DPA requests.

What Ovexa Does NOT Store​

To be explicit about data handling:

DataStored?Details
Prompt contentNoProcessed in RAM only
AI responsesNoStreamed through, not persisted
Original PII valuesNoHeld in RAM for max 60s
Provider API keys (plain text)NoOnly AES-256 encrypted form
Ovexa API keys (plain text)NoOnly SHA-256 hashes
Request metadataYesTimestamps, token counts, model, PII type counts
Usage statisticsYesAggregated daily/monthly metrics

Incident Response​

Ovexa maintains an incident response procedure:

  1. Detection -- Automated monitoring and alerting for anomalous patterns
  2. Containment -- Affected systems are isolated within 30 minutes
  3. Notification -- Customers are notified within 72 hours per RODO Art. 33 requirements
  4. Resolution -- Root cause analysis and remediation
  5. Post-mortem -- Published to affected customers

Reporting Vulnerabilities​

If you discover a security vulnerability, please report it responsibly:

  • Email: [email protected]
  • We acknowledge reports within 24 hours
  • We aim to resolve critical issues within 48 hours