Graph navigation for coding agents reduces tool-call storms

At a glance

What this is: Sonar describes a graph navigation engine for coding agents that maps code structure, reduces grep and read storms, and can lower token consumption by up to 36% on refactoring tasks.

Why it matters: For IAM and NHI teams, the key issue is not only cost but control over agent behaviour, because tool-driven workflows can miss structural dependencies, persist excessive context, and create silent change risk in software delivery.

By the numbers:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Sonar's analysis of graph navigation for coding agents and token cost reduction

Context

Coding agents are most expensive when they have to discover structure by brute force, not when they are writing code. Grep, find, and repeated file reads inflate both turns and retained context, which is why tool-call storms create cost and increase the chance of missing an indirect dependency in a refactor.

This matters for agentic AI governance because the agent is acting as a non-human identity with delegated access to source code, build systems, and editing tools. Once that identity is allowed to reason and act through tool loops, the control problem becomes one of scope, observability, and whether the agent can enumerate all affected locations before it changes anything.

Sonar's article sits in that operational gap: it is not just about faster navigation, but about whether structural code understanding can reduce both waste and incomplete changes. That starting point is typical of modern coding-agent workflows, where discovery is often the hidden cost center.

Key questions

Q: How should security teams govern coding agents that already have access to production tools?

A: They should govern the agent as a delegated identity, not as a piece of software. That means scoping every token, browser session, and MCP connection to the task, requiring just-in-time grants for high-impact actions, and binding the agent's rights to the human principal's permissions. If the human cannot do the action, the agent should not inherit it.

Q: Why do coding agents create hidden change risk even when builds still pass?

A: Because many code changes depend on structural relationships that text search does not fully expose. An agent can miss an indirect call site, interface implementor, or shadowed symbol and still produce compilable code. That creates silent defects, so teams need controls that prove coverage of all affected locations, not just successful compilation.

Q: What do teams get wrong about grep-based code navigation for AI agents?

A: They assume faster search equals complete discovery. In reality, grep only matches text, so it often returns noisy hits or misses structurally related sites entirely. That forces the agent to read more files, retain more context, and still risk incomplete edits. The control problem is completeness, not search speed.

Q: How can engineering teams reduce token cost without weakening code-change quality?

A: Use structural navigation only when it replaces repetitive search and read loops, especially for refactors across shared abstractions. Require the agent to return exact file and line targets, keep resident context small, and measure whether the tool eliminates extra turns. If it only adds queries, the cost benefit disappears.

Technical breakdown

Why text search breaks in agentic code navigation

Text search only matches characters, so it cannot reliably answer structural questions such as which type implements an interface or which method is called indirectly. In coding-agent workflows, that matters because the agent must build its own map before it can edit safely. The cost penalty comes from repeated reads and from retaining every opened file in context, which compounds across the whole run. The failure mode is not search speed. It is that search cannot enumerate the complete set of edit sites when relationships are hidden in symbols, scopes, or inheritance rather than names.

Practical implication: agent workflows need structural navigation for refactors where completeness depends on relationships, not keyword matches.

How a code graph changes the agent workflow

A code graph turns modules, classes, methods, fields, and references into nodes and edges that can be queried directly. Instead of asking the model to infer every location from text, the engine returns exact file and line targets for the symbol or relationship in question. That reduces the number of turns and avoids loading unnecessary file contents into the resident context. The architectural shift is subtle but important: the agent is no longer reconstructing code topology from grep output, it is querying the topology itself. That is why graph-based navigation can be substitutive rather than additive.

Practical implication: use structural queries only when they replace text-search loops, not when they simply add another layer of tool use.

Why completeness is a correctness control, not only a cost control

In code changes, missed sites can be loud or silent. A rename may fail at compile time, but a behaviour change reached indirectly can still compile and ship with a defect. Exhaustive enumeration of every structurally related location is therefore a governance control as much as a productivity feature. It reduces the chance that an edit set is incomplete and protects against silent bugs that tests may not cover. For agentic development, this is the deeper value of semantic navigation: it improves both edit coverage and confidence in the final change set.

Practical implication: treat complete location enumeration as a required control for high-risk refactors and behaviour-changing edits.

Threat narrative

Attacker objective: The objective is not data theft but operational inefficiency and incomplete code modification that leaves defects in production software.

1. Entry begins when the coding agent starts from a natural-language task without explicit file or line targets, forcing it to discover the code path on its own.
2. Escalation happens through repeated grep and read cycles that expand the resident context, increase token burn, and widen the set of candidates the agent must evaluate.
3. Impact is incomplete refactoring or a silent bug when structurally related edit sites are missed, especially where the code still compiles after the change.

NHI Mgmt Group analysis

Semantic navigation is becoming a governance issue, not just a developer convenience. When a coding agent must build its own map of the codebase, the workflow behaves like a non-human identity with delegated access to repositories, build systems, and edit tools. That makes scope control and location completeness part of the control plane, not a side effect of productivity tooling. Practitioners should treat structural code awareness as part of agent governance.

Graph-based code discovery introduces a useful concept we can call structural edit completeness. This is the ability to enumerate every affected symbol, reference, and edit target before the change begins. In agentic coding, that matters more than raw search speed because missed sites create silent defects that compile cleanly and evade tests. Teams should measure whether their agent can replace search-and-reconstruct loops with a complete edit set.

The real security value of semantic navigation is blast-radius reduction. A tool that returns exact line targets reduces unnecessary reads, shrinks resident context, and limits the chance that an agent drags irrelevant code into the decision loop. That aligns with least-privilege thinking for AI systems: give the agent only the information needed to act, not a growing shadow context. Practitioners should see code graphing as an access minimisation control for agentic workflows.

This pattern reinforces a broader NHI lesson: the identity of the agent is only half the problem. The other half is what the agent can observe, retain, and modify while it operates. In agentic AI security, that means governance must cover tool scope, context scope, and change scope together. Practitioners should evaluate whether their coding agents are governed as identities with bounded operational reach.

Vendor-specific acceleration claims are less important than the workflow category they expose. The article shows that structural questions outperform text search when code relationships, not syntax, define the work. That is a category-level signal for IDE and automation teams: any agent that edits code at scale needs a way to reason over dependencies before it starts changing files. Practitioners should prioritise tooling that proves edit coverage, not just faster retrieval.

What this signals

Structural navigation reduces one class of agentic risk, but it also widens adoption pressure by making coding agents cheaper to run. That means governance teams should expect more agentic activity inside delivery pipelines, not less, and should prepare controls for tool scope, auditability, and write authority before usage normalises.

Structural edit completeness: this is the control concept teams should watch closely as coding agents mature. If an agent cannot enumerate every affected location before it edits, it will eventually ship an incomplete change, even when the model is competent and the build passes. Teams should treat this as a measurable assurance gap, not a usability feature.

The broader signal is that agentic workflows are moving from retrieval efficiency to decision quality. That shift aligns with NIST AI Risk Management Framework thinking, because the question is no longer just whether the model can help, but whether the surrounding controls constrain what it can observe, retain, and change. Teams should evaluate coding agents with that governance lens.

For practitioners

• Map agent permissions to code-change scope Define which repositories, branches, and file classes a coding agent may inspect and modify, then separate read-only discovery from write-capable actions so structural queries do not become open-ended access.
• Require complete edit-set enumeration before write actions For refactors that touch shared abstractions, require the agent to return all affected symbols and line targets before it is allowed to edit, so discovery is substituted rather than layered on top of search.
• Track tool-call storms as an operational risk signal Monitor the number of grep, read, and re-read turns per task, because repeated search loops usually indicate the agent is reconstructing relationships manually instead of using a structural map.
• Bind coding-agent context to the minimum necessary state Limit how long file contents remain resident in the agent conversation and reset context where possible, so unnecessary reads do not keep compounding cost and decision noise across later turns.

Key takeaways

• Semantic code navigation matters because agentic coding fails when structural dependencies are hidden from text search.
• The practical gain is twofold: lower token use on refactor-heavy tasks and a smaller chance of shipping incomplete changes.
• Coding agents now need governance over scope, context, and edit coverage, not just faster tool access.

Key terms

• Structural Edit Completeness: The ability of an agent to enumerate every code location affected by a change before it begins editing. It matters because indirect references, shared abstractions, and symbol relationships can create missed sites that compile cleanly but still break behaviour at runtime.
• Tool-Call Storm: A repeated sequence of search, read, and inference turns that an agent uses to reconstruct code relationships manually. It increases token consumption, inflates resident context, and often signals that the agent lacks a structural view of the codebase.
• Resident Context Floor: The amount of file content an agent carries forward on each turn after opening code during a task. As that floor rises, every later decision becomes more expensive and more cluttered, which is why unnecessary reads compound cost across the run.
• Semantic Code Navigation: A code discovery method that returns relationships between symbols, files, and references rather than matching text strings. It helps agents ask structural questions directly, which improves completeness when the edit set depends on code topology instead of visible names.

What's in the full report

Sonar's full article covers the operational detail this post intentionally leaves for the source:

• The measurement methodology behind the 36% cost reduction, including how baseline and navigation runs were compared.
• The task-by-task breakdown of where graph navigation helped and where it stayed within a few percent of baseline.
• The implementation path through SonarQube CLI and SonarQube MCP Server for teams that want to test the workflow.
• The specific cases where navigation was not the bottleneck and the engine added little value.

👉 Sonar's full article covers the benchmark setup, refactoring cases, and the conditions where navigation does not help.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, IAM, and secrets management. It helps practitioners build the governance model that multi-tool agent workflows now require.