Self-Serve Security
Zero-knowledge credential encryption, transport / OAuth, and data retention for SealGate.
These are the protections every SealGate tenant gets out of the box-no enterprise contract required.
Credential Encryption
SealGate uses zero-knowledge encryption for stored credentials. No encryption keys are stored on the server.
| Credential type | Encrypted with | Key stored? |
|---|---|---|
| User credentials | User's personal key | Never -- hash only |
| Admin credentials | Domain key (optional) | Never -- hash only |
The user's key is a composite of typed segments: user:{personal_key}.admin:{org_key}[.role:{name}:{key} ...], delivered to the server in the X-SealGate-Secret-Key request header and never persisted. Each stored secret is encrypted with an AES-256-GCM key derived via HKDF-SHA256, using an info parameter of sealgate-secret:{context} where {context} uniquely identifies the secret (e.g. server:template_key). This context-based derivation gives each secret its own derived key without the server ever storing key material.
Transport & Auth
- Auth: HMAC-signed API keys or SAML 2.0/OIDC.
- Transport: TLS 1.2+ mandatory.
- Isolation: Clients communicate only with the SealGate server; no direct client access to MCP backends.
Data Retention
| Data Type | Logged | Retention (Default) |
|---|---|---|
| Tool Calls | Metadata only by default (tool name, timestamp, status, duration, trifecta/ACL flags) | 90 Days |
| Tool Call Params & Results | Not stored unless call storage is enabled (store_call_data, opt-in per org, off by default) | 90 Days when enabled |
| Security Events | Flag changes & Blocks | 1 Year |
| Approvals | User decisions | 1 Year |
Privacy: Tool-call parameters and results are read in-flight to evaluate policy, then discarded. They are persisted only if an org explicitly enables store_call_data (off by default). Raw file contents and full conversation histories are not tracked or stored on SealGate servers.