Privacy and Security

Guardway is designed around a simple principle: by default, your prompts and completions stay on your gateway. The self-hosted gateway handles inference; the SaaS dashboard governs configuration, records administrative audit logs, and observes aggregate telemetry.

​

The data boundary

​

Encryption

• In transit — every connection the gateway originates (gateway → provider, gateway → control plane, SIEM export) enforces TLS 1.2+. Inbound hops (your app → gateway, dashboard → gateway) use TLS when you terminate it in front of the gateway — deploy the container behind a TLS-terminating proxy or load balancer.
• At rest — provider API keys and other secrets are AES-256-GCM encrypted on the gateway and decrypted only in memory; plaintext keys are never written to disk.
• Event redaction — the stored preview on every guardrail event is masked by the content filter before it is written (v0.4.41+), including secret-looking values among the recognised spans. Request logs record bodies as received; enable the secret/credential guardrail in mask mode to keep leaked credentials out of stored traffic.

​

Authentication

• Dashboard users authenticate via Supabase with email + password; invite email links expire after 1 hour, and the pending invitation itself remains valid for 7 days and can be re-issued. Session timeouts are configurable per user (see Console).
• 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 and MCP access rules; IP allow/block-lists are enforced at the organization level.

​

Authorization (RBAC)

Organization roles: See Access.

​

Container hardening

The published gateway image runs as a non-root user (uid 65532) by default, and the bundled MCP tool-bridge sidecars ship with dropped capabilities, no-new-privileges and a restricted seccomp profile. The gateway container itself is compatible with a read-only root filesystem, dropped capabilities and a default seccomp profile — set these in your deployment (compose security_opt/cap_drop, or your pod security context). Any recent Docker, containerd, or Kubernetes release supports them.

​

Content safety

Built-in guardrails run inside your deployment with no third-party SaaS in the inspection path: pattern-based checks (PII patterns, prompt-injection heuristics, keyword filters, IP lists) run in-process on the gateway, and model-backed checks (Safety SLM moderation, OrionFence PII) run in Guardway sidecar services deployed alongside it:

• PII detection — SSN, credit card, email, phone, API key patterns.
• Hate speech / toxicity.
• Prompt injection — jailbreak and instruction-override patterns.
• Keyword filters — custom deny lists (keywords and regex patterns); operator exception phrases suppress false positives on the injection and content filters.
• IP allow / block-lists.

Violations are logged, optionally redacted, and can fire webhooks or block the request. See Guardrails. What the gateway persists about a violation is redacted first (v0.4.41+). The stored preview on a guardrail event has every span the built-in content filter recognises masked before the row is written — even for monitor-mode policies; entities detected only by the model-backed checks, outside those patterns, may still appear in the preview. The full request/response replay payload is captured only if your org explicitly opts in (store_replay_payloads).

​

Data retention

• On the gateway — logs, guardrail events and traces are stored in the gateway’s PostgreSQL database (traces additionally in Jaeger); persist its data volume (the compose default maps database_data to /var/lib/postgresql/data) to survive restarts. Retention is whatever your database and Jaeger deployment keep — the gateway does not impose a schedule. The /var/lib/guardway volume holds only the gateway’s cloud credentials.
• On the cloud dashboard — aggregate usage and spend metrics are retained for the life of your subscription. Administrative audit logs are retained for 30 days, and raw request-log events age out on a rolling 30-day window. With the v0.4.41+ default, those events carry no request or response bodies; bodies sent by older gateways or opted-in deployments age out on the same 30-day window.

​

Compliance

Guardway’s architecture is built to support:

• SOC 2 — centralized auth, RBAC, audit logging, TLS in transit, key management, access reviews.
• HIPAA — centralized audit logs, PII guardrails, per-user access, automatic logoff (see Console).
• PCI DSS — encryption at rest for secrets, credit-card PII detection, unique user identification, full audit trail.
• GDPR — PII detection and redaction, data minimization (prompt bodies stay on your gateway by default from v0.4.41), incident-response support via audit log export.

For control-level mappings, see ISO/IEC 42001 and the EU AI Act pages. Formal certifications are pursued per plan; email compliance@guardway.ai for your current attestation package.

​

Reporting a security issue

Email security@guardway.ai with a proof-of-concept, affected version, and your contact details. We aim to acknowledge reports within one business day, follow coordinated disclosure, and credit reporters with permission.