Proxy identity proves the component that negotiated the connection, while process identity proves the workload that actually executed the request. Zero trust needs both if co-located code can access the proxy path. Without process identity, the network layer can be secure and still misattribute the actor.
How Proxy Identity and Process Identity Split the Trust Problem
Proxy identity answers a narrow question: which intermediary component terminated, forwarded, or negotiated the connection. Process identity answers a stronger one: which running workload actually executed the action behind that connection. In zero trust, those are not interchangeable, because the transport path can be secured by one component while the actual requester is a different process inside the same host, pod, or container.
That distinction matters most when shared runtime environments allow code to reach the proxy path without being the trusted application. If you only validate the proxy, you may know the connection came through an approved control point, but you still do not know which local process originated the request or whether multiple workloads share the same network boundary.
Why Zero Trust Often Needs Both Signals
Zero trust is built on continuous verification, least privilege, and explicit trust decisions at each request. NIST SP 800-207 Zero Trust Architecture is useful here because it frames trust around the actual request context, not just the network path. Proxy identity can support policy enforcement at the edge of the connection, while process identity helps confirm the workload that should receive the privilege.
In practice, process identity becomes the missing control when co-located code can reuse the same proxy, sidecar, socket, or node-level route. The network layer may look compliant, yet the actor behind the request may be a different binary, container, or service instance. That is why mature zero trust designs treat proxy identity as a routing and enforcement signal, not as proof of the originating workload.
When the Difference Becomes Operationally Important
The gap shows up whenever trust decisions depend on local execution context. In service meshes, sidecars, and shared hosts, the proxy may be the entity that established the session, but the security question is often whether the calling process is allowed to act on behalf of the workload. Guide to SPIFFE and SPIRE is a relevant reference point because workload identity systems are designed to bind identity to the workload itself, not just to the network mediation layer.
That same issue affects auditability. If logs only capture the proxy, incident responders may be left with a trustworthy transport record but an ambiguous actor record. For policy, that means authorization decisions should be made on the strongest identity available at the decision point, and not inferred from the component that happened to carry the traffic.
Risk and Threat Considerations
Proxy-only trust creates a misattribution risk: defenders can secure the path and still allow an untrusted local process to use it. In shared execution environments, that can collapse separation between the intended workload and adjacent code that can reach the same proxy or socket.
Failure mechanism: A proxy, sidecar, or gateway authenticates the connection, but the platform does not bind the request to the executing process. An attacker who gains code execution on the same node or in the same container boundary can ride the approved network path and inherit the proxy’s apparent legitimacy.
Impact: Authorization decisions, logs, and alerts may attribute activity to the wrong component, which weakens containment, complicates forensics, and can let privilege or access bleed between workloads that should be separated.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Covers service/workload identity binding beyond a proxy hop. |
| AC-6 — Least Privilege | Zero trust requires limiting what the actual workload may do after authentication. | |
| Recommendation — Bind access decisions to service identity, not only to the proxy or network path. Limit each workload to the minimum actions allowed by its verified identity. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Explains request-level trust decisions and continuous verification. |
| Recommendation — Base enforcement on verified request context, not on a trusted network location. | ||
| OWASP Non-Human Identity Top 10 | NHI-10 — Human Use of NHI | Shared paths can let the wrong actor use a trusted non-human path. |
| Recommendation — Separate human and workload usage paths so one actor cannot impersonate another through a shared control. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud IAM must distinguish the authenticating component from the executing workload. |
| Recommendation — Map cloud access controls to the identity that actually executes the request. | ||
Practitioner Guidance
What to verify: Treat proxy identity as necessary but incomplete. Verify whether the platform can bind each request to a process-, workload-, or workload-attestation signal before you trust it for authorization or audit.
Decision rule: If multiple workloads, containers, or binaries can reach the same proxy boundary, require process identity or workload identity for the final access decision. If the environment cannot provide that binding, treat the proxy as a control point, not as the actor of record.
Practitioner takeaway: The practical goal is to prevent “secure path, wrong actor” outcomes, because zero trust fails when the component that moved the request is mistaken for the component that actually performed it.
Related resources from NHI Mgmt Group
- What is the difference between zero trust for users and zero trust for NHIs?
- What is the difference between JIT access and Zero Trust for NHIs?
- What is the difference between code scanning and runtime identity monitoring?
- What is the difference between identity security and Zero Trust in healthcare?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org