Detection Vault
How Outgate stores recognized sensitive values, what populates it, and what to expect when it changes.
What the vault is
A per-organization store of fingerprints for values that should be anonymized in traffic.
When guardrails detect sensitive content — an email address, an API key, a phone number — Outgate replaces it with a placeholder like [EMAIL_1] before the request reaches the model. The Detection Vault is where the mapping between the original value and that placeholder lives, so the gateway can replace the same value the same way on every subsequent request and restore originals in responses.
The vault is scoped to your organization and lives in the region that processed the request. It holds fingerprints — token sets and hashes — not plaintext (except in an explicit debug mode used only for incident triage on self-hosted regions).
- Per-organization: every member of the org shares the same vault for a region.
- Per-region: each region keeps its own vault; entries in one region do not roll over to another.
- TTL-bounded: entries expire after seven days of inactivity by default. A hit on an entry refreshes the TTL.
- Hash-first: production deployments store only hashes plus tokenized fingerprints — the plaintext value never leaves the gateway boundary.
Anonymization vs. detection
The vault only matters for categories where the guardrail policy is set to anonymize. Detections that block or alert do not write to the vault — there is no need to remap a value the gateway refused to send.
Categories and sources
Every entry is tagged by category and by who put it there.
Entries are organized along two axes. Category describes what the value is — its risk type. Source describes how it got into the vault.
| Category | Default behavior |
|---|---|
| personal_information | Anonymize (enabled by default for new policies) |
| credentials | Anonymize (enabled by default for new policies) |
| Source | How entries land here |
|---|---|
| auto-detect | Detected automatically during a live request through the gateway. |
| kv-scan | Found by a scan job — either an og-cli scan or a console-triggered re-scan over historical traffic. |
| manual | Added directly through the console or the og-cli vault commands. |
Source matters when you flush. The console and CLI both let you flush by scope so you can clear automated detections without losing values you added on purpose.
Populating from the console
Add, label, and clear entries in Gateway → Guardrails → Detection Vault.
The console exposes the vault under Gateway → Guardrails → Detection Vault. You can list everything the org has accumulated, see a summary of categories and sources, add entries manually, and flush by scope.
- Add: pick a category, paste the value, and optionally attach a short tag for grouping. Source is set to manual. The console hashes the value client-side before sending the entry to the regional guardrail.
- Flush by scope: auto-detect, kv-scan, manual, or all. Useful when you want to wipe automation churn without losing curated entries.
- Stats: shows total entries, hit rate, and last scan time. Operator-grade view, not user-facing.
Visibility
The console vault page is org-wide. Anyone with console access to the org can see every entry. Treat tags as visible labels, not as private notes.
Populating from og-cli
Use og scan to seed entries and og vault add/list/rm to curate.
The CLI gives you two paths into the vault. og scan runs detection in dry-run mode — the request never reaches the upstream model, but every detection is written to the vault under source kv-scan. og vault is a small set of CRUD commands for working with the vault directly.
# Dry-run scan against a guardrail-enabled provider; populates the vault
og scan --provider my-provider path/to/file
# Curate entries directly
og vault add "sk-ant-abc123def456" --category credentials --tag staging
og vault list --category credentials
og vault rm --tag staging- og scan uses the gateway endpoint of your selected provider and runs the same detection pipeline a live request would, just without forwarding to the model.
- og vault add stores the value under source manual with an optional tag. The tag is a free-form label up to 200 characters.
- og vault rm by --tag removes every entry whose tag contains the substring.
Where the CLI writes
og vault and og scan target the regional gateway you selected with --provider. If your org spans multiple regions, entries do not propagate automatically — scan once per region where you want the gateway to recognize the value.
Populating from API traffic
Live requests through the gateway are the main source of vault growth.
Most entries end up in the vault without any explicit action. When you send a request to a guardrail-enabled endpoint, the gateway runs validation, replaces detected values with placeholders before forwarding to the model, and writes the resulting fingerprints to the vault asynchronously. The next request that contains the same value matches the existing fingerprint instead of asking the model to rediscover it.
On the response path, the gateway looks up the placeholders in the vault and substitutes the original values back in so your application sees the rehydrated text. This happens transparently for normal completion and chat APIs.
- Source is recorded as auto-detect.
- TTL resets on every hit, so recurring values stay in the vault as long as they are seen at least every seven days.
- Streaming responses are buffered for the rehydration pass, so placeholders never leak to the client mid-stream.
Display in the chat
How chat.outgate.ai surfaces vault matches without exposing plaintext to the browser.
The chat app has a per-thread "Show detections" toggle that highlights regions of a message matching vault entries. When the toggle is on, the chat backend asks the regional guardrail for the relevant detections for that thread — but only as hashes plus token shapes, never as plaintext. The browser never holds raw values; it only matches local message text against the fingerprints.
- Toggle is per-thread and remembered locally.
- Categories shown default to personal_information and credentials; other categories can be enabled per thread.
- A vault flush from the console removes the highlights but leaves the chat messages themselves untouched.
Implications and edge cases
What to expect when the vault changes, expires, or moves with you.
A few things are worth keeping in mind when you operate Outgate over time.
Flushing the vault does not rewrite old messages.
A request that was anonymized before the flush will still contain placeholder tokens like [EMAIL_1]. Without a vault entry to map back, the placeholders remain literal in any historical view. New requests start fresh.
Cross-region traffic builds separate vaults.
If your org has gateways in two regions and the same value appears in both, each region keeps its own fingerprint. Flushing one region does not affect the other; a scan in one region does not seed the other.
Hash-only by default.
Production regions store fingerprints, not plaintext, so neither operators nor compromised infrastructure can read back the original value from the vault alone. Self-hosted regions can opt into a debug storage mode that retains plaintext for short-term incident triage — leave it off for normal operation.
TTL keeps the vault small.
Entries expire after seven days without a hit. If a value disappears from your traffic for more than a week and reappears, the gateway will redetect it and create a new entry. The placeholder index may differ from before.
Tags are visible to everyone in the org.
They are useful for organizing entries — for example tagging staging credentials separately from production ones — but treat them as public labels within the org.
Public API
Manage the vault programmatically with an API key.
Every action you can take in the console or with og-cli has a matching HTTP endpoint, so CI jobs, internal tools, and SDKs can manage the vault without a human in the loop. Authentication is the same org-issued API key you create in Console → Gateway → API Keys (the value starts with `gw_`). It travels as a Bearer token; the gateway resolves it to your organization and the region you target via the X-Region-Id header.
Two scopes gate access. Attach them at key-creation time — they appear as checkboxes in the create-key modal.
| Scope | Allows |
|---|---|
| outgate.vault.read | GET /api/v1/vault/stats, GET /api/v1/vault/detections |
| outgate.vault.write | POST /api/v1/vault/detections, DELETE /api/v1/vault/detections/{hash}, DELETE /api/v1/vault/detections/by-tag/{tag}, POST /api/v1/vault/flush |
Hashes only
List endpoints return hashes and token shapes, never plaintext. The same constraint that protects the chat UI from holding raw values applies to the public API.
Examples. Replace `gw_…` with your key and `reg-…` with the region id you want to target.
# Vault stats
curl https://api.outgate.ai/api/v1/vault/stats \
-H "Authorization: Bearer gw_…" \
-H "X-Region-Id: reg-…"
# List detections (paginated, hashes only)
curl "https://api.outgate.ai/api/v1/vault/detections?category=credentials&limit=100" \
-H "Authorization: Bearer gw_…" \
-H "X-Region-Id: reg-…"
# Add a manual detection
curl -X POST https://api.outgate.ai/api/v1/vault/detections \
-H "Authorization: Bearer gw_…" \
-H "X-Region-Id: reg-…" \
-H "Content-Type: application/json" \
-d '{"value":"sk-ant-abc123","category":"credentials","tag":"staging"}'
# Delete by hash
curl -X DELETE https://api.outgate.ai/api/v1/vault/detections/<hash> \
-H "Authorization: Bearer gw_…" \
-H "X-Region-Id: reg-…"
# Delete every entry whose tag contains 'staging'
curl -X DELETE https://api.outgate.ai/api/v1/vault/detections/by-tag/staging \
-H "Authorization: Bearer gw_…" \
-H "X-Region-Id: reg-…"
# Flush only auto-detected entries
curl -X POST https://api.outgate.ai/api/v1/vault/flush \
-H "Authorization: Bearer gw_…" \
-H "X-Region-Id: reg-…" \
-H "Content-Type: application/json" \
-d '{"scope":"auto"}'- Missing X-Region-Id → 400 region_required.
- Invalid or revoked key → 401 unauthorized.
- Key without the required scope → 403 with the scope name that's missing.
- Region not active for the org → 403 forbidden.
Prefer the CLI for terminal use
og-cli ships `og vault add/list/rm` for the same operations without managing curl, headers, and JSON bodies by hand. The public API is the right surface for automation and SDKs; the CLI is the right surface for ad-hoc terminal work.