Access by proxy is a governance pattern where one team approves access but another team or application actually maintains it. This creates drift between authorization and enforcement, which makes it harder to prove who has access, why they have it, and whether it should still exist.
Expanded Definition
Access by proxy describes a governance pattern in which one party approves or requests access while another identity, application, or team actually holds the entitlement and performs the action. In NHI environments, that split creates audit gaps because approval, enforcement, and evidence often live in different systems.
Definitions vary across vendors, but the operational risk is consistent: the identity that was reviewed is not always the identity that acts. That matters in service accounts, API keys, automation runners, and Agent workflows where ownership can be shared, inherited, or delegated. The issue is closely related to the broader NHI lifecycle described in the Ultimate Guide to NHIs, and it often shows up alongside poor secret handling and stale entitlements called out in the Ultimate Guide to NHIs — Key Challenges and Risks.
In governance terms, access by proxy is not the same as role delegation, PAM checkout, or RBAC assignment. Those models can be controlled and traceable when implemented correctly. Access by proxy becomes problematic when approvals are detached from the actual credential, token, or certificate that enters production. The most common misapplication is treating an approval ticket as proof of control, which occurs when the operating identity, not the reviewed identity, retains standing access.
Examples and Use Cases
Implementing access by proxy rigorously often introduces more coordination overhead, requiring organisations to weigh approval convenience against traceability and revocation discipline.
- A platform team approves a deployment service account, but a different CI/CD pipeline token executes the release. The approval exists, yet the real credential never passed review.
- An engineering manager authorises an Agent to read an internal API, while the Agent uses a shared backend identity that also has write privileges. The proxy masks the true blast radius.
- A contractor requests temporary access, but the entitlement is granted to a group-owned secret that persists after the contractor leaves. The proxy outlives the business need.
- A security reviewer signs off on a PAM workflow, while the downstream application caches a certificate and continues authenticating after the approved session expires. The control fails at the enforcement layer.
These patterns are easier to spot when teams compare approval records against actual identity activity, a discipline emphasized in OWASP Non-Human Identity Top 10 guidance. They also appear in breach analyses where access was technically “reviewed” but never actually constrained, as discussed in the 52 NHI Breaches Analysis.
Why It Matters in NHI Security
Access by proxy matters because NHI control failures rarely begin with a dramatic compromise. They begin with drift: an entitlement approved in one system, enforced in another, and forgotten in a third. That is especially dangerous where secrets are long lived, third-party exposure is common, or automation is allowed to act faster than humans can review. NHI Mgmt Group research shows that 97% of NHIs carry excessive privileges, which makes any proxy-based approval model more likely to preserve access that should have been removed.
This is why the problem is central to both Zero Trust and NHI governance. The OWASP Non-Human Identity Top 10 treats weak lifecycle controls and secret misuse as recurring failure modes, while the Ultimate Guide to NHIs shows why visibility, rotation, and offboarding must be tied to the identity that actually authenticates. Practitioners also need to align this pattern with Ultimate Guide to NHIs — Key Challenges and Risks because proxy arrangements often hide where remediation must happen.
Organisations typically encounter the damage only after an access review, incident, or audit exposes that the approved identity and the operating identity were never the same, at which point access by proxy 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 Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret and entitlement misuse that often hides behind proxy access patterns. |
| NIST Zero Trust (SP 800-207) | AC-6 | Least-privilege enforcement requires the acting identity, not just the approved one, to be controlled. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed and reviewed at the point of enforcement, not just approval. |
Reconcile approvals to live entitlements and revoke any proxy-based access that lacks current business need.
