Dograh

API Key Safety for Voice AI: BYOK, Rotation and Service Keys

API Key Safety for Voice AI: BYOK, Rotation and Service Keys
TechnicalNovember 6, 2026·7 min read

API Key Safety for Voice AI: BYOK, Rotation and Service Keys

Abhishek Kumar
Abhishek Kumar·Co-founder, Dograh AI

Co-founder of Dograh, building the future of open-source voice AI agents. Own your voice AI stack.

Keep voice AI keys out of prompts and code, and rotate them with an overlap so calls keep working. Model keys can sit in a pool, so add the new key before removing the old one. A Twilio Auth Token cannot overlap, so swap it in a quiet hour and place a test call.

Key Takeaways

  • Model keys rotate with no downtime: add the new key, then remove the old.
  • Promoting a new Twilio Auth Token deletes the old one, so update Dograh at once.
  • Dograh service keys expire after 90 days by default, so plan the renewal.

This post is part of our guide to voice AI for developers, where every programmatic path starts with an API key kept in a secret manager. Below, we map where each key lives in a self-hosted Dograh install, then show how to rotate each kind without dropping calls.

Where each key lives in a self-hosted stack

A voice agent holds more keys than most web apps, because every call touches a phone provider and several model providers. On a self-hosted Dograh install each kind of key is added on its own sidebar page and kept in a different place.

KeyWhere you add itWhere it is kept
Model provider keys (LLM, speech-to-text, voice)ProvidersYour own database, masked when read back
Phone provider keys, such as a Twilio Account SID and Auth TokenTelephonyYour own database, masked when read back
Keys your tools and webhooks send to other systemsCredentialsYour own database
Dograh API keys (dgr_)DevelopersOnly a SHA-256 hash and the first 8 characters
Dograh service keys, for Dograh's own modelsDevelopers, then a Dograh provider connectionYour own database, with the provider connection
Platform secrets, such as OSS_JWT_SECRETEnvironment variablesYour servers' environment

Because the keys sit in your own database, database access and backups are part of key safety. Limit who can query that database, and treat every backup copy with the same care as the live one. Saved secrets never come back to the browser in full, and when you edit a phone connection, sending the masked value back keeps the stored secret as it is.

Why old keys stay valid for years

Teams skip rotation because a careless swap breaks production. GitGuardian's secrets sprawl report found that 64% of the valid secrets it detected four years earlier still worked, and it puts the delay down to that fear of outages. A rotation plan that cannot drop a call is what gets rotation done.

The OWASP secrets management cheat sheet sets the rule plainly: rotate regularly "so that any stolen credentials will only work for a short time" and revoke an exposed key at once. Keep separate keys for test and production, too, so a leaked test key never reaches live calls.

One place a key must never go is the agent's prompt. OWASP's entry on system prompt leakage says the system prompt "should not be considered a secret", and a caller can talk a model into reading its instructions aloud. Tools carry their keys through Credentials, so the model never sees them.

Rotate model keys with a key pool

Model keys are the easiest to rotate, because a provider connection can hold more than one. In the connection editor under Providers, Add API Key puts each key in its own row, and every call picks one of the keys in the pool at random. That overlap is the whole trick. Old and new keys work side by side while you check the new one.

Three frames of one provider connection's key pool: a new key is added next to the old one and checked, test calls each pick one of the two keys, then the old key is removed and revoked at the provider.
A credential update keeps no copy of the old value, so keep the old key alive at the provider until your test calls pass. A rejected key leaves the existing connection unchanged, so a typo never takes calls down.

The sequence takes a few minutes. Create the new key in the provider's console, add it to the pool and save. Dograh checks every key in a pool before saving, and a rejected key leaves the existing connection unchanged, so a typo never takes calls down. Place a few test calls, then remove the old key from the pool and revoke it in the provider's console.

Two details from the provider connection setup matter here. A call that has already started loads the connection's current keys, so nothing needs to wait for calls to end. And a credential update replaces the stored values with no copy kept, so keep the old key alive at the provider until your test calls pass. Pools also spread load across accounts, which our post on BYOK vs managed models covers for spend and rate limits.

Dograh

Open Source Alternative to Vapi / Retell

Self-hosted voice agent platform — no per-minute fees

dograh-hq/dograh

Star on GitHub

Rotate a Twilio Auth Token in a quiet hour

A Twilio Auth Token cannot overlap the way a pooled key does. In Twilio's Auth Token docs, you create a secondary token and then promote it, and promoting "deletes the current primary Auth Token". From that moment the old token stops working everywhere.

Dograh uses the stored token for two jobs on Twilio. It authenticates outbound requests, and it checks the webhook signature in the X-Twilio-Signature header on every inbound request, which Twilio computes from your account's token. Until the new token is saved in Dograh, inbound calls fail that check.

So plan the swap. Pick a quiet hour, create the secondary token in the Twilio console and copy it. Promote it, then paste it straight into the Twilio connection under Telephony in Dograh, leaving the Account SID as it is. Place one inbound and one outbound test call before you leave the screen. The window between promote and save is short, but it is real, so keep it to a quiet hour.

Dograh API keys and service keys

Dograh API keys start with dgr_ and open up the API, the SDKs and the API Trigger. Only a SHA-256 hash of each key and its first 8 characters are stored, so a key cannot be read back and the screen shows it only once. Each key has full access to your organization, so give every system its own key. To rotate one, create the new key under Developers, deploy it to the system that uses it, then archive the old key.

Service keys are a different thing. They let a provider connection use Dograh's own managed models, and API keys and service keys are created on the same Developers page. Each service key expires after 90 days by default, and the page shows the Expires date. On Dograh Cloud, creating one needs a verified email and the matching team selected. A self-hosted install gets its key from app.dograh.com/get-service-key, and usage is billed to the Cloud account that owns it.

Rotate a service key before its expiry date. Create the new key, put it on the Dograh connection your model configuration uses, place a test call and then archive the old key. Archiving is one-way, since an archived key cannot be reactivated. All the Dograh services in a single run share one service key, so swap it on the connection, never service by service. For dgr_ keys in a secrets manager and the rest of the account settings, see voice AI security for phone agents.

Platform secrets and what to do after a leak

A self-hosted install also runs on secrets that never appear in the app. The environment variables reference lists them, including OSS_JWT_SECRET, which signs logins, the MinIO storage keys, TURN_SECRET for browser calls and LANGFUSE_SECRET_KEY for traces. Changing OSS_JWT_SECRET signs everyone out, so schedule it like any other change.

TELEPHONY_WS_TOKEN_SECRET deserves a look on a phone setup. It signs the media WebSocket URL and the Telnyx call-events webhook URL, and checks stay off until you set it. Set the same value on every process that places or receives calls, and turn on TELEPHONY_WS_TOKEN_ENFORCE to reject connections without a valid token.

When a key leaks, revoke it first and investigate second. Revoke it at the provider, or archive it in Dograh, then rotate it with the steps above and search your repos and chat history for other copies. After that, check what the key could reach and who opened call records while it was exposed, which is where an auditable voice AI stack earns its keep.

Join the Dograh Community

Dograh is an OSS alternative to Vapi. Join our Slack community for queries, releases, best practices & community interactions.

Glossary

Key pool
Several API keys for the same provider held on one connection, with each call picking one at random. Adding the new key before removing the old one rotates a model key with no gap in service.
Secondary token
The second Twilio Auth Token you create to rotate the first. Promoting it deletes the old primary at once, and anything still using the old token, including webhook signature checks, fails until it is updated.
Service key
A Dograh key that lets a provider connection use Dograh's own managed models. It expires after 90 days by default, is billed to the Cloud account that owns it, and cannot be reactivated once archived.
Webhook signature
A header a phone provider adds to each request, computed with your account's secret, so the receiver can prove the request is genuine. Dograh checks Twilio's X-Twilio-Signature with the stored Auth Token.

Frequently Asked Questions

Get started with Dograh

Build, deploy, and scale AI agents with Dograh. Join the community of developers building the future.