Accountability sits with the team that defined the trust boundary too broadly. If the platform authorises a sidecar while assuming it proves process identity, the governance model is incomplete. Frameworks such as NIST Cybersecurity Framework 2.0 and NIST SP 800-207 both expect clearer trust boundaries than that.
Why This Matters for Security Teams
When a valid mTLS session is abused by the wrong process, the certificate alone has proven transport trust, not process trust. That distinction matters because many platforms treat the sidecar, proxy, or workload wrapper as if it were the workload itself. NIST Cybersecurity Framework 2.0 makes this governance problem explicit by requiring clearer identity, access, and asset boundaries than many service meshes actually enforce.
This is not a theoretical gap. NHI Management Group’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs shows that only 5.7% of organisations have full visibility into their service accounts, which means accountability often breaks down before anyone can prove which process actually used the session. In practice, the team that defined the trust boundary too broadly is usually the one that must answer for the abuse, even if the abuse surfaced as a valid protocol exchange.
Security teams get this wrong when they assume authenticated transport is equivalent to authorised execution. A valid mTLS handshake can still be replayed, proxied, or inherited by a process that was never intended to hold that privilege. In practice, many security teams encounter this after lateral movement or privilege abuse has already occurred, rather than through intentional boundary testing.
How It Works in Practice
The practical fix is to separate workload identity from process execution and then evaluate authorisation at request time. mTLS should prove the workload or service identity, while the platform must still verify which process, container, pod, or agent is acting, what it is trying to do, and whether that action fits current policy. Zero Trust guidance from NIST Cybersecurity Framework 2.0 and NIST SP 800-207 both align with this idea: trust is not inherited simply because a session is valid.
For NHI and service-to-service environments, current best practice is to combine cryptographic workload identity with short-lived credentials and policy-as-code. That usually means:
- Issuing ephemeral certificates or tokens per workload instance rather than relying on long-lived shared secrets.
- Binding identity to the workload using SPIFFE/SPIRE or equivalent workload identity primitives, so the platform knows what the workload is, not just what secret it presents.
- Evaluating requests against runtime context such as destination, time, requested action, and risk level.
- Logging the decision path so incident responders can attribute abuse to the owning control plane, deployment, or process boundary.
This is where the Guide to SPIFFE and SPIRE becomes relevant: workload identity can reduce ambiguity when certificates are issued to the unit of execution rather than to a vague service label. It also supports stronger accountability, because the platform can tell whether the abuse came from the intended process, a sibling process, or an unintended execution path. These controls tend to break down when sidecars, shared nodes, or legacy service meshes collapse multiple processes into a single identity boundary because the policy engine can no longer distinguish legitimate execution from inherited trust.
Common Variations and Edge Cases
Tighter identity binding often increases operational overhead, requiring organisations to balance stronger accountability against deployment complexity. That tradeoff is especially visible in Kubernetes, shared hosts, and legacy service-mesh designs where process isolation is imperfect and trust is often inherited from the node or pod rather than the exact executable.
There is no universal standard for attributing abuse inside a valid mTLS session yet. Some environments can bind identity to a workload instance cleanly, while others only get to container-level or node-level assurance. In those cases, the accountable party may be the platform team, the application owner, or the mesh operator depending on who approved the boundary and who failed to enforce process isolation. That is why the lifecycle view in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs matters: offboarding, rotation, and visibility are part of accountability, not just hygiene.
Where teams rely on shared certificates, broad service accounts, or “trusted” internal networks, the answer becomes less about who clicked the request and more about who accepted a model that could not distinguish a process from a proxy. That is why current guidance suggests treating valid mTLS as necessary evidence, not sufficient proof, of authorised action.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI 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 Agentic AI Top 10 | A01 | Broad trust boundaries let the wrong process use a valid session. |
| CSA MAESTRO | ID-2 | MAESTRO stresses workload identity and runtime control for agentic systems. |
| NIST AI RMF | AI RMF governance applies when autonomous workloads act through shared sessions. |
Assign ownership for identity, policy, and incident response across the full AI workflow.
