Security and data handling

Data rules are set per project (Core › Projects and keys, /app/core/projects); company-wide access rules, SSO and security events live in Core › Security (/app/core/security), the audit log in /app/core/security/auditas.

Data retention

Metadata (timestamps, models, token counts, cost) is always kept because billing needs it (400 days). Security events (400 days) and the audit log (730 days) have their own retention. Detailed traces can be sampled per project (1, 0.5, 0.1 or 0.01); metering and errors are always kept. The API never returns prompts or answers (Observability).

Personal data (PII) and secrets

ORYVOX scans every prompt before it leaves for a model.

• redact replaces the match with a placeholder before the model sees it.
• block rejects the request with 400 blocked_by_policy (not retried).
• Blocks and redactions are recorded as security events and can trigger the security.alert webhook.

Providers and regions

The project policy can restrict which providers and regions may process data:

• allowed / denied providers and blocked models,
• data regions (us, eu, cn, global; for example EU only),
• "no training" (only providers that do not train on API data),
• "require zero data retention" (only ZDR providers).

Routing never sends a request to a provider outside the policy, including fallbacks and the internal calls the token engine and semantic cache make. If no allowed model can serve it, the API returns 503 no_model_available.

API keys

• Keys are shown once and stored hashed (SHA-256); the dashboard shows only ory_live_abcd…wxyz.

• Rotation issues a new secret with the same settings; the old one keeps working for a grace period you choose (0 h, 1 h, 24 h, 3 d, 7 d). Revoked keys fail with 401 invalid_api_key immediately.

• Scopes limit what a key can call (403 permission_denied otherwise):

  Scope	Endpoints
  chat	POST /chat/completions, POST /responses, POST /requests/{id}/feedback
  embeddings	POST /embeddings
  models	GET /models
  cache	POST /cache/invalidate
  requests	GET /requests, GET /requests/{id}, GET /metrics

  A key without explicit scopes gets chat, embeddings, models and cache; add requests for observability access.

• Test keys (ory_test_) run the whole pipeline but never call a model and are never charged (Test mode).

• IP allowlist: restrict a key to IP addresses or CIDR ranges (403 ip_not_allowed otherwise). The company-wide allowlist applies to every key and to the dashboard.

• Last use time and IP are shown; use from a new IP is a security event.

• Rate limits per key (see Rate limits).

Never put keys in browser or mobile code. Call ORYVOX from your backend.

Transport

All traffic uses TLS. Webhooks are signed (see Webhooks).

Roles

The full permission matrix is on the Security page.

Sign-in

• Two-factor (TOTP): each person sets it up in Settings › Security (QR code, 8 single-use recovery codes). A company can require it for everyone.
• SSO (OpenID Connect): Okta, Microsoft Entra ID, Google Workspace, Auth0, Keycloak. Verify your domain with a DNS TXT record oryvox-verification=<token>; people on it join with the connection's default role. Enforce SSO refuses password sign-in for those domains.
• SAML 2.0: available on request; contact support to switch it on for your company.
• Sessions: each person sees and ends their own sessions; a company can cap session length in hours.

Audit log and security events

• The audit log records who changed what, with the values before and after, IP and user agent. Secrets are never written to it. Filter and export it as CSV or JSON (the export is logged too).
• Security events: blocked or masked secrets, blocked personal data, denied IPs, scope denials, new key IPs, failed and locked sign-ins, MFA changes, role and policy changes, SSO refusals. Warnings and critical events e-mail owners, admins and an optional alert address (repeats of the same alert are grouped).

Encryption

All traffic is encrypted in transit (TLS with HSTS). Stored prompts and answers, cached answers, conversation summaries, your own provider keys (BYOK), SSO client secrets and two-factor secrets are encrypted at rest with your organisation's own key, which is held in a key-management service. API keys and recovery codes are stored only as one-way hashes.