Notifications
Clear all
Topic starter
09/06/2026 11:47 pm
TL;DR: Shared database passwords break attribution, auditability, and least-privilege enforcement because they tie access to a secret rather than a person or workload, according to Teleport. As AI agents begin reaching production data, unified cryptographic identity and session-level control become the baseline, not an enhancement.
NHIMG editorial — based on content published by Teleport: How to Eliminate Shared Database Passwords for MySQL, PostgreSQL, and More
Questions worth separating out
Q: What breaks when teams use shared database passwords?
A: Shared database passwords break attribution, weaken audit evidence, and make incident response slower because multiple people or systems can act under the same credential.
Q: Why do shared passwords create more risk for production databases?
A: Production databases are high-value targets, so a shared credential gives broad reach to anyone who learns it and often persists long after the original task is over.
Q: How do security teams know if database access attribution is working?
A: Attribution is working when every query can be tied to a unique executor, not just a shared login or generic account.
Practitioner guidance
- Replace shared database passwords with identity-bound certificates Use short-lived X.509 or equivalent identity-bound credentials for database sessions so access is tied to the executor and expires with the task.
- Map database permissions from current SSO roles Derive database access from live organisational attributes such as team or group membership, and revoke reach automatically when those attributes change.
- Require session MFA for write-capable database roles Gate INSERT, UPDATE, DELETE, and other state-changing operations behind per-session hardware key or biometric approval.
What's in the full article
Teleport's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples for connecting to MySQL and PostgreSQL with short-lived certificates.
- Role configuration details for read-only and read-write access mapped from SSO identity.
- Hardware key approval flow for write-capable database sessions.
- Audit log examples showing how query attribution is recorded at session level.
👉 Read Teleport's analysis of eliminating shared database passwords →
Shared database passwords and AI agents: what teams should change?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
10/06/2026 2:16 am
Shared database passwords are a responsibility failure, not just a secrets problem. The article shows that a shared username breaks the link between action and accountable identity, which is exactly what database audit, compliance review, and incident triage depend on. Once the same credential can represent multiple actors, the control surface becomes ambiguous and the evidence chain weakens. Practitioners should treat shared passwords as a governance failure that obscures ownership.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
A question worth separating out:
Q: How should organisations govern AI agents that need database access?
A: Organisations should give AI agents narrow read access by default, separate write privileges from query privileges, and require human approval for any session that can modify data. That keeps agent activity inside a clearly bounded role while preserving auditability and reducing the chance of unsupervised state change.
👉 Read our full editorial: Shared database passwords are breaking identity accountability
