Security
Krios enforces a fixed security baseline — HTTPS-only / TLS 1.3, strict per-tenant isolation, SHA-256-hashed API keys, Zod-validated input, and sanitized rich-text output, among others. This section explains how those guarantees are implemented.
Auth model
Two credential kinds:
| Kind | Source | Used by |
|---|---|---|
| Session JWT | NextAuth (HTTP-only cookie) | Admin UI; CLI's auth login. |
| API key | Bearer header | Programmatic clients (SDK, MCP, CI). |
src/lib/auth/request.ts:authenticateRequest resolves both — bearer wins when both are present (explicit beats ambient).
API key types
| Type | What it gets |
|---|---|
delivery | Read-only, public content. Safe to ship in client bundles. |
preview | Read-only, draft + published. Used for preview builds. Pair with KriosPreviewOverlay for click-to-edit. |
management | Full read/write. Server-side only. Required for REST /api/v1/* mutations and for MCP sessions. |
Keys are SHA-256 hashed at rest (keyHash); a separate keyPrefix column stores the first 8 chars for display. Plain keys are shown to the user once at creation and never retrievable.
Optional fields: expiresAt, rateLimit (per-key override), siteId (delivery keys can be scoped to one site), environmentId (V2: scoped to one environment).
TLS
HTTPS only. No HTTP fallback. Krios trusts the x-forwarded-proto header from Vercel / a TLS-terminating proxy to detect the scheme.
For more detail see the dedicated security review document at docs/SECURITY-MODEL.md in the repo (also linked from this site at Compliance).
Sub-pages
- Authentication — sessions, lockout, password storage
- Authorization — RBAC, field-level permissions, key types
- API security — rate limiting, CORS, CSP, input validation
- Compliance — GDPR, SOC 2, HIPAA, ISO 27001 readiness