Encrypted API relay with replay protection.
CRelay protects sensitive API payloads beyond HTTPS with AES-256-GCM encryption, timestamp freshness, route-bound AAD, and encrypted responses.
Open SDK. Public protocol. Hosted enforcement.
HTTPS protects the pipe. CRelay protects the payload.
After TLS termination, sensitive payloads may still pass through logs, proxies, queues, and internal services. CRelay adds application-level payload protection and replay defense for sensitive API calls.
Once TLS terminates, your payload is plaintext inside infrastructure. Logs, queues, and proxies see everything.
Without replay protection, captured requests can be replayed. Identical payloads accepted twice means double charges, duplicate actions.
Without route-bound AAD, a valid encrypted payload may be accepted in the wrong context.
How it works
SDK encrypts request
Your client SDK encrypts the request payload with AES-256-GCM, binding the AAD to method, path, and tenant.
Gateway verifies AAD, freshness, and replay
The gateway checks timestamp freshness, validates the AAD matches the route, and rejects replays.
Gateway forwards to allowlisted upstream
Only pre-approved target URLs receive the decrypted request.
Gateway encrypts response back to SDK
The upstream response is encrypted with response-specific AAD before returning to the client.
CRelay operates within a trusted gateway boundary: the gateway decrypts requests to validate and forward them, then encrypts responses before they return to the SDK. This is how replay protection, AAD verification, and allowlist enforcement work in practice.
Security features
Authenticated encryption with 32-byte keys, 12-byte nonces, and 16-byte auth tags. Industry-standard envelope encryption.
Every request carries a unique nonce. The gateway rejects any nonce it has already seen within the freshness window.
Requests must arrive within a configurable freshness window (default 5 minutes). Stale envelopes are rejected.
Additional Authenticated Data binds each encryption to a specific method, path, and tenant. Prevents route confusion attacks.
Only pre-approved upstream URLs can receive forwarded requests. Prevents SSRF and unauthorized forwarding.
Responses are encrypted before returning to the SDK, using response-specific AAD (RESPONSE:/path:tenantId).
Zero-trust payload enforcement
CRelay does not assume a request is safe just because it arrived over HTTPS.
Every protected request must prove that it was encrypted with the correct key, created recently, not replayed, bound to the intended route, and sent only to an allowlisted upstream API.
CRelay decrypts inside the trusted gateway boundary to enforce these checks, forward the request, and encrypt the response back to the client.
Request and response bodies are protected with AES-256-GCM.
Duplicate request IDs and nonces are rejected.
Stale or future-dated envelopes are rejected.
Payloads are bound to the intended method, path, and tenant.
Requests can only be forwarded to approved upstream origins.
CRelay logs operational metadata, not plaintext payloads or response bodies.
Payload logging FAQ
Does CRelay log my payload?
No. CRelay does not intentionally log plaintext request or response payloads.
CRelay logs operational metadata needed for debugging and reliability, such as request ID, tenant ID, key ID, method, path, upstream status, error code, and duration.
It does not log raw API keys, encryption keys, plaintext payloads, request bodies, or response bodies.
Is CRelay zero-knowledge?
No. CRelay v0.1 is not zero-knowledge.
The gateway decrypts payloads inside the trusted gateway boundary so it can enforce replay protection, timestamp freshness, route-bound AAD, target allowlists, and response encryption.
Built for developers
Open SDK. Public protocol. Hosted enforcement.
CRelay keeps the developer-facing parts transparent: the SDK, protocol, threat model, and quickstart are open for review. The hosted gateway provides the managed enforcement layer for replay protection, freshness validation, route-bound AAD, target allowlists, and encrypted responses.
Review the envelope format, AAD rules, freshness model, and threat assumptions.
Transparent enough to trust. Managed enough to be useful.
Roadmap
Planned capabilities for teams protecting sensitive API payloads.
Enterprise key-management options for teams that need tighter control over key custody and rotation workflows.
Workload identity, route-level policies, policy decisions, key status metadata, and audited enforcement decisions.
Protect sensitive AI prompts, tool-call payloads, RAG context, and AI responses when routed through a customer-controlled AI proxy or backend.
CRelay will help teams encrypt AI request/response payloads, enforce freshness and replay protection, bind requests to intended AI routes, and restrict forwarding to approved AI proxy endpoints.
CRelay does not make third-party AI providers zero-knowledge. If your backend sends plaintext prompts to an external AI provider, that provider still receives the prompt. CRelay protects payloads across your application boundary and enforcement layer.
Payload protection patterns for GraphQL APIs while preserving CRelay's replay, freshness, and route-binding model.
Exploration of encrypted message enforcement for long-lived connections without weakening the HTTP API model.
Operational patterns for distributing key metadata across cloud environments.
A future audit surface for reviewing enforcement posture, operational metadata, and security events.
