Security
Honest account of how GateRelay protects your data — written for buyers, not auditors.
What's in place today
- API authentication: every non-public endpoint requires a key — workspace keys for management, per-agent keys for the gateway. Keys are stored only as SHA-256 hashes; a leaked database does not leak usable keys.
- Deny-by-default authorization: an agent can list and call only the tools its allowlist explicitly names. Cross-workspace access is impossible by construction — every read is scoped to the key's workspace (covered by automated tests).
- Credential handling: upstream auth headers are injected server-side and never returned by any API response or written to logs. Audit arguments are redacted for secret-looking keys before storage.
- Input validation: every endpoint validates and bounds its inputs; malformed requests get a
400, never a stack trace. - Transport: the service is designed to run behind TLS; we terminate HTTPS at the reverse proxy and never accept credentials over plain HTTP in production.
- Payments: checkout and card handling are done by Stripe; card numbers never touch our servers.
What we don't claim
- We are not SOC 2 certified and have not completed a third-party penetration test. We'll say so plainly until we have.
- Stored upstream auth headers are not yet encrypted at rest in v1 — the data directory must be protected like a secrets file. Encryption at rest is on the roadmap.
- Single-node store in v1 — back it up daily (the audit log is the product's evidence trail). Multi-node scale-out is a later milestone.
- The gateway limits what agents can reach; it does not make a permitted action safe, and it cannot stop every prompt injection. Least-privilege allowlists are the control; we enforce them, you write them.
Report a vulnerability
Email don+gaterelay@lifeofmorr.com with details. We aim to acknowledge within 2 business days.