Reachability filtering

A method for shrinking the analysis surface to code paths that can actually be invoked from an external or attacker-controlled entry point. It helps teams avoid spending time on dead code and unreachable findings, which improves triage quality and makes downstream validation more meaningful.

Expanded Definition

Reachability filtering is the discipline of narrowing security analysis to code paths that can actually be invoked from an external or attacker-controlled entry point. In NHI and agentic AI security, that means separating theoretical findings from paths that are reachable through APIs, callbacks, tool invocations, message queues, or other real execution surfaces.

It is closely related to triage, attack-path analysis, and exploitability assessment, but it is not the same as static code scanning alone. A scanner may flag a weakness in a library or function that exists in the codebase, yet that weakness may never be reachable from any live identity, secret, or agent tool chain. Guidance varies across vendors on how aggressively to prune results, so teams should treat reachability as a validation step, not as proof of safety. NIST’s control model in NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it reinforces that control effectiveness depends on actual exposure, not just code presence.

The most common misapplication is treating every code finding as reachable, which occurs when teams skip entry-point analysis and apply the same severity to dead paths and live attack paths.

Examples and Use Cases

Implementing reachability filtering rigorously often introduces some analyst overhead, requiring organisations to weigh faster, higher-confidence triage against the cost of building and maintaining accurate call-chain context.

• A service account token is flagged in a dormant module, but the module is never invoked by the production API gateway, so the issue is de-prioritised until the path becomes reachable.
• An agent tool exposes file access, and only the subset of functions reachable through the model’s tool-calling workflow are reviewed for prompt-injection escalation.
• A dependency vulnerability appears in a package used by test code only, so reachability filtering prevents it from polluting the production backlog.
• A callback handler is reachable only after a specific webhook signature is validated, so the analysis focuses on that authenticated entry path rather than the entire repository.

For broader NHI context, the Ultimate Guide to NHIs shows why visibility into live identities matters before any reachability claim is trustworthy. In adjacent security practice, teams often align this filtering with external guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls when deciding which findings require immediate validation.

Why It Matters in NHI Security

Reachability filtering reduces false urgency, but its real value in NHI security is that it reveals which weaknesses can actually be exercised through service accounts, API keys, automation jobs, and agent tool permissions. Without it, teams waste time chasing unreachable code while missing the paths that connect a live NHI to a sensitive action.

This matters because NHIs are often overprivileged and poorly understood. NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, which means the reachable subset of a finding can be far more important than the existence of the finding itself. The same guide also notes that only 5.7% of organisations have full visibility into their service accounts, making accurate reachability analysis difficult unless identity inventory is already strong. The Ultimate Guide to NHIs is a useful reference point for that visibility gap, especially when paired with control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls.

Organisations typically encounter the operational cost of poor reachability analysis only after an incident review shows that an ignored finding was actually on a live path, at which point reachability filtering becomes unavoidable to address.

Related resources from NHI Mgmt Group

• What is the difference between prompt filtering and identity governance for AI agents?
• What do security teams get wrong about prompt filtering for AI agents?
• What is the difference between prompt signing and prompt filtering?
• What is the difference between policy evaluation and vector filtering in RAG?