Security & Compliance
How Ingate protects your data, credentials, and LLM traffic. Cloud-managed infrastructure with SOC 2 Type II audit readiness.
Infrastructure Security
Ingate is a fully managed cloud platform. There are no self-hosted components to configure or patch. All infrastructure is operated, monitored, and hardened by the Ingate team.
| Layer | Protection |
|---|---|
| Network | TLS 1.3 enforced on all connections (in transit) |
| Storage | AES-256 encryption at rest for all data stores |
| Database | Isolated PostgreSQL instance per organization |
| Provider keys | AES-256-GCM encryption at rest, injected only at request time |
| Uptime | 99.9% SLA (Enterprise plans) |
Every HTTP response from Ingate includes a hardened set of security headers:
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), camera=(), microphone=()
Strict-Transport-Security: max-age=63072000; includeSubDomains; preloadNo self-hosting
Authentication
Ingate uses two authentication methods: API keys for machine-to-machine access and session tokens for the dashboard.
API Key Authentication
Every proxy and API request requires your key in the X-Ingate-Key header. Keys are header-only: they are never accepted in query parameters, preventing accidental exposure in server logs, browser history, or referrer headers.
curl https://api.ingateai.com/v1/chat/completions \
-H "X-Ingate-Provider: openai" \
-H "X-Ingate-Key: sk-ingate-your-key" \
-H "Content-Type: application/json" \
-d '{"model": "gpt-4o-mini", "messages": [{"role": "user", "content": "Hello"}]}'Keys are stored as SHA-256 hashes. Raw key values are never persisted, never logged, and never included in error responses. Only a truncated hash prefix is used for log correlation.
Dashboard Authentication
Dashboard login uses email and password. Passwords are hashed with bcrypt before storage. Session tokens are signed with HMAC-SHA256 and are short-lived.
# Login (returns session token)
curl -X POST https://api.ingateai.com/api/v1/login \
-H "Content-Type: application/json" \
-d '{"email": "dev@acme.com", "password": "your-password"}'Brute Force Protection
Login and signup endpoints are rate limited to 10 attempts per 15 minutes per IP. Exceeding the limit returns 429 Too Many Requests with a Retry-After header.
{
"error": "rate limit exceeded",
"error_code": "rate_limited",
"retry_after_seconds": 900
}Authorization (RBAC)
Ingate enforces deny-by-default role-based access control. If the auth context is missing or invalid, access is denied. Requests are never silently passed through.
| Role | Level | Capabilities |
|---|---|---|
viewer | 0 | Read-only access to logs, metrics, evals, usage |
member | 1 | Viewer + proxy access, create prompts/evals/keys |
admin | 2 | Member + manage teams, budgets, webhooks, org settings |
owner | 3 | Admin + delete org, manage billing, transfer ownership |
Roles follow a linear hierarchy: higher roles inherit all permissions of lower roles. All data is org-scoped: users in one organization can never access another organization's data, keys, logs, or settings.
Deny by default
401 Unauthorized. This is enforced at the middleware layer before any handler executes.Provider Key Security
Provider API keys (OpenAI, Anthropic, etc.) are stored with AES-256-GCM authenticated encryption at rest. They are decrypted only at the moment a request is forwarded upstream and are never exposed to clients.
| Feature | Details |
|---|---|
| Encryption at rest | AES-256-GCM with per-key nonces |
| Injection | Keys injected into the upstream request at proxy time only |
| Client isolation | Clients never see, send, or receive provider keys |
| Header stripping | X-Ingate-Key is stripped before forwarding upstream |
| Auth passthrough | For subscription-based tools, client credentials pass through directly |
| Zero-downtime rotation | Rotate provider keys in the dashboard. No client changes required |
# Rotate a provider key. Existing clients are unaffected
curl -X PUT https://api.ingateai.com/api/v1/providers/openai \
-H "Authorization: Bearer <token>" \
-H "Content-Type: application/json" \
-d '{"api_key": "sk-new-openai-key..."}'PII Redaction
Enterprise feature
Automatically redact sensitive data from request and response logs before persistence. Three redaction modes are supported:
| Mode | Behavior | Use case |
|---|---|---|
pattern | Regex match replaced with [REDACTED] | Partial redaction. Preserves log structure |
hash | Entire field replaced with [REDACTED] | Full-field redaction. Still visible in logs as redacted |
drop | Field set to null (not stored) | Maximum privacy. Field never touches disk |
Default patterns detect and redact these data types out of the box:
- Email addresses: standard RFC 5322 patterns
- Social Security Numbers: XXX-XX-XXXX format
- Credit card numbers: Visa, Mastercard, Amex, Discover
- Phone numbers: US and international formats
Data Retention
| Plan | Log Retention | Export |
|---|---|---|
| Free | 7 days | Full API export before expiry |
| Enterprise | Configurable (30 / 60 / 90 days / unlimited) | Full API export + webhook delivery |
Data approaching the retention boundary can be exported via the API at any time. On Enterprise plans, configure webhook delivery to push logs to your own storage before expiry.
# Export logs before retention expiry
curl "https://api.ingateai.com/api/v1/logs?start=2025-01-01&end=2025-01-31&format=jsonl" \
-H "Authorization: Bearer <token>" \
-o logs-jan-2025.jsonlRate Limiting
Multiple layers of rate limiting protect against abuse, runaway costs, and denial-of-service:
| Layer | Limit | Purpose |
|---|---|---|
| Per-key request rate | Configurable per org | Cost control and fair usage |
| Auth endpoints (login/signup) | 10 req / 15 min / IP | Brute force protection |
| Response capture | 10 MB max per response | DoS protection on log storage |
When a rate limit is exceeded, the response includes standard headers for client backoff:
HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 0Compliance
Ingate is built for organizations with strict security and compliance requirements.
| Area | Status |
|---|---|
| SOC 2 Type II | Audit-ready. Controls implemented and documented |
| SSRF protection | Outbound URLs (webhooks, eval callbacks) validated against allowlists; private IP ranges blocked |
| Data Processing Agreement | Available on request for Enterprise customers |
| Custom data residency | Available on Enterprise. Deploy in your preferred region |
| SSO (SAML / OIDC) | Coming soon |
Security questionnaire
Security Summary
A quick reference of all security controls enforced across the platform:
| Control | Implementation |
|---|---|
| Encryption in transit | TLS 1.3 on all endpoints |
| Encryption at rest | AES-256 (database), AES-256-GCM (provider keys) |
| API key storage | SHA-256 hashed, never logged |
| Password storage | bcrypt hashed |
| Session tokens | HMAC-SHA256 signed |
| Auth model | Deny-by-default RBAC, org-scoped isolation |
| Security headers | HSTS, X-Frame-Options, CSP, nosniff, referrer policy |
| Brute force protection | 10 req / 15 min / IP on auth endpoints |
| Response size limit | 10 MB capture bound (DoS protection) |
| SSRF protection | Outbound URL validation, private IP blocking |
| PII redaction | Pattern, hash, and drop modes (Enterprise) |
| Data retention | 7 days (Free), configurable (Enterprise) |