Guardway is designed around a simple principle: your prompts, completions, and audit logs never leave your network. The self-hosted gateway handles inference; the SaaS dashboard governs configuration and observes aggregate telemetry.
The data boundary
| Stays on your gateway | Sent to the Guardway cloud |
|---|
| Prompts and completions (request / response bodies) | Aggregate metrics: request counts, token counts, latency, cost |
| Provider API keys after attachment | Configuration you set in the dashboard (providers, routes, guardrails, budgets) |
| Audit logs (administrative actions) | Gateway health, version, heartbeat |
| MCP tool calls and their payloads | Cost + spend rollups per team / key / model |
| Cache entries | |
Audit logs are local-only. They describe actions on a specific gateway and are never routed through the cloud. View or export them from the gateway’s detail page while the dashboard is connected. See Audit. Encryption
- In transit — every hop (your app → gateway → provider, dashboard → gateway, gateway → control plane) uses TLS 1.2+.
- At rest — provider API keys and other secrets are AES-256 encrypted on the gateway. Keys are decrypted only in memory for the duration of a request.
- Log redaction — secret-looking values (Bearer tokens,
sk-... keys, Authorization headers, password-like fields) are redacted from logs automatically.
Authentication
- Dashboard users authenticate via Supabase with email + password; activation invites expire in 1 hour. Session timeouts are configurable per user (see Session).
- Gateways authenticate to the control plane with a one-time registration token at first boot, then with long-lived derived credentials. You can revoke a gateway’s credentials from the dashboard at any time.
- Applications authenticate to the gateway with API keys you issue (see API keys) — per-key scopes, budgets, quotas, IP allow-lists, MCP access rules.
Authorization (RBAC)
Gateway-scoped roles:
| Role | Scope |
|---|
| Owner | Everything, including billing and org deletion. |
| Admin | Configure providers, routes, guardrails, teams, keys. |
| Member | Issue and use keys within their team. |
| Viewer | Read-only. |
Container hardening
The gateway image ships with:
- Non-root user at runtime.
- Read-only root filesystem.
- Dropped Linux capabilities — only the minimum set needed to bind ports and open outbound connections.
- Restricted seccomp profile.
Your container runtime needs to support these features; any recent Docker, containerd, or Kubernetes release does.
Content safety
Built-in guardrails run on the gateway with low latency and no third-party dependency:
- PII detection — SSN, credit card, email, phone, API key patterns.
- Hate speech / toxicity.
- Prompt injection — jailbreak and instruction-override patterns.
- Keyword filters — custom allow and deny lists.
- IP allow / block-lists.
Violations are logged, optionally redacted, and can fire webhooks or block the request. See Guardrails.
Data retention
- On the gateway — logs, traces, and audit records follow whatever retention you configure. Default is rolling local storage; mount a persistent volume at
/var/lib/guardway to survive restarts.
- On the cloud dashboard — aggregate usage and spend metrics are retained for the life of your subscription. There are no raw request or response bodies stored in the cloud to retain.
Compliance
Guardway’s architecture is built to support:
- SOC 2 — centralized auth, RBAC, audit logging, TLS in transit, key management, access reviews.
- HIPAA — local-only audit logs, PII guardrails, per-user access, automatic logoff (see Session).
- PCI DSS — encryption at rest for secrets, credit-card PII detection, unique user identification, full audit trail.
- GDPR — PII detection and redaction, data minimization (no prompt bodies leave your network), incident-response support via audit log export.
Formal certifications are pursued per plan; email compliance@guardway.ai for your current attestation package.
Reporting a security issue
Please do not file public GitHub issues for security reports.
