Legal
law firm → e-discovery vendor's cloud → firm's AI assistant
The assistant searches privileged documents held by the vendor. The vendor stores and searches only encrypted data.
/// VectorBlack
Encrypted search your AI can use.
SELECT YOUR INDUSTRY
The whole path · Government
Your AI can search it. No one else can read it.
Two lanes, two sides. Everything to the left of the SDK is readable. Everything to the right is ciphertext. The key never leaves the left side.
- READABLE
- ENCRYPTED
- HOLDS THE KEY
SWIPE TO SEE THE HOST SIDE →
Ingest. Files become vectors on your side. The SDK encrypts vectors and files with your key and writes them to the host. Readable copies never cross.
Search. Your AI's question is encrypted by the SDK. The server scores every record on ciphertext and returns encrypted scores. It never sees the question.
Answer. The SDK decrypts the scores, fetches the top 10 files inside a batch of decoys, decrypts only those, and hands them to your model. That is the one place plaintext exists.
The full record
Check our work.
Every number here comes from a real test on one 20-core workstation with no GPU. Nothing is estimated.
5.4
queries per second on one node
16 concurrent clients, median 3.3 s
10,000,000
files searched on one node
2.07 s best, 3.9 s median, memory-limited
18s
to ingest a million files
encrypt vectors and files, 8 threads
80,000
real passages stored as encrypted files
10 of 10 checks passed, 0.071 s server
| Condition | Measured |
|---|---|
| Files | 1,000,000 |
| Server search, d=128 | 0.21 s |
| End to end, d=128 | 0.36 s |
| Server search, d=256 | 0.45 s |
| End to end, d=256 | 0.61 to 0.65 s |
| Ingest | 18 s per million vectors at d=128, 34 s at d=256 |
| Throughput, one node | 5.4 queries per second with 16 concurrent clients, median 3.3 s |
| Ten million files, one node | server 2.07 s best, 3.9 s median; 76.6 GiB index, memory-limited |
| Real documents | 80,000 MS MARCO passages stored as encrypted files, 10 of 10 checks passed |
| Query upload | 0.3 MiB, one ciphertext |
| Response | 31 MiB for the full result set, or 1 MiB with the selection sketch (server 1.3 s) |
| Recall@10 vs exact plaintext | 1.00 |
| Score error | about 2e-10 |
| Index size | 7.7 GiB per million vectors at d=128 |
| Hardware | one 20-core workstation, no GPU |
Answer quality. Encrypted search returns the same matches an unencrypted search of the same vectors returns. The shorter vectors themselves keep 98 to 99.9% of full-length quality on four public test sets with the better reducer, and 81 to 95% out of domain.
Test conditions. One 20-core workstation, no GPU. The machine was doing other work at the same time, so real-world speed should be the same or better.
Real documents. 80,000 real passages went in as encrypted files and came back out only on the client: 0.071 s of server time per question, ten of ten checks passed.
Smaller responses. Instead of sending back the full 31 MiB of results, the server can send a 1 MiB summary that still gives you the same top 10 matches, at 1.3 s of server time.
What the host holds
What the host holds. What it never can.
The host stores your data in encrypted form and holds special keys that let it compute on that data, but not read it. The one key that decrypts anything stays with you. VectorBlack is a small toolkit on your side that encrypts and decrypts, and a search server on the host's side that works blind. Your AI setup doesn't change.
On the host
- your filesencrypted, unreadable
- your search indexencrypted, unreadable
- math keyslet the server calculate, never decrypt
- a map of which server holds what
- basic factshow many files, when you search, which encrypted files were fetched (among decoys)
Never on the host
Hover a row to compare what you see with what the host sees.
- your secret keysk_2f91…stays on your machines, always
- your documentsmerger agreement v79f3a c01e 44b7 2d88
- your search index[0.118, -0.402, 0.077, …]e19c 7b02 5a6d f3e1
- your questions"who signed the side letter?"0c7e 91ab 66d4 b3f0
- the resultstop 10 → doc 4127, 88, 9020c41d 08ef 2a75 d9c3
Specifications
What a security reviewer will ask.
Encryption
CKKS, 128-bit classical
Parameters come from OpenFHE's standard 128-bit table. Both operands of every multiplication are ciphertexts; the host never holds a plaintext vector.
Lattice basis
Ring-LWE, the family behind ML-KEM and ML-DSA
The same lattice family as NIST's post-quantum standards, FIPS 203 and 204, which CNSA 2.0 adopts. CKKS itself is on no approved list, and we do not claim otherwise.
Transport
TLS 1.3, OpenSSL FIPS Provider 3.1.2 (CMVP #4985)
The server refuses to start unless OpenSSL reports FIPS mode. The build is vendor-affirmed on this platform, not a tested-platform certificate. FIPS covers transport only.
SDKs
Python and Node.js
One key-store and one index format, written by both SDKs and tested against each other. Runs wherever your agent runs: on-prem, VPC, or workstation.
Tenants and auth
Bearer tokens, mutual TLS
Tokens are stored as SHA-256 digests and compared in constant time. Each tenant has its own context and keys; nothing can mix them.
Sharding
Shards behind a router
Each shard serves a block range; the router fans out and merges. The router holds context, keys and manifest only. Runs on ordinary Linux instances; sharding is tested on one machine, not yet across a network.
Response integrity
Client-held canaries and a nonce
Catches a host that skips blocks, replays or corrupts a full response; the 1 MiB sketch carries only the nonce. The threat model is an honest-but-curious host: a lying host is caught, not prevented.
Document payloads
AES-256-GCM, fetched with decoys
Client-encrypted, with the document id bound as associated data, so a swapped file fails to decrypt. Fetches hide the wanted ids inside a padded batch of decoys.
Key store
PBKDF2-HMAC-SHA256, AES-256-GCM
The secret key, placement and payload key are sealed under a passphrase-derived key. A wrong passphrase fails the tag; there is no silent wrong key.
Prior art
SANNS, HERS, HyDia
The packing layouts follow published work. The measured numbers on this page are ours.
Use cases
For anyone who runs AI on data they're not allowed to expose.
Finance
investment team → shared Azure or AWS tenant → analyst's AI
Analysts get AI search over deal memos and research in a cloud the whole firm shares. The cloud can't read a word of it.
Defense and government
accredited enclave → AWS GovCloud → Claude on Bedrock
The search runs in GovCloud on ciphertext. The keys never leave the accredited side.
Objections
Short answers.
No. The SDK runs on an instance in your own account and encrypts them in place, writing the encrypted index and encrypted copies back to S3. From then on the search server handles only ciphertext. It cannot undo what could already be read in the plaintext copies, which you can delete once ingestion is done.
Next
Run it in your GovCloud account.
Tell us which model you use and where the files live: GovCloud, another cloud, on-prem, or a vendor. They can stay where they are. We'll benchmark it on your documents and show you the numbers.
// what crosses the wire, TLS 1.3
- POST /t/agency/searchone ciphertext, 0.3 MiB, plus a nonce
- 200encrypted scores: 31 MiB, or a 1 MiB sketch
- POST /t/agency/payloadsthe wanted ids inside a batch of decoys
- 200AES-256-GCM payloads, opened with your key
GET /t/agency/audit reports what the host holds for that tenant: protocol, cipher, FIPS mode, auth mode.