What breaks when reachability triage depends on AI alone?

Why AI-only reachability analysis fails

Reachability triage is not just text interpretation, it is a program-analysis problem. A model that reads source as plain language has no reliable way to resolve symbols, infer types with certainty, or follow cross-file call edges the way deterministic tooling can. The result is unnecessary recomputation, inconsistent verdicts, and a tempting confidence level that may not match the underlying code.

The practical failure mode is subtle: the model may sound precise while missing a call path hidden behind indirection, imports, interfaces, or generated code. That is why source-aware analysis should start with the compiler or semantic index, then let AI explain ambiguous cases rather than invent the graph from scratch.

One useful way to think about this is that AI can summarize reachability evidence, but it should not be the evidence engine. For a reliable workflow, semantic tooling establishes what is actually callable, and AI adds judgment only where the code leaves genuine uncertainty.

What goes wrong in the analysis pipeline

The main operational problem is repeated re-derivation. If every query forces the model to rediscover basic relationships, triage becomes slower and more expensive as the codebase grows. It also makes results harder to reproduce, because a small prompt change can shift the model’s inferred call path even when the code has not changed.

There is also a correctness problem. Reachability triage often feeds decisions about review priority, exploitability, or remediation sequencing. If the path is guessed incorrectly, teams can waste time on non-issues or miss the cases that actually deserve attention. Deterministic semantic analysis reduces that variance by anchoring the verdict in symbol binding, type resolution, and known call edges.

That division of labour matters especially in mixed-language or framework-heavy systems, where the visible source text is only part of the execution story. When the call graph is partially implicit, AI can help interpret the edge cases, but only after the graph has been grounded in analysis that is repeatable and inspectable.

How to structure a safer reachability workflow

The safest pattern is to treat AI as the layer that explains, not the layer that decides. Let static analysis, build metadata, or language-aware tooling establish candidate reachability first, then ask AI to summarise ambiguity, highlight likely false positives, or explain why a path may be gated by configuration or runtime conditions.

For teams implementing this pattern, the important distinction is between unresolved ambiguity and unresolved analysis. Ambiguity belongs to the code, but missing symbol resolution belongs to the toolchain. If the pipeline cannot resolve the latter, the answer should be “insufficiently grounded,” not a confident triage verdict.

When the codebase is highly dynamic, the right response is usually not to abandon deterministic analysis, but to narrow the scope of what AI is allowed to infer. Keep the AI role bounded to explanation, prioritisation, and exception handling, while the call graph and reachability facts remain machine-derived and reviewable.

Risk and Threat Considerations

AI-only triage creates avoidable security and operational risk because false reachability judgments can suppress real findings or flood teams with noise. In practice, that weakens trust in the triage pipeline and can distort downstream remediation priorities, especially when the output is used to decide what code gets reviewed first.

Failure mechanism: The model infers access paths from surface text instead of grounded program structure, so it may miss indirection, overloads, interfaces, or cross-file bindings and then repeat that mistake query after query.

Impact: Teams may accept a false negative as authoritative, or spend cycles chasing false positives, which increases cost, delays fixes, and makes the triage process less defensible.

Practitioner Guidance

What to prioritise: Establish a deterministic semantic layer first, then let AI consume the resulting graph or index. If the tooling cannot produce a stable call graph for a language or framework, treat that as an analysis coverage gap rather than as a prompt-engineering problem.

What to verify: Check whether the triage output can be reproduced from the same code revision, build context, and analysis engine. A good workflow should produce the same reachability answer without depending on prompt wording or model confidence.

Common mistake: Using AI to “save time” by skipping symbol resolution, then assuming the output is still a trustworthy reachability verdict. That shortcut usually shifts cost from analysis time to remediation time, where mistakes are more expensive.

Practitioner takeaway: Use AI to interpret uncertain code paths, not to manufacture them, because reachability is only reliable when the graph is grounded before the model weighs in.

Related resources from NHI Mgmt Group

• What breaks when AI governance depends on email or OAuth discovery alone?
• What breaks when AI transparency depends on explainability alone?
• What breaks when SCA triage relies on reachability alone?
• What breaks when vulnerability triage still depends on manual review in AI-speed environments?