The deployment handoff where an engineer discovers the telephony credential is visible in an admin screen: a practical secrets-management checklist for voice-agent platforms

A telephony credential should never be readable from an admin screen after it has been saved. During a deployment handoff, treat any visible API key, token, or secret as exposed: revoke it, replace it, and fix the storage and display path before enabling calls.

Start with the handoff boundary

The handoff is where a secret often moves from a developer’s local environment into a shared system. List every credential required for the voice agent to operate: telephony-provider keys, webhook signing secrets, assistant-runtime credentials, database connection strings, and billing-provider keys.

For each one, record three things: who owns it, where the approved value lives, and which service reads it at runtime. Do not put the actual value in the handoff document, ticket, chat thread, or screen recording.

A practical handoff note might say: “Telephony credential is stored in the production secret store. The calling worker has read access. The admin team can replace it, but cannot retrieve the saved value.” That gives the next engineer what they need without creating another copy of the key.

Make saved secrets write-only

An admin screen may need a field to add or rotate a credential. It should not turn into a vault browser.

After a secret is saved, replace the value with a masked state. Show only metadata that helps an operator confirm the configuration, such as the provider name, environment, date of last update, and a short non-sensitive identifier if the provider supports one. Never rely on partial masking as protection. A screen that shows most of a token, or exposes it through page source, a network response, browser autofill, logs, or an API endpoint still leaks the secret.

Asenda Talk’s admin secrets management is designed around write-only, masked, environment-aware handling. Test that behavior in the actual deployed environment, not only in the interface. Enter a test credential, save it, reload the page, inspect the relevant admin API response, and confirm the original value never returns to the browser.

Separate development, staging, and production

One credential used across every environment makes a mistake expensive. A developer testing a webhook locally should not have access to a production telephony account, and a staging deployment should not be able to place chargeable calls with the production key.

Create distinct provider credentials and distinct secret records for development, staging, and production. Label them clearly in the admin interface and in the provider account. Restrict production access to the smallest group that needs it.

This matters especially for voice platforms because a valid credential can affect real calls, caller reputation, and spending. In Asenda Talk, metered per-minute billing includes an operator-controlled real-money gate. Keep that gate closed while validating secret storage, webhook delivery, and call-event tracking. A credential can be technically valid while the rest of the operational controls are still incomplete.

Verify the runtime path, not only the form

A masked form is one check. The agent still needs the secret at the point where it runs.

Trace the complete path from stored secret to runtime service. Confirm which component reads the credential, when it reads it, and what happens if the credential is missing, malformed, or revoked. The service should fail clearly without printing the secret into application logs, error trackers, or webhook payloads.

For a Vapi-orchestrated assistant runtime, validate that the runtime receives only the credential it needs. Do not pass broad provider account access into every worker or agent configuration. Scope permissions to the required capability where the provider allows it, such as sending calls or reading a limited set of status events.

Run a deliberate failure test with a revoked test credential. The expected result is an understandable operational error, no call attempt, and no credential value in logs.

Rotate immediately after any exposure

If an engineer can read a production telephony credential in an admin screen, assume that anyone with equivalent access could have copied it. Masking the field afterward does not undo that exposure.

Revoke the credential at the provider, create a replacement, update the approved secret location, and verify the runtime with the new value. Then review access logs, deployment logs, support tickets, screenshots, and recordings made during the incident. Remove or restrict any material that contains the value, following your organization’s incident process.

Rotation should also be routine. Set an owner and a review date for each production secret. Rotation has a tradeoff: a rushed change can interrupt calling. Reduce that risk by testing the new credential in staging first, scheduling the production change, and confirming call lifecycle events continue to arrive after the update.

Pair credentials with call controls and audit records

Secret management is part of safe call operations, not a separate admin task. A telephony key makes it possible to initiate activity; consent, opt-out, lifecycle records, and spend controls determine whether that activity can be defended and reviewed.

Before a campaign moves toward production, verify that every call can be matched to its lifecycle events and that consent and opt-out records are retained. If a caller asks to stop in Twi, the suppression path needs evidence, not an informal assurance. See A Twi Stop Request. No Further Calls Until Suppression Is Proven. for the operational standard behind that check.

Outbound calling in Asenda Talk remains gated behind an explicit telephony-provider decision that has not been made live. Use the time before that decision to test configuration boundaries, secret rotation, and audit exports. Do not treat a saved credential as approval to place calls.

Use this pre-deployment checklist

• Confirm every credential has one approved storage location and a named owner.
• Save a test secret, reload the admin screen, and verify that its full value cannot be retrieved.
• Check browser responses, logs, error reports, and deployment output for secret leakage.
• Keep development, staging, and production credentials separate.
• Test a revoked credential and confirm the runtime fails safely.
• Keep the real-money gate closed until billing and call-truth records can be reconciled. Billed voice minutes need matching call events.
• Document the rotation procedure before a production credential needs replacing.

Assign one engineer to run this checklist against the deployed admin screen and one operator to confirm the call and billing controls. Record the results, rotate any exposed key, and leave outbound activity blocked until the provider decision and operational gates are complete.