What breaks when security teams cannot distinguish reachability from actual execution?

Why This Matters for Security Teams

Reachability and execution are not the same security signal, and confusing them turns prioritisation into guesswork. A component may be reachable in theory, yet never invoked in production; another may be executed repeatedly through a narrow runtime path that static analysis misses. For NHI and agentic workloads, that gap is especially dangerous because tool access, secrets usage, and downstream calls can be triggered only under specific context.

When teams treat reachability as proof of exposure, they flood remediation queues with dormant findings and bury the issues that are actually exploitable. NHI Mgmt Group has shown how often organisations struggle with exposure hygiene, including the Ultimate Guide to NHIs evidence that 96% of organisations store secrets outside secrets managers in vulnerable locations. That kind of sprawl makes it harder to tell what could run from what did run. For control validation, NIST guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful, but it still needs runtime evidence to be operationally meaningful.

In practice, many security teams discover the difference only after an incident has already proved which code paths actually executed.

How It Works in Practice

The practical fix is to split analysis into two questions: can this path be reached, and was it actually executed under production conditions? Reachability is typically established through code review, dependency graphs, call-chain analysis, or policy checks. Execution requires runtime telemetry from traces, logs, audit events, and workload identity signals that show the action really occurred.

For NHI-driven systems, this distinction matters even more because an agent or service account may have permission to call a tool, but only exercise that permission when a prompt, workflow state, or external event makes it necessary. Current guidance suggests using workload identity and short-lived credentials to correlate identity with action, rather than assuming a long-lived token implies active risk. That approach is consistent with the direction of The State of Non-Human Identity Security, which reports that only 1.5 out of 10 organisations are highly confident in securing NHIs. Runtime evidence helps explain why confidence stays low.

• Use reachability to triage theoretical exposure, not to assign final severity.
• Use execution evidence to confirm whether a vulnerable function, API, or tool was invoked.
• Link traces to workload identity so the team can see which NHI or agent executed the action.
• Prefer ephemeral secrets and JIT access so dormant paths do not retain long-lived value.
• Feed findings into policy-as-code and runtime controls, not only static scan reports.

That model is strongest when observability is mature and each request can be tied to a specific workload identity, because then teams can separate exposed code from actually abused code; these controls tend to break down in event-driven microservices with weak tracing and shared service accounts because execution evidence becomes ambiguous.

Common Variations and Edge Cases

Tighter execution-based prioritisation often reduces noise, but it also increases telemetry and correlation overhead, requiring organisations to balance better triage against monitoring cost and coverage gaps. Best practice is evolving here, because there is no universal standard for what level of runtime proof is sufficient.

Some environments make the distinction harder. Batch jobs may be reachable only during rare schedules, serverless functions may execute too briefly for traditional logs, and multi-agent systems may chain calls across several tools before a final action appears. In those cases, the issue is not just whether a function executed, but whether a broader workflow executed in a way that could change state or exfiltrate data.

Security teams should also be cautious about false confidence from partial telemetry. A static scanner may show a path as reachable, while a runtime monitor sees nothing because logging is missing, not because the code is safe. That is why Schneider Electric credentials breach-style lessons matter: exposure can persist even when teams believe controls are present, and the gap often sits in visibility rather than policy.

The operational takeaway is simple. Reachability helps teams decide where to look. Execution tells them where to act.

Related resources from NHI Mgmt Group

• What breaks when security teams cannot connect sensitive data exposure to actual access and activity?
• What breaks when organisations cannot see which users are actually active in a security platform?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?