A logging approach that captures queries and access events outside the database engine. It reduces load on PostgreSQL itself and is often easier to keep running at scale, but it may not preserve every native event detail that in-server auditing can capture.
Expanded Definition
Proxy logging is the collection of query and access telemetry by an intermediary layer rather than by the database engine itself. In NHI operations, that intermediary may be a gateway, sidecar, API proxy, or connection broker that records who connected, what was requested, and when the request occurred. The practical appeal is operational: the database stays lighter, logging is often easier to centralise, and telemetry can be standardised across many services. The tradeoff is fidelity. Because the proxy does not observe every native event inside PostgreSQL, it may miss execution details, session state, or server-side context that in-engine auditing would retain.
Definitions vary across vendors on how much request content a proxy should record and how long it should retain it, so governance teams should treat proxy logging as an observability control, not a complete forensic substitute. For a broader NHI governance context, see the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0 for logging and monitoring expectations.
The most common misapplication is treating proxy logs as a full audit trail, which occurs when teams assume the proxy can reconstruct every database action without validating what the database engine itself records.
Examples and Use Cases
Implementing proxy logging rigorously often introduces an observability-versus-fidelity tradeoff, requiring organisations to weigh lower database overhead against the possibility of losing native event detail needed for incident investigation.
- A platform team routes PostgreSQL traffic through a proxy that records application identity, source network, and query timing for centralised monitoring.
- A security team uses proxy logs to detect unusual service account access patterns across multiple clusters, then correlates those events with Ultimate Guide to NHIs guidance on service-account visibility and lifecycle control.
- An SRE group keeps lightweight proxy logging enabled in production because full in-server auditing would create too much performance overhead during peak traffic.
- A compliance team pairs proxy logging with native database audit settings so that the proxy captures broad access telemetry while the engine preserves high-value action details.
- An incident responder reviews proxy logs first to identify which NHI credential touched a database, then uses internal database auditing to confirm the exact statement path and scope, aligning with the logging and monitoring intent reflected in the NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Proxy logging matters because NHI incidents rarely begin with obvious human actions. Compromised service accounts, API keys, and automation tokens often generate database activity that looks legitimate unless telemetry is rich enough to show source, timing, and unusual access patterns. NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why visibility into database access paths is so important. The same body of research also notes that only 5.7% of organisations have full visibility into their service accounts, making logging coverage a governance issue, not just an operations preference.
Proxy logging can support detection, containment, and forensic triage when it is paired with identity-aware controls, rotation discipline, and access review. It is especially useful when organisations need broad coverage without overwhelming database performance, but it must be matched with retention, integrity, and correlation requirements. The Ultimate Guide to NHIs is a useful reference point for understanding why telemetry gaps become security gaps in distributed automation environments.
Organisations typically encounter the limits of proxy logging only after a suspicious query cannot be fully explained, at which point the missing native detail becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 | Logging gaps and auditability are core NHI visibility concerns. |
| NIST CSF 2.0 | DE.CM-1 | Continuous monitoring depends on collecting usable access telemetry. |
| NIST Zero Trust (SP 800-207) | PR.AC-7 | Zero Trust requires ongoing validation and monitoring of access activity. |
Log NHI database access centrally and verify the proxy still preserves enough detail for investigations.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
