A database credential is not rotated until the old one fails

Creating a new database secret is the beginning of a rotation—not the end.

The old credential may still be held by an MCP agent, connection pool, deployment revision, test client, or forgotten worker. A successful login with the new secret proves only that the new path works.

A safer runbook is:

1. inventory every consumer and active session
2. create a new version or replacement database role
3. preserve or narrow the reviewed grants
4. open a short, explicitly bounded overlap window
5. canary the new credential through the real network path
6. drain pools and stop old revisions from creating connections
7. test positive and negative authorization cases
8. revoke the old credential
9. attempt a fresh login with the old secret and require failure

Track time to distribute, connect, drain, revoke, and prove revocation—not merely the secret's “updated at” timestamp.

And keep rollback narrow. Leaving both credentials valid indefinitely is not rollback; it is a second production access path.

Full runbook: MCP database credential rotation