What we store, what we never store, and how to check.
This page is the written answer to a security review: the data model, the deployment boundary, the keys, and the compliance posture, stated the same way here as in the product.
Two columns, no fine print.
What we store
- –ACARS composite score and per-signal breakdown
- –Decision outcome (allow / warn / block) and APE stages applied
- –Risk category (PII, Financial, Source Code, Legal, Strategic)
- –Timestamp, deployment group, and org policy snapshot
- –Execution graph node identifier and framework type
What we never store
- –Raw prompt or agent payload text, processed in-memory only
- –Tool call outputs or retrieved document contents
- –End-user or employee PII or identity information
- –The text behind any stored embedding: learned-block vectors keep category and risk metadata, never the content they derive from
- –Any data that crossed the agent boundary, only pre-boundary state is read
Metadata-only is the GDPR answer.
Raw prompt and agent payload text is never stored; it is processed in memory only. Detection events keep metadata: risk score, category, decision, timestamp. When the LLM judge confirms a block and a vector store is configured, an embedding vector derived from the content (never the text itself) is stored with category and risk level.
A system that never keeps the content cannot leak the content, and a records-of-processing request gets a short, checkable answer. Documents follow the same rule: files live in object storage you choose, never in the database, originals and outputs are deleted on a retention window, and every output download is access-audited.
Your boundary, the whole stack.
Every plan can move fully on-prem. Self-hosted, the detection pipeline, the vault, the document engine, and the models run inside your network, and the document engine makes zero outbound calls: OCR models are mounted, never downloaded. Air-gapped operation is a supported deployment, one component of the combination rather than the pitch.
Self-hosted deployments that don't configure a vector store persist nothing beyond event metadata.
Answered in writing.
Two modes, stated plainly: on Privent Cloud, Privent generates and operates the vault keys. Self-hosted, you generate and hold them, and no Privent-held key ever exists for your data.
Encryption at rest
Every vault value is encrypted with AES-256-GCM under a fresh random IV, and the authentication tag is verified on every read. Lookups never touch plaintext: they use HMAC-SHA256 blind hashes.
Bring your own key
No external KMS or HSM integration exists today. Self-hosted, key custody is already yours: the installer deliberately refuses to auto-generate the vault keys, so you create both and you hold both.
Rotation
In-place key rotation is not shipped. The schema reserves a key version field for it. Vault entries are short-lived by design (60-minute default, 24-hour ceiling), which bounds the blast radius of any key event.
Erasure
We erase data, not keys. Destroying a session hard-deletes its vault rows, an hourly sweep hard-deletes expired entries, and deleting an organization cascades through everything it owns. We do not claim crypto-erasure.
Key-material residency
Key material lives in environment configuration and process memory. It is never logged, never written to the database, and never transmitted. Self-hosted, it never leaves your boundary.
Current tense only.
SOC 2 Type II is in progress, monitored via DSALTA; the word certified arrives when an auditor brings it. Our current controls and policies are public at trust.privent.ai. Every compliance report the product exports says what it is: point-in-time operational evidence mapped to eight frameworks, with independent auditor review required for formal assertions.
trust.privent.aiBring your security review.
The answers above are the ones we give in writing. If your review needs more, ask for it on a call.