Security

How Coco Router protects access, credentials, and spend. Coco Router sits between your applications and every model provider, so its security model is mostly about one thing: keeping provider credentials and budgets under tight, auditable control while your apps hold nothing sensitive.

Access

  • No public sign-up. Admin and workspace credentials are provisioned by the Cocolevio team. There is no self-service registration, so an unknown party cannot create an account.
  • Admin sign-in to the consoles is username and password. Destructive actions in the Dashboard — block, unblock, change budget, delete a key — require the admin password again, so a left-open console can't be used to wreck keys.
  • TLS everywhere. All traffic to router.cocolevio.com is HTTPS.

Provider credentials never leave the gateway

This is the core benefit of routing through Coco Router:

  • Your applications hold a virtual key (details), never a provider key. OpenAI, Google, OpenRouter, AWS, and every other provider credential lives only in the gateway's server-side configuration.
  • The Lead Agent's Coco CRM API key is likewise held server-side and is never exposed to browsers or client apps.
  • Because apps never see provider keys, rotating or revoking a virtual key never touches provider credentials — you can cut off one app instantly without affecting anyone else.

Virtual keys as blast-radius control

Every application and teammate gets their own key, which makes each one a small, independently controllable unit:

  • Budgets. A per-key Max Budget is a hard lifetime cap — once spend hits it, the key stops working. Always set one on any key embedded in client-side code or shared externally, so a leak can't run up an unbounded bill.
  • Expiry. Keys can be created with an expiry so short-lived access cleans up after itself.
  • Allow-lists. A key can be restricted to specific models.
  • One-time secrets. A key's sk-… secret is shown once at creation and only ever displayed masked afterward.

If a key leaks, the exposure is bounded by its budget and allow-list, and you can block or delete it from the Dashboard in seconds.

Auditability

  • Per-key attribution. Every request is logged against the key that made it, with its model, tokens, cost, latency, and status. The Dashboard and Logs give you a complete, per-application record — useful for spotting anomalies as well as for cost.
  • Routing decisions are recorded too, so you can see which tier and model served any request.

Good practices

  • One key per application, never a shared key, so you can attribute spend and revoke access individually.
  • Always set a budget on keys that ship inside apps or leave your control.
  • Rotate keys periodically and delete ones no longer in use.
  • Treat virtual keys like passwords — never commit them to source control or paste them into client-side code that ships to browsers. Call the gateway from your backend where you can.