Attribution is working when every query can be tied to a unique executor, not just a shared login or generic account. Teams should be able to answer who ran the query, from where, under which role, and during which session. If any of those links are missing, accountability is incomplete.
Why This Matters for Security Teams
Database attribution is not just an audit detail. It is the difference between a query trail that can support incident response and one that collapses into a shared service account with no accountable executor. When teams cannot prove who or what ran a query, access reviews, forensic timelines, and separation of duties all weaken at once. That problem is common in service accounts, CI pipelines, and application pools where identity is inherited, reused, or obscured.
NHI Management Group research shows how often the wider identity picture is already weak: only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. In practice, poor attribution usually means the database is recording activity, but not accountability. That gap is why the OWASP Non-Human Identity Top 10 treats weak identity evidence and over-permissive access as core risks rather than logging concerns. In practice, many security teams encounter attribution failure only after an investigation needs a single answer and the logs can only point to a shared login.
How It Works in Practice
Attribution works when the database session carries a durable identity chain from the workload to the query event. That usually means the application or agent authenticates with a unique workload identity, the database sees a distinct session context, and logging captures enough metadata to reconstruct the executor, role, source, and time. For autonomous systems, current guidance suggests moving away from static shared secrets and toward short-lived, task-scoped credentials, because the executor may be a service, pipeline, or agent that changes behaviour from one request to the next.
Practitioners usually combine several controls:
- Unique workload identity for each app, pipeline, or agent, rather than a generic database login.
- Just-in-time issuance of credentials or tokens with tight TTLs, so each session maps to a specific task window.
- Database session tagging or query context propagation, so logs show the calling service, role, request ID, or agent ID.
- Centralised telemetry that correlates database logs with IAM, workload, and orchestration logs.
- Policy checks at request time, not only at provisioning time, so access is evaluated in context.
That model aligns with the identity-first direction described in the State of Non-Human Identity Security and with the OWASP guidance that NHI controls must reduce both over-privilege and attribution ambiguity. It also matches the operational direction in NIST AI Risk Management Framework and the CSA MAESTRO approach to runtime governance, where identity and authorisation are evaluated continuously rather than assumed from a standing account. These controls tend to break down when legacy apps pool connections through a single shared database account, because the database can only attribute the pool, not the true executor behind each query.
Common Variations and Edge Cases
Tighter attribution often increases engineering and operational overhead, requiring organisations to balance forensic clarity against connection management, application refactoring, and logging cost. That tradeoff is real, especially where high-throughput systems reuse sessions or where vendor products hide the underlying user context.
There is no universal standard for perfect database attribution yet. Some environments rely on application-level identity injection, while others use database-native session metadata, proxy layers, or workload identity federation. Best practice is evolving, but the test remains the same: if a query cannot be tied to a unique executor, the attribution control is incomplete. Shared read-only accounts, connection pools, and migration tools are common edge cases because they often compress many actors into one session. In those cases, teams should at minimum preserve a request ID, originating workload ID, and role assignment in a way that survives log aggregation and incident review. The Ultimate Guide to NHIs — Key Research and Survey Results is useful here because it shows how often organisations still lack the visibility needed to make that chain reliable. Where database proxies, ephemeral jobs, or multi-tenant automation flatten identity, attribution usually degrades at the exact point investigators need it most.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Covers weak NHI attribution and over-privileged shared access. |
| CSA MAESTRO | ID.AA | MAESTRO emphasizes runtime identity and access assurance for agents and workloads. |
| NIST AI RMF | GOVERN | AI RMF governance supports accountability and traceability for autonomous executors. |
Eliminate shared DB identities and require unique, traceable workload credentials for each executor.
