Data handling
What Cirvix stores, what it never sees, and how the two are kept apart.
What crosses the boundary
| Data | Stored? | Notes |
|---|---|---|
| Decision records | Yes | Agent, action, resource identifier, verdict, policy — the audit chain |
| Secret values | No | Only opaque handles cross; values resolve from your vault at the edge |
| Tool call arguments | Configurable | Full payload capture can be scoped or disabled per policy |
| Model prompts / completions | No, by default | Cirvix governs the tool-call boundary, not the conversation |
The one exception to "no prompts or completions" is opt-in: content classification for injection scoring reads tool *results* — not the model's prompts — specifically to flag instruction-shaped text before it re-enters context. That classifier's output (a score) is what's recorded, not the underlying content, unless you explicitly configure otherwise.
Retention
There is no automatic pruning — decisions, runs, and audit records accumulate until you export and remove them. In a self-hosted deployment, retention, export, and deletion are entirely within your own control. Note that pruning audit records breaks the hash chain by design; archive the removed range and record the checkpoint hash at the cut.
Data residency
For a self-hosted or VPC deployment, residency is wherever you run the control plane. For the hosted, private-beta control plane, residency specifics are part of onboarding rather than a default assumed here.