╔═══════════════════════════════════════════════════════════════════╗ ║ RUNGATE SECURITY · Governance Control Plane for AI Agents ║ ║ ║ ║ Every claim below is backed by code you can read. ║ ║ License: Apache 2.0 · source via early-access invite ║ ║ Contact: [email protected] · 72h ack ║ ║ Certs: SOC 2 Type II → 2026 Q4 (in progress) · §16 ║ ╚═══════════════════════════════════════════════════════════════════╝
1. Open Source & Auditable
The full server is Apache 2.0. The repository is currently private during early access; source access is granted on request to [email protected]. Every claim on this page names the module or behavior that backs it. If the code doesn’t match what you read here, email [email protected] — that’s a bug.
Self-hosting is the strongest audit: the managed cloud runs the same code, but if you need to verify enforcement happens exactly as described, request source access and observe directly.
2. Agent Token Storage
Agent tokens (rg_agt_*) are stored as SHA-256 hashes.
The raw value is displayed once at issue time and cannot
be retrieved afterward — lost tokens are rotated, not recovered.
Admin tokens (rg_adm_*) use the same storage pattern.
Both token classes are scoped: each carries a bound set of
permissions the server checks on every request. Token revocation
is immediate and logged.
3. Provider API Key Encryption
OpenAI, Anthropic, and other provider API keys entered into Rungate are encrypted at rest with AES-256-GCM before storage. The master key is environment-resident and rotated per deployment environment. Decryption happens only at request-forward time, in-memory.
If the SQLite file or a database snapshot leaks, the provider keys it contains are opaque without the master key.
4. Webhook Signing (HMAC-SHA256)
Every webhook delivery carries an X-Rungate-Signature
header computed as v1=HMAC_SHA256(secret, timestamp + "." + body).
Verify before trusting the payload.
Secrets are displayed once at subscription time, hashed in
storage, rotatable via a dedicated endpoint
(POST /api/webhooks/{id}/rotate-secret), and
support a dual-signature grace window during
rotation: Rungate sends both the new and previous signatures so
consumers can roll secrets without downtime. See
the integration reference §14
for verification code.
5. Webhook Replay Protection
Webhook payloads include X-Rungate-Timestamp.
Consumers should reject deliveries with a timestamp more than
5 minutes outside the current wall clock. Any
captured-and-replayed payload older than the window fails
validation even with a valid signature.
6. Transport Encryption
All public traffic to api.rungate.dev and the
dashboard is TLS 1.3 at the Railway-managed
edge. HTTP requests are redirected to HTTPS; there is no
plaintext endpoint. Legacy cipher suites are disabled.
Strict-Transport-Security: max-age=31536000; includeSubDomains
is set site-wide. The marketing site (this domain) additionally
sets a strict Content-Security-Policy, X-Frame-Options: DENY,
a restrictive Permissions-Policy, and
Referrer-Policy: strict-origin-when-cross-origin.
7. Rate Limiting
Per-agent, per-policy, and global rate limits are enforced in the proxy pipeline. Limits are configurable; the default sane caps catch runaway loops at the per-agent level (a single agent cannot flood the system even under a stuck retry).
Hitting a limit returns 429 with standard
Retry-After and X-RateLimit-* headers.
Rate limits are a coarse safety net; the
run-level budget ceiling is the
hard cost stop.
8. Multi-Tenant Isolation
Every database entity is scoped to an organization. Cross-tenant access is blocked at the query layer by role-based filters applied to ~60 admin endpoints. The multi-member security audit rounds (2026 Q1) specifically targeted this surface; fixes are in the commit history, each with a regression test.
9. Role-Based Access Control
Four roles, 57 checked actions.
| Role | Can |
|---|---|
| Owner | Everything. Including transferring ownership, deleting the org, and billing. |
| Admin | Manage agents, policies, provider keys, webhooks, members (except Owner). No billing, no deletion. |
| Member | View analytics, approve/reject gates, view runs. Cannot create agents or change policies. |
| Viewer | Read-only across the org. No writes. |
Dashboard UI enforces the same permission checks as the API — no capability is surfaced that the server would reject. Every role change is logged.
10. Platform Admin Separation
Platform-level operations (account CRUD, cross-org audit access)
use a distinct rg_platform_* token class with:
- Mandatory IP allowlist (request IP not on list → 403).
- Mandatory token expiry (no long-lived platform tokens).
- No UI surface — platform tokens are CLI-only.
- Zero access to organization content (policies, runs, logs). Only account-level metadata.
This separation means a compromised platform credential cannot read customer workflow data.
11. Audit Trail
Every admin action against the managed cloud is logged to
platform_audit_log. Every run is fully
reconstructable via /v1/runs/{id}/steps: every
call, tool invocation, retry, approval gate, cost, latency, and
approver. Logs include request origin, actor, timestamp, and the
before/after state of the modified resource.
Retention is per tier: 30 days on Free, 90 on Pro, 1 year on Growth, custom on Enterprise. Self-hosted retention is customer-controlled.
12. Account & Data Deletion
Account deletion is a 24-hour grace window followed by cascade deletion of all org-scoped data: agents, policies, provider keys (cryptographically shredded by deleting the envelope), runs, webhooks, audit logs. Once the grace window elapses, the data is unrecoverable.
GDPR data export and deletion requests should be sent to
[email protected]; we respond within the statutory
30-day window.
13. Infrastructure & Data Residency
The managed cloud runs on Railway in us-east-1.
Primary data store is SQLite (single-tenant per deployment) with
optional Redis for rate-limit counters at scale. Webhook delivery
uses a Cloudflare Worker with R2-backed retry queue for
durability.
US-only today, by design — single-region simplifies the threat model and audit surface. EU/regional residency is an Enterprise option pending customer demand.
Sub-processors: Railway (hosting), Cloudflare (edge delivery, webhook retries), OpenAI/Anthropic (LLM providers — agent traffic is forwarded to whichever provider the policy allows). Provider keys customers enter never leave the Rungate boundary for any purpose except forwarding the request they belong to.
14. Dependency Security
Production dependencies are version-pinned in
package-lock.json + uv.lock. GitHub
Actions in CI are SHA-locked (not tag-locked) to prevent supply
chain tag-rewrites. Dependabot is enabled; security patches land
within 72 hours of publication.
15. Security-Focused Testing
Regression coverage for the security-critical surface lives alongside the feature tests and runs on every commit:
- Multi-tenant isolation. ~60 admin endpoints have cross-tenant regression tests. New queries that touch org-scoped data are blocked from merging without a matching isolation test.
- RBAC enforcement. All 57 role-checked actions have explicit role-grid tests (Owner/Admin/Member/Viewer × action). A permission change requires the matching row in the test grid.
- Webhook verification. HMAC computation, timestamp window, dual-signature grace flow, and replay-attack cases are exercised on both the signing side and verification helpers we ship in the SDK.
- Auth boundaries. Scope-violation, expired-token, IP-allowlist-miss, and hashed-equality-timing tests run on every commit.
- Real-provider smoke. End-to-end tests against live OpenAI + Anthropic endpoints verify the proxy pipeline before every deploy, catching regressions that mocks would miss.
No paid third-party security audit or SOC 2 certification today. Pentests are scheduled post-registration-open. We will only display badges we have actually earned. The full test suite (including the security-focused categories above) is public in the repo — read it, fork it, extend it.
16. Compliance Posture
SOC 2 Type II is on the roadmap for 2026 Q4. We are in pre-audit readiness today. GDPR, HIPAA, ISO 27001, and a public bug bounty are staged behind it.
Below is the honest current state. This page updates as items land; we will not display a badge we haven’t earned.
| Framework | Status | Target |
|---|---|---|
| SOC 2 Type II | Pre-audit readiness | 2026 Q4 |
| GDPR | DPA available on request | Before public registration |
| HIPAA / BAA | Not available | Enterprise tier, date TBD |
| ISO 27001 | Evaluating | Post-launch |
| Public bug bounty | Email-based disclosure today | HackerOne post-launch |
17. Incident Response
On confirmed impact to customer data or availability, we notify affected customers within 72 hours via email to the account owner. Notification includes: what happened, what data was affected, what we’ve done to contain it, what the customer should do.
Post-incident reviews (root cause + remediation) are published within 30 days for any incident that affected customer data or availability > 4 hours. Reviews are archived on the status page.
18. Responsible Disclosure
Report security issues to [email protected]. Response SLA:
- 72 hours — acknowledgement that we received your report.
- 7 days — initial triage + severity assessment.
- 30 days — fix deployed for critical/high severity; status update for medium/low.
Safe harbor. We will not pursue legal action against researchers acting in good faith who access only the minimum data needed to demonstrate a vulnerability, do not harm other users, do not exfiltrate data, and give us reasonable time to remediate before public disclosure.
No paid bug bounty today. Researchers who report confirmed vulnerabilities receive credit in the changelog and a written acknowledgement for their CV.
Machine-readable contact: /.well-known/security.txt
19. Related
- Privacy policy — data we collect and why.
- Status page — uptime + incident history.
- Webhook signature verification — code example.
- security.txt — RFC 9116 contact.