MCP database credential rotation: revoke old agent access without downtime

A database password is not rotated when the new secret exists. It is rotated when the old identity can no longer open a connection—and the team can prove that without breaking live agent workflows.

MCP deployments make that distinction important. Credentials can be held by an on-premise agent, a secret manager, a connection pool, a deployment revision, a test client, or a forgotten worker. Updating one field does not retire all of those paths.

Define the rotation boundary first

Inventory the database identity, every runtime that can use it, secret versions, connection pools, replicas, environments, owners, and emergency paths. Record whether the identity is shared. If production and staging use the same role, separate them before treating rotation as routine.

The target state is explicit: one current secret version, known consumers, least-privilege grants, no active sessions for the retired identity, failed authentication with the old secret, and an operation record linking the change to verification.

For storage controls around that boundary, see how to store credentials for MCP servers.

Choose rotation or identity replacement

Some systems can change a password on one role. Others are safer with a new role such as mcp_reader_2026_08, equivalent reviewed grants, and later deletion of the old role.

Identity replacement makes overlap and rollback visible, but it can complicate ownership and grants. In-place rotation is simpler, but cached connections may remain valid after the password changes. Whichever pattern you use, treat credential validity and session validity as separate controls.

Prepare the new credential without widening access

1. Create the secret with a new version or new database role.
2. Apply the same or narrower reviewed grants—never copy privileges blindly.
3. Set an owner, creation time, expiry or next-review date, and allowed environment.
4. Make the secret available only to the intended runtime identity.
5. Test authentication through the real network and TLS path, not from an administrator laptop alone.

A rotation should not silently reintroduce broad schema grants or bypass row-level policy. Review the database role and approved objects as part of the change.

Use a bounded dual-credential window

Zero-downtime rotation usually needs a short period when both old and new credentials work. Declare the start, maximum duration, owner, and abort condition before opening that window.

Deploy the new secret version to a small runtime slice first. Verify connection acquisition, read-only enforcement, tenant scope, query limits, latency, error rate, and audit correlation. Then move the remaining workers.

The overlap is a migration tool, not a rollback plan. If it has no deadline, the organization has created two valid production credentials.

Drain pools deliberately

Connection pools can keep sessions authenticated with the retired secret for hours. A successful new connection proves only that the new credential works.

Configure a bounded connection lifetime, rotate or restart workers in controlled batches, stop new checkouts from old revisions, and observe active sessions by application name, database role, client address, and deployment revision. Cancel only when workload owners understand the effect.

For short-lived identity patterns that reduce this exposure, see short-lived credentials for AI database agents.

Verify the workflow, not just the login

Run representative positive and negative checks:

• an approved query returns the expected bounded result;
• an unauthorized table, column, tenant, or environment is denied;
• write operations remain unavailable;
• timeouts, row limits, and cancellation still work;
• the operation appears under the new runtime and database identity;
• no secret value appears in logs, traces, errors, or deployment output.

Compare evidence from the MCP layer, runtime, secret manager, and database. A green health endpoint does not prove the authorization boundary survived the change.

Revoke, then prove revocation

After all consumers use the new version and old sessions have drained, revoke the old password or role. Remove the old secret from runtime access and disable obsolete deployment revisions.

Now perform the check that rotations often omit: attempt a fresh connection with the old credential from an authorized test path. It must fail. Confirm there are no remaining sessions or successful authentications tied to the retired identity after the cutoff.

Record the new version, affected runtimes, verification cases, revocation time, old-session count, exceptions, and next rotation date. Do not record the secret itself.

Keep rollback narrow

Rollback should mean restoring the previous application revision while it can authenticate through an approved current path. It should not mean leaving the old secret valid indefinitely.

Predeclare rollback triggers: authentication failures above threshold, permission mismatches, missing audit correlation, database saturation, or an inability to cancel work. If rollback requires the old credential, time-box that exception, assign an approver, and repeat revocation after recovery.

Test rotation before an incident

Run the procedure on a schedule and after changes to database roles, secret providers, agent deployment, or pool configuration. Include a compromised-credential exercise where the overlap window is skipped and existing sessions are terminated.

A useful measure is not “last updated.” Track time to distribute, time to establish new connections, time to drain old sessions, time to revoke, and time to prove failure of the old credential.

Where Conexor fits

Conexor provides MCP infrastructure for connecting AI clients to databases and APIs through governed tools. Its security model includes an on-premise agent, encrypted credentials, scoped access controls, read-only enforcement, and audit logging. Credential rotation should reinforce those boundaries instead of becoming a separate manual exception.

Explore the Conexor security model

For database-role design, continue with scoped credentials for MCP database servers.