Skip to main content
Version: MVP

Dashboard Security

4 min readFor operators & maintainersUpdated 2026-05-22

What you'll find here

The security posture for Craik's local dashboard: authentication, local bind defaults, unsafe-bind acknowledgement, redaction, and action boundaries.

The dashboard is not public infrastructure.

It is a local operator surface. Keep it bound to localhost unless a separate network boundary and TLS termination layer are already in place.

Authentication

Every dashboard route requires one of two authentication postures:

Dashboard bearer token

Pass a token with --auth-token or CRAIK_DASHBOARD_TOKEN, then send it in Authorization: Bearer ... or X-Craik-Dashboard-Token.

Active operator session

If no dashboard token is configured, requests must include X-Craik-Operator-Session matching the active local session token.

Dry-run launch metadata reports the active auth posture but does not print the bearer token value. Operator-session mode includes a warning that callers must send the session-binding header; the presence of an operator-session file alone is not sufficient.

Bind Safety

craik dashboard binds to 127.0.0.1 by default. Binding to 0.0.0.0, a LAN address, or another non-local host is rejected unless the operator passes --allow-unsafe-dashboard-bind.

That flag is an acknowledgement, not a security control. Treat a non-local dashboard as sensitive and place it behind network controls and TLS termination.

Redaction

Dashboard JSON and HTML are rendered through the shared redaction and runtime text sanitization utilities. Pages expose readiness state, counts, IDs, paths, provider status, and action output; they do not display raw provider secrets, refresh tokens, or credential-bearing values.

Actions

The /api/actions route dispatches through the shared slash-command registry. Browser POSTs with an Origin header must match the local dashboard origin, and read-only command results are returned directly. Mutating slash-command families are blocked from this route. Mutating dashboard actions must route through their owning runtime handlers and must keep receipt emission, operator identity, and policy checks in those handlers rather than bypassing them in the web surface.

What's next