They usually rely on exact-match tools such as grep, glob, and find, then iterate through many files to build a working model of the codebase. As repositories expand, that guessing loop increases tool calls, token usage, and runtime. Semantic retrieval helps because it returns likely relevant functions, types, and modules by meaning, not filename alone.
Why This Matters for Security Teams
AI coding agents do not scale like normal developer tools. As repositories grow, the agent has to search more files, read more context, and retry more often before it can act confidently. That raises runtime and token spend, but it also raises security risk because the same broad access that helps the agent “find” code can expose secrets, test data, or deployment logic. NHIMG has documented how quickly AI-linked credentials are abused once exposed, including the LLMjacking: How Attackers Hijack AI Using Compromised NHIs research and the State of Secrets in AppSec findings on secrets hygiene.
The core mistake is treating coding agents like a faster junior engineer instead of a goal-driven workload that must discover its own working set at runtime. That behavior makes cost unpredictable and makes access review harder, because the agent’s path through the codebase is not fixed in advance. Current guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 points toward runtime controls, not static assumptions. In practice, many security teams encounter the cost problem only after the agent has already scanned too much code, not through intentional workload design.
How It Works in Practice
Most AI coding agents start with low-precision discovery: grep, glob, find, symbol search, file walking, and repeated prompt iterations. On a small repository, that is tolerable. On a large monorepo, the agent may need several passes to identify the right module, then another round to inspect dependencies, then another to validate the change. Each pass adds tool calls, more tokens, and more latency. Semantic retrieval reduces that loop by returning likely relevant functions, types, and modules based on meaning, which narrows the search space before the model starts reasoning.
The practical pattern is to combine retrieval with tighter workspace boundaries and explicit task decomposition. For example, an agent can be pointed at a service slice, a package graph, or an indexed symbol layer rather than the entire repository. That improves both cost and control. Security teams should also treat the agent’s identity and permissions as workload identity, not a long-lived human account. The lessons from Analysis of Claude Code Security and OWASP NHI Top 10 are consistent: broad, persistent access makes autonomous tools expensive to govern.
- Index code semantically so retrieval can cut down blind file traversal.
- Scope each task to a package, service, or branch instead of the full repo.
- Issue short-lived credentials and revoke them when the task ends.
- Log tool calls separately from model output so cost spikes and risky access are visible.
These controls tend to break down in monorepos with weak module boundaries because the agent still needs cross-package context to make safe changes.
Common Variations and Edge Cases
Tighter retrieval often increases setup cost, requiring organisations to balance faster agent execution against the overhead of building and maintaining indexes, dependency maps, and policy gates. There is no universal standard for this yet, so best practice is evolving rather than settled.
Highly coupled codebases are the hardest case. If the agent must touch shared libraries, generated code, and deployment manifests in one task, semantic search alone will not stop the context explosion. In those environments, runtime policy evaluation matters as much as retrieval quality. The CSA MAESTRO agentic AI threat modeling framework and MITRE ATLAS adversarial AI threat matrix both support the view that agent behavior should be constrained at execution time, not just by repository size. That is especially true when the agent can chain tools, follow references across services, or inspect secrets-heavy files such as CI pipelines and IaC templates.
Another edge case is when teams over-index on token reduction and forget correctness. A smaller context window can lower spend, but it can also hide the dependency or config change that makes the fix valid. For that reason, the better target is not minimum context, but minimum necessary context. In fast-moving production codebases, that balance is usually the only way to keep coding agents both useful and economically sustainable.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agentic tools need bounded context and safe tool use as repos grow. |
| CSA MAESTRO | M1 | MAESTRO addresses runtime agent control and threat-informed design. |
| NIST AI RMF | GOVERN | AI RMF governs accountable, risk-based deployment of autonomous coding agents. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Short-lived workload credentials reduce the blast radius of agent access. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege is central when agents traverse large and sensitive codebases. |
Model agent workflows and add execution-time controls around code access and tool chaining.
Related resources from NHI Mgmt Group
- What do teams get wrong about AI coding agents generating access-related code?
- What do security teams get wrong about using general-purpose AI coding agents for vulnerability remediation?
- Why do AI coding agents increase supply-chain risk?
- What do teams get wrong when building clarification loops for AI agents?
