RelayGate's threat model assumes the binary handles your most sensitive AI traffic. The architecture is shaped accordingly: a single statically-compiled binary with no runtime dependencies, signed Ed25519 receipts on every request, CEL-bounded ContextWorker execution, and zero plaintext credential storage in the managed plane.
RelayGate ships as one ~18 MB statically-compiled Go binary. CGO is disabled. There is no dynamic linking, no runtime package manager, no embedded interpreter. The binary's SHA-256 is published on every release; signed checksums are mirrored to two independent registries (GitHub Releases and a managed object store) so you can cross-check before you run.
Reproducible builds. The build is deterministic given the source revision. We publish the build command, build environment hash, and the resulting checksum so you can re-derive the binary yourself and prove it matches what we shipped.
ContextWorkers run inside the request lifecycle. Each Worker is isolated from peers: no shared memory, separate goroutine, scoped CEL evaluator, request-bound timeout. CEL is the policy language for routing, quotas, redaction, and access control — it is statically type-checked at config-load and cannot escape its sandbox. There is no eval. There is no shell-out. There is no network egress from inside CEL.
Workers that perform side effects (e.g., post-request audit, async retry) run on a separate scheduling lane with explicit egress allowlisting. The default config disallows all outbound traffic from a Worker; egress must be opted into per host.
The self-host binary stores backend API keys (OpenAI, Anthropic, Google, etc.) in the local vault — by default an encrypted file with a passphrase you choose. Production deployments use the included KMS adapter (AWS KMS, GCP KMS, HashiCorp Vault) so keys are decrypted only inside the binary's process memory and never persisted in plaintext on disk.
The managed tier never has plaintext access to your backend keys. The hosted-vault feature uses customer-controlled KMS-CMK as the wrapping key; we hold the ciphertext, you hold the unwrap authority.
RelayGate's own signing keys for Ed25519 receipts are similarly KMS-protected. The default self-host configuration generates a new Ed25519 keypair on first run and stores the private half in the local vault. The managed tier offers an HSM-backed signing service for customers who require hardware key protection.
RelayGate accepts inbound traffic on a single configurable port. Inbound listeners terminate TLS 1.3 with a minimum cipher suite of TLS_AES_128_GCM_SHA256. mTLS is supported and recommended for service-to-service deployments.
Outbound traffic from the binary is restricted to the configured backend hosts and the optional observability endpoint. There is no telemetry phone-home. The self-host binary never reaches RelayGate-owned infrastructure unless explicitly configured.
The managed tier is multi-tenant by default. Tenant isolation is enforced at three layers: per-tenant request routing, per-tenant CEL policy namespace, and per-tenant observability index. Cross-tenant data flow at the application layer is impossible by construction; CEL programs cannot reference state outside their tenant's namespace.
Customers requiring single-tenant deployment use the Enterprise tier; single-tenant customers get their own VPC, their own observability index, their own KMS root, and their own dedicated managed binary instance.
Every request produces an Ed25519-signed receipt. Receipts are TrueCom-compatible, Merkle-chained, and verifiable offline given the signing public key. The receipts log is a complete record of which agent called which backend with which policy decision.
SOC 2 Type I is in progress; report expected before GA. Penetration tests are conducted twice per year by an external firm. Customers under NDA can request the most recent summary letter.
Security reports go to [email protected]. PGP key fingerprint and a safe-harbor disclosure policy are linked from the about page. Critical reports get acknowledged within one business day and triaged within three.
In-scope: binary integrity, CEL sandbox escapes, ContextWorker isolation breaks, receipt forgery, key-vault unwrap flaws, multi-tenancy boundary violations. Out-of-scope: denial-of-service against the public marketing site; social engineering of staff; physical attacks. Eligible reports receive a bounty under our coordinated-disclosure program.
The Apache 2.0 binary phones nothing home. Run it air-gapped, run it on-prem, run it in a sovereign cloud. The protocol does not require the managed plane. We sell the operating experience around the binary, not the binary itself.