Split-key envelope
A database copy contains ciphertext and one half. An inspected app contains the other half without ciphertext. Neither side can recover the provider key alone.
Credential protection
Put policy in front of every AI key.
Keep provider credentials out of distributed apps, narrow what each service can call, and verify devices before the request leaves your boundary.
Provider-native transitSplit-key envelopesRequest bodies are not stored
Defense in depth
A proxy should do more than hide one environment variable.
The credential boundary, application identity and traffic policy work together. Each layer limits a different failure mode.
Device attestation
Require Apple App Attest, DeviceCheck or Firebase App Check before the credential is opened and the upstream request is sent.
Endpoint allowlists
Permit only the provider paths that a service needs. A key for one service cannot be reused against another service.
Model policy
Allow specific models or pin requests to one model so a leaked client token cannot select an unexpected expensive model.
Rate and spend limits
Bound traffic by app key, IP or device. Add a recorded monthly spend budget when the gateway must reject new requests.
Rotation and revocation
Name keys by app or release, rotate with a grace period, and revoke the affected client without changing unrelated services.
Provider-native proxy
Change the origin and auth header—not the provider API.
Append the upstream path to the service gateway URL and replace the real provider credential with an app key. JSON, SSE, binary payloads and WebSocket frames keep their provider-defined shape.
- The URL selects the project and service.
- The app key authorizes that service and carries the client half.
- HyperProxy injects the provider's expected auth scheme.
request.shHTTPS
curl -N \
https://api.hyperproxyai.com/PROJECT/SERVICE/v1/responses \
-H "X-HyperProxy-Key: hp_live_…" \
-H "Content-Type: application/json" \
-d '{"model":"gpt-5","input":"Hello"}'Request lifecycle
Reject unsafe traffic before provider spend.
Identify and verify
Resolve the service, validate the app key and require the configured device proof.
Apply policy
Check endpoint, model, rate, quota and enforced budget rules before opening the credential envelope.
Forward and measure
Inject provider auth, stream the native response and record metadata such as status, tokens, latency and estimated cost.
Data handling
Keep content out of the analytics record.
| Data | How HyperProxy handles it |
|---|---|
| Prompts and completions | Streamed through; not written to application logs or analytics storage |
| Provider credentials | Encrypted as a split-key envelope; plaintext exists briefly in gateway memory |
| Request metadata | Status, timing, provider, model, token totals and optional client/session IDs are retained |
| Payment information | Handled by Paddle rather than stored by HyperProxy |
FAQ
Secure AI proxy questions.
Why is a backend proxy safer than putting the key in an app?
The credential never has to enter the distributed binary, and the server can enforce authorization and policy before every provider call.
Can the database decrypt a provider key by itself?
No. Stored ciphertext and the encrypted server half are insufficient without the client half carried by an authorized app key.
Does the gateway translate provider payloads?
No. It preserves provider-native request and response formats while applying transport-independent policy around the call.
Related