What is VectaX?
VectaX is Mirror Security's encryption layer for AI pipelines. It addresses a problem that no standard encryption tool solves: how to protect AI data without breaking AI functionality.
Standard AES encryption secures data at rest, but it destroys the mathematical properties that make machine learning work. You cannot compute cosine similarity between two encrypted vectors. You cannot run a model on an encrypted input. VectaX uses three specialised encryption techniques that preserve the properties AI needs while keeping data confidential end-to-end.
The Problem with Plaintext Vector Stores
Every embedding is a compressed representation of the data that produced it. A RAG pipeline storing patient note embeddings holds a recoverable form of that data.
Any database breach, insider threat, or infrastructure compromise exposes the contents. Nearest-neighbour queries can be used to recover information about the original documents from their embeddings alone. Standard encryption solves the breach risk but breaks similarity search entirely. You end up choosing between security and the core feature that makes RAG useful. VectaX removes that choice.
How Encrypted Memory Works
VectaX encrypts embeddings so that relative distances between vectors are maintained in the ciphertext. A cosine similarity search on encrypted vectors returns the same ranked results as the same search on their plaintext originals. The vector database holds only ciphertext at all times.
Role-Based Access Control
Encrypting vectors is necessary but not sufficient. Without access control, anyone with the decryption key reads everything. VectaX ties decryption rights to organisational roles through a multi-dimensional key system.
Access keys are scoped simultaneously by role, group, and department. A user who matches two of three required dimensions is denied. Partial matches grant no access. A data scientist with model-training permissions does not automatically get access to patient record embeddings.
clinical_team), the group (e.g. oncology), and the department (e.g. patient_records). A user key is generated per-user and scoped to their actual dimensions.
Metadata Encryption with FPE
Most vector stores attach metadata to each embedding: document source, date, patient ID, classification tier. This metadata often contains the most sensitive fields. Format-Preserving Encryption encrypts this data while keeping its format intact, so existing database queries continue to work. No schema changes are required.
FPE uses a context-bound tweak generated from the metadata itself, ensuring that the encryption is specific to each record's context and cannot be replayed across records.
Standard RAG vs VectaX Encrypted RAG
| Aspect | Standard RAG | VectaX Encrypted RAG |
|---|---|---|
| Embeddings at rest | Plaintext in vector DB | Encrypted; similarity preserved |
| Metadata | Plaintext JSON fields | FPE-encrypted; still queryable |
| Document access | Anyone with DB credentials | RBAC-scoped per role, group, department |
| Similarity search | Standard cosine on plaintext | Same results on ciphertext |
| Breach exposure | Full embedding contents readable | Ciphertext only; no plaintext |
| Audit trail | Optional, often absent | Policy-enforced, built-in |
| Compliance posture | Manual controls required | Encryption at architecture level |
The Problem with Standard Inference
Inference is where sensitive data travels most. The model endpoint sees inputs and outputs in full. In cloud deployments, so does the provider.
A clinical model receives patient notes. A credit model receives financial history. A fraud model receives transaction details. Under GDPR, HIPAA, and sector-specific data residency rules, sending this data to a cloud inference endpoint in plaintext is often not acceptable. Teams respond by stripping sensitive fields before sending data, which loses accuracy, or keeping models on-premise, which loses scalability. Encrypted inference is a third option.
How Encrypted Inference Works
VectaX encrypts inputs before they leave your network. The model receives ciphertext, applies its weights using FHE, and returns ciphertext. Decryption happens only inside the authorised caller's context, under the RBAC policy set at inference time. The cloud provider, the model host, and the logging infrastructure hold ciphertext only at every stage.
Pipeline Stage Comparison
| Stage | Standard Pipeline | Encrypted Inference |
|---|---|---|
| Input preparation | Raw data sent in plaintext | Encrypted at client before any transmission |
| Feature extraction | Embeddings computed on plaintext | Computed on encrypted input via FHE |
| Model compute | Weights applied to plaintext features | Weights applied to ciphertext; no decryption at host |
| Output | Plaintext prediction returned | Encrypted prediction; RBAC-gated decryption |
| Logging | Raw inputs and outputs in logs | Ciphertext only in logs; no plaintext exposure |
Access Control Matrix
Real Benchmarks: Plaintext vs FHE-Encrypted
Mirror's FHE engine is optimised specifically for AI workloads. These are production numbers, not theoretical estimates.
Use Cases by Industry
Technical Specifications
| SDK packages | pip install mirror-sdk mirror-enc |
| Python version | 3.9 and above |
| API endpoint | https://mirrorapi.azure-api.net/v1 |
| Authentication | MIRROR_API_KEY environment variable |
| Vector DB support | ChromaDB (native integration); any store via standard interface |
| Encryption types | FHE (compute layer), similarity-preserving (vectors), FPE (metadata) |
| Access control | Multi-dimensional RBAC: role, group, department |
| Key scoping | Per-user keys generated via sdk.rbac.generate_user_secret_key() |
| Metadata binding | Context-bound tweak via sdk.metadata.generate_tweak_from_data() |
| Hosting | Azure Static Web Apps (Academy); Mirror platform on Azure |
| SDK version | v1.0 |
How VectaX Fits with Other Mirror Products
Ready to encrypt your AI pipeline?
Request a personalised demo or explore the Mirror Academy to see VectaX in production-ready course examples.