Why do stored database credentials increase risk even for read-only table queries?

Why This Matters for Security Teams

Stored database credentials are risky because they do not just authorize a query, they create a reusable identity that can be copied, replayed, and embedded across scripts, CI pipelines, and analyst tooling. A read-only account still reveals metadata, table names, and environment structure, which can help an attacker map the system and plan the next move. That is why the issue belongs in non-human identity governance, not only database hardening.

NHIMG research on secret exposure shows how quickly attackers move once credentials are visible, with LLMjacking: How Attackers Hijack AI Using Compromised NHIs documenting access attempts against exposed AWS credentials in minutes, not days. The broader pattern also appears in the Guide to the Secret Sprawl Challenge, where durable secrets keep expanding the attack surface even when the intended use case looks limited.

Best practice is evolving toward short-lived, context-bound access because persistent database secrets tend to outlive the workload that needed them. In practice, many security teams discover the risk only after a credential has already been copied into a notebook, build log, or support bundle.

How It Works in Practice

A read-only database account still behaves like a standing credential. If that secret is stored in plain text, a config file, a vault with broad retrieval rights, or an application environment variable, any process that can read the secret can impersonate the workload. Once copied, the credential can be reused outside its original control plane, which defeats the purpose of limiting the SQL verb to SELECT.

The operational fix is not simply “use stronger passwords.” It is to reduce the lifetime and blast radius of the identity. Current guidance suggests combining workload identity, ephemeral secret issuance, and runtime policy checks. The OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 both support reducing standing access and improving traceability for machine actors.

• Issue credentials just in time for a task, then revoke them automatically when the job ends.
• Prefer workload identity and token exchange over shared database passwords.
• Scope access to a specific database, schema, and query class rather than a broad environment.
• Log retrieval, use, and revocation events so secret reuse can be detected quickly.

NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets frames the key distinction well: static secrets are durable attack targets, while dynamic secrets reduce the time window in which a copied credential remains useful. These controls tend to break down when legacy applications require long-lived connection strings because the surrounding architecture cannot rotate credentials without service interruption.

Common Variations and Edge Cases

Tighter database access often increases operational overhead, requiring organisations to balance lower credential risk against application compatibility and support burden. Read-only access is still useful, but it is not inherently safe when the same secret is reused across many hosts, service accounts, or third-party tools.

There is no universal standard for this yet, but current guidance suggests treating read-only secrets as sensitive assets rather than “low-risk” exceptions. For example, a read-only account may still expose tenant names, table relationships, feature flags, or backup database identifiers that help an attacker move from reconnaissance to targeted abuse. That is why hardening must include secret storage location, retrieval path, and query observability, not only SQL permissions.

Where organisations have strong controls, the better pattern is to pair least-privilege database roles with short-lived access tokens and policy checks aligned to workload context. For additional practitioner context, see NHIMG coverage of secret leakage in the MongoBleed breach and the Emerald Whale breach, both of which show how exposed data systems and embedded secrets turn narrow access into broader compromise. The main edge case is highly static reporting or ETL jobs, where rotation can disrupt downstream consumers unless the migration is engineered first.

Related resources from NHI Mgmt Group

• Why do non-human identities create compliance risk even when policies exist?
• Why do Salesforce integrations increase NHI risk?
• Why do GenAI integrations create security risk even when the model is approved?
• Why do acquisitions often increase identity risk?