Self-Serve Security
Credential encryption at rest, 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 encrypts stored connector credentials at rest with AES-256-GCM. This covers template values (the API keys and tokens that admins and users enter for a server) and OAuth tokens and client secrets.
- Deployment-held key: the key is configured on the SealGate deployment (
SEALGATE_OAUTH_ENCRYPTION_KEY). The server can decrypt credentials, because it needs them to call your connected apps. So SealGate itself is able to read them: encryption protects database files and backups, not a compromised running server. - Write-only values: a saved value is never returned by the API or shown again in the dashboard. You can only replace it.
- No key configured: credentials are stored in plaintext, and admins see a warning in the dashboard.
Transport & Auth
- Auth: HMAC-signed API keys. People sign in with email, Google, or Microsoft.
- 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.