Security, in plain language.
Renio exists for one reason: your AI keys should not be scattered across code, shared .env files or logs. Here are the protections built into the product, without the jargon.
Your real provider keys
Encrypted on arrival, never readable again
Your provider key is encrypted as soon as it arrives (AES-256-GCM, with a separate encryption key per customer). Its plaintext exists only in memory for a request — never written to disk, logs or error messages. Our database contains only encrypted values.
The dashboard cannot reveal them
The interface is write-only by design: you can add or replace a key, but never read it back. Even an internal request never returns your plaintext key — that capability does not exist in the code.
The vault’s master key is managed separately
Encryption relies on a master key managed by a dedicated key management service (KMS), with an audit log. A copy of our database alone is not usable without that separately held key.
Deleting keys
Deleting a connection removes its secret from the active database. Backups have their own retention periods: deletion does not immediately erase an earlier copy. Also revoke the key with its provider to invalidate any older copy.
Your Renio access keys (re_)
Shown only once
An access key’s complete secret is shown only when it is created. Afterwards, we retain only a SHA-256 hash, its prefix and its last 4 characters — enough to identify it, never to reconstruct it.
Permanent revocation
A revoked access key can never be accepted again. If its secret resurfaces a year later, access remains blocked — its hash remains banned.
Your conversations
A meter, not a recorder
The relay measures timestamps, provider, model, tokens, cost, duration and status. It stores neither your prompts nor the models’ responses.
No IP addresses or URL paths in the request journal
The relay’s request journal contains no IP addresses or request paths — only the billing metadata listed above. Infrastructure providers may process connection data under their own policies.
Control
Revoke access within seconds
Revoke an access key: it is permanent and takes effect across providers in under five seconds. In-flight requests associated with the revoked key are interrupted too. Your real provider key stays in the vault.
Budgets block new requests automatically
Each request reserves an amount before it is sent; new requests are refused when the available budget is exhausted. The provider’s final cost may differ from the estimate. Requests whose cost cannot be estimated are refused for capped access keys. Requests already sent may still incur charges, even if their stream is interrupted. If the budget counter is unavailable, new controlled requests are refused. Total budgets do not renew; monthly and daily budgets renew at the next period. Email alerts are sent at 80% and 100%.
Infrastructure and operating practices
Infrastructure in Europe
The relay, database and KMS are deployed in the European Union. AI providers then process requests according to their own regions and terms.
Fixed destinations
Provider hosts are defined by the adapters. Redirects and host overrides from test configuration are rejected in production.
Traceable access
The relay counts decryptions. Scaleway Audit Trail records key management operations, without guaranteeing a native event for every decryption. Operational alerts are configured separately.
Secret leak prevention
Automatic scanning on each commit and in continuous integration: an accidentally pasted secret causes the pipeline to fail before publication.
Minimal supply chain
The critical core uses the standard library; each added dependency is justified, pinned and scanned for vulnerabilities.
Separate permissions
The relay uses a dedicated Postgres role. Its KMS identity can decrypt vault keys without administering the master key.
Your provider accounts remain yours. If Renio is unavailable, you can reconfigure your applications to call their providers directly. Those direct requests then run without Renio’s controls or usage tracking.