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.

LayerProtection
NetworkTLS 1.3 enforced on all connections (in transit)
StorageAES-256 encryption at rest for all data stores
DatabaseIsolated PostgreSQL instance per organization
Provider keysAES-256-GCM encryption at rest, injected only at request time
Uptime99.9% SLA (Enterprise plans)

Every HTTP response from Ingate includes a hardened set of security headers:

Response 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; preload

No self-hosting

Ingate is cloud-only. All security controls, patching, and monitoring are managed for you. There are no binaries to deploy or infrastructure to maintain.

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.

bash
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.

bash
# 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.

json429 Response
{
  "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.

RoleLevelCapabilities
viewer0Read-only access to logs, metrics, evals, usage
member1Viewer + proxy access, create prompts/evals/keys
admin2Member + manage teams, budgets, webhooks, org settings
owner3Admin + 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

Unlike permissive gateways that pass requests through when auth is absent, Ingate rejects any request missing a valid auth context with 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.

FeatureDetails
Encryption at restAES-256-GCM with per-key nonces
InjectionKeys injected into the upstream request at proxy time only
Client isolationClients never see, send, or receive provider keys
Header strippingX-Ingate-Key is stripped before forwarding upstream
Auth passthroughFor subscription-based tools, client credentials pass through directly
Zero-downtime rotationRotate provider keys in the dashboard. No client changes required
bash
# 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

PII redaction is available on Enterprise plans.

Automatically redact sensitive data from request and response logs before persistence. Three redaction modes are supported:

ModeBehaviorUse case
patternRegex match replaced with [REDACTED]Partial redaction. Preserves log structure
hashEntire field replaced with [REDACTED]Full-field redaction. Still visible in logs as redacted
dropField 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

PlanLog RetentionExport
Free7 daysFull API export before expiry
EnterpriseConfigurable (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.

bash
# 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.jsonl

Rate Limiting

Multiple layers of rate limiting protect against abuse, runaway costs, and denial-of-service:

LayerLimitPurpose
Per-key request rateConfigurable per orgCost control and fair usage
Auth endpoints (login/signup)10 req / 15 min / IPBrute force protection
Response capture10 MB max per responseDoS protection on log storage

When a rate limit is exceeded, the response includes standard headers for client backoff:

429 Response Headers
HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 0

Compliance

Ingate is built for organizations with strict security and compliance requirements.

AreaStatus
SOC 2 Type IIAudit-ready. Controls implemented and documented
SSRF protectionOutbound URLs (webhooks, eval callbacks) validated against allowlists; private IP ranges blocked
Data Processing AgreementAvailable on request for Enterprise customers
Custom data residencyAvailable on Enterprise. Deploy in your preferred region
SSO (SAML / OIDC)Coming soon

Security questionnaire

Contact security@ingateai.com for security questionnaires, SOC 2 evidence packages, compliance documentation, and custom requirements.

Security Summary

A quick reference of all security controls enforced across the platform:

ControlImplementation
Encryption in transitTLS 1.3 on all endpoints
Encryption at restAES-256 (database), AES-256-GCM (provider keys)
API key storageSHA-256 hashed, never logged
Password storagebcrypt hashed
Session tokensHMAC-SHA256 signed
Auth modelDeny-by-default RBAC, org-scoped isolation
Security headersHSTS, X-Frame-Options, CSP, nosniff, referrer policy
Brute force protection10 req / 15 min / IP on auth endpoints
Response size limit10 MB capture bound (DoS protection)
SSRF protectionOutbound URL validation, private IP blocking
PII redactionPattern, hash, and drop modes (Enterprise)
Data retention7 days (Free), configurable (Enterprise)