Who is accountable when proxy infrastructure is used to conceal malicious access?

Why This Matters for Security Teams

Proxy infrastructure changes the accountability question because it can separate the visible source of a session from the real actor behind it. That creates gaps in attribution, incident response, and control ownership, especially when credentials, API keys, or service tokens are reused across environments. Security teams need to treat concealment through proxies as a governance problem, not only a network problem.

The practical issue is that proxy use can be legitimate, but the same pattern is often abused to blend malicious access into normal traffic. That means investigators must understand who owns the service path, who owns the secrets that authenticated the session, and who is responsible for log review and anomaly detection. NIST guidance on logging, access control, and audit accountability in NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it links technical telemetry to control ownership.

For NHI-heavy environments, this is especially important when a proxy fronts machine identities, automation accounts, or agentic workflows. If those identities can reach production systems, accountability must extend beyond the application owner to the teams managing secret issuance, rotation, and monitoring. In practice, many security teams encounter the failure only after a proxy-enriched intrusion has already bypassed normal attribution and delayed containment.

How It Works in Practice

Attribution in proxy-backed access usually requires reconstruction across layers: the proxy endpoint, the authentication event, the downstream resource, and any identity or secret used to obtain access. That is why the accountable party is rarely just the last system touched. The organisation operating the exposed service must own secure configuration, the team issuing credentials must own lifecycle controls, and the monitoring function must own detection and escalation when source context is obscured.

A workable model assigns responsibility along the access chain:

• The service owner ensures the proxy is necessary, approved, and logged.
• The identity or platform team governs secret issuance, rotation, and revocation.
• The security operations team detects unusual source patterns, impossible travel, or repeated access via anonymising infrastructure.
• The incident response lead decides when concealed access becomes a reportable event and preserves evidence.

This is where identity discipline matters. If the proxy is being used by a human user, service account, or Non-Human Identity, the control objective is the same: prove who or what is authorised, and whether the session aligned with that authorisation. The OWASP Non-Human Identity Top 10 is relevant because hidden or over-permissive machine identities often make proxy-based abuse harder to notice. MITRE ATT&CK also helps analysts map proxy use to known behaviours such as valid account abuse, remote services, and defence evasion, which improves triage and detection logic.

In operational terms, teams should require strong authentication, short-lived access where possible, immutable audit logs, and explicit ownership for every credential that can reach an externally exposed path. Those controls need to be validated against actual traffic patterns, not only policy documents. These controls tend to break down when shared service accounts are routed through third-party proxies because ownership, logging, and revocation become fragmented across multiple administrators.

Common Variations and Edge Cases

Tighter attribution controls often increase operational overhead, requiring organisations to balance investigative clarity against service performance, privacy, and supplier complexity. That tradeoff becomes sharper when proxies are used for privacy-preserving routing, global delivery, or regulated third-party integrations.

There is no universal standard for this yet, but current guidance suggests accountability should follow control, not just technical origin. If a managed proxy, CDN, or identity broker obscures the source, the accountable party is still the organisation that chose the architecture and the teams that accepted the residual risk. Where a supplier is involved, contracts should define logging retention, incident cooperation, and evidence preservation, because otherwise attribution gaps are predictable.

Edge cases often appear in agentic AI and NHI scenarios. An AI agent may call tools through a proxy while a human operator assumes the platform will preserve provenance. That assumption is unsafe unless session binding, tool authorization, and secret ownership are explicit. Best practice is evolving here, especially for multi-tenant agent platforms and delegated access models, so teams should document who approves the proxy, who can rotate the secret, and who investigates abuse.

For high-value environments, proxy use should be reviewed alongside zero trust and privileged access governance, because concealed access frequently overlaps with standing privilege, stale credentials, and weak session observability. Where those conditions coexist, accountability becomes ambiguous unless ownership is mapped before an incident, not during one.

Related resources from NHI Mgmt Group

• Who is accountable when compromised credentials are used to access personal or infrastructure accounts?
• Who is accountable when a lost authenticator is used to regain access?
• Who is accountable when privileged management access is used to disrupt endpoints?
• Who is accountable when a phished identity is used to access downstream systems?