As organizations deploy AI coding agents across large monorepos and microservices environments, a fundamental problem emerges: the model may be capable of making the change, yet still lack the organizational context required to make the right change safely.
A developer can ask an AI coding agent to deprecate an API field, update an authentication flow, or modify a service interface. The agent can inspect the code available on the developer's machine and search for references. What it may not know is that the field is consumed by four other services across separate repositories, that one of those services belongs to another team, or that the same field eventually carries sensitive data into a third party integration.
This is not simply a context window problem. It is a code context problem: providing AI agents with accurate, current, organization wide evidence about how software actually behaves.
One emerging approach is to generate that evidence directly from source code using deterministic static analysis, keep it continuously updated as development happens, and expose it to AI agents through the Model Context Protocol, or MCP.
The result is a context layer that can serve more than AI coding agents. The same evidence about services, APIs, callsites, fields, third party integrations, and sensitive dataflows can support privacy data mapping, AI governance, compliance, application security, and SOC investigations.
What if you could interact with that context directly?
Imagine being able to visually explore the services, APIs, dependencies, sensitive dataflows, and third party integrations across your organization, then query the same service graph using natural language. An engineer could ask which gRPC services depend on a particular API before changing it. A security or privacy team could ask which third party integrations receive PII. An AI governance team could ask which AI integrations exist and what sensitive data reaches them.
 |
| Interactive Service Graph and Dataflow Context for AI Agents |
For example, asking “Which third party integrations receive PII?” can query the underlying dataflow graph and surface the relevant integrations, sensitive data elements, repositories, code locations, and risk status.
 |
| Querying Sensitive Dataflows and Third Party Integrations With AI |
Anthropic's Guidance for AI Coding Agents in Large Codebases
Anthropic recently published guidance based on Claude Code deployments across multimillion line monorepos, legacy systems, distributed architectures spanning dozens of repositories, and organizations with thousands of developers.
One of its most important conclusions is that the harness matters as much as the model.
Anthropic identifies several components that help Claude Code operate effectively at enterprise scale, including CLAUDE.md files, hooks, skills, plugins, Language Server Protocol integrations, subagents, and MCP servers.
The reason becomes apparent when looking at how an AI coding agent navigates a large codebase.
Claude Code uses agentic search. It traverses directories, reads files, uses tools such as grep, and follows references to locate the code relevant to a task. This avoids some of the freshness problems associated with maintaining an embedding index, but Anthropic also points out an important tradeoff: agentic search works best when the agent already has enough context to know where to look. Searching for vague relationships across an enormous codebase can exhaust the available context before useful work begins.
Anthropic recommends several ways to reduce that search space. CLAUDE.md files can provide persistent knowledge about the codebase. Skills can load specialized knowledge only when needed. LSP integrations can give Claude symbol level precision instead of forcing it to search by strings.
MCP takes the idea one step further. Anthropic notes that sophisticated engineering organizations are building MCP servers that expose structured search directly to Claude, allowing the agent to query information that it cannot efficiently discover itself.
That raises another question:
What happens when the relationship the agent needs does not exist in a symbol, a file, an API specification, or even the repository on the developer's machine?
Why API Specifications Are Not Enough for AI Coding Agents
Consider a protobuf definition for an Address message:
message Address {
string street_address = 1;
string address_line_1 = 5;
string address_line_2 = 6;
string city = 2;
string state = 3;
string country = 4;
}Suppose an engineer asks an AI coding agent:
Deprecate street_address and migrate consumers to address_line_1.
The schema tells the agent exactly what Address looks like. It does not necessarily tell it every service that consumes street_address, every callsite where the field is referenced, which repositories contain those consumers, or which teams own them.
This distinction becomes especially important in microservices environments. API specifications such as protobuf, OpenAPI, and GraphQL are excellent descriptions of contracts. They do not inherently provide a continuously updated map of downstream consumers and field usage across an entire software estate.
In one test monorepo we use at HoundDog.ai, what appears to be a one line protobuf change affects four services, three teams, and two programming languages.
Without that context, the agent has to reconstruct the relationship itself. It searches repositories, follows imports, greps for references, generates temporary scripts, and reasons about which results actually represent downstream consumers.
Then another developer asks a similar question and the discovery happens again.
Generate AI Agent Context Directly From Code
An alternative is to separate discovery from reasoning.
At HoundDog.ai, we built a lightweight deterministic code scanner in Rust that analyzes source code and generates structured context about both software architecture and sensitive dataflows.
For application architecture, it can map relationships such as:
Service → API → method → field → consumer → callsite
For security and privacy, it can map:
Sensitive data → transformations → callsite → log, storage, API, third party, or AI integration
The scanner performs interprocedural dataflow analysis across functions and files, allowing it to follow data through deeply nested application paths rather than relying solely on nearby syntax or simple pattern matching.
Because the discovery layer is deterministic, the same commit produces the same underlying graph. AI is then applied selectively to the resulting traces to provide context, adjust severity, and eliminate false positives.
This creates a useful division of labor:
Static analysis discovers. AI reasons. MCP delivers.
Organizations can also use their preferred LLM provider and their own API key. The model does not need the complete source code to perform the reasoning step. It can reason over the dataflow traces already extracted by the scanner.
The scanner is lightweight enough to operate directly in development workflows. In our testing, it can analyze 10 million lines of code in under a minute on standard CPU infrastructure.
That makes it practical to continuously regenerate context rather than periodically rebuilding a service catalog or data map.
 |
| Deterministic Context Architecture |
Giving AI Coding Agents Context Across Large Codebases
Once these relationships are represented as structured data, they can be exposed through an MCP server.
An AI coding agent can now ask questions such as:
Which services consume Address.street_address?
Which repositories call this RPC?
Which fields from this API are actually used downstream?
What is the blast radius if I change this service contract?
Instead of spending part of its context window rediscovering the software estate, the agent receives a structured answer generated from the code itself.
The distinction becomes especially important when the organization's code cannot physically exist on one developer's machine.
A centralized context engine can analyze selected repositories through source control and CI integrations and expose the resulting cross repository context organization wide. The developer's coding agent therefore gains access to relevant relationships across the organization without needing every repository checked out locally.
The economic effect can be significant because discovery no longer has to occur for every developer, prompt, and change.
In one internal test using the same prompt and test monorepo, an agent without precomputed context spent 9 minutes and 57 seconds and approximately $1.75 reconstructing the relationships. When the same information was available through one structured context call, the task took 1 minute and 23 seconds and approximately $0.29.
This is an illustrative internal measurement rather than a universal benchmark, but it demonstrates the shape of the problem: repeatedly asking AI to rediscover deterministic relationships introduces both latency and recurring inference cost.
Replit Security Agent: Grounding AI With Static Analysis
There is already an important production example of this architectural pattern in security.
HoundDog.ai powers privacy code scanning for Replit, where our infrastructure currently runs approximately 100,000 scans per day across a platform serving more than 50 million creators.
Replit's Security Agent combines deterministic security tools with LLM based reasoning rather than relying on an LLM to discover every vulnerability from source code alone.
Replit's research into securing AI generated applications concluded that deterministic tools should establish the security baseline while LLMs provide contextual reasoning. Replit CEO summarized the results more directly, stating that combining current LLMs with deterministic tools such as static analysis produced “90%+ better outcomes.”
That distinction matters beyond vulnerability scanning.
Static analysis is very good at answering deterministic questions such as whether a sensitive value can reach a logging function or external API. An LLM is better suited to questions such as whether the behavior is appropriate given the application's purpose and what remediation makes sense.
The combination provides the agent with evidence before asking it to reason.
Using Static Code Analysis to Discover Shadow AI
The same approach becomes increasingly important as organizations adopt AI.
Security and governance teams face a deceptively simple question:
Where is AI actually being used across the organization?
An inventory based solely on procurement records, surveys, or known SaaS applications may miss AI introduced directly by developers.
A developer can add an AI SDK, framework, or API integration in a pull request. That integration may begin processing customer information without appearing in a central AI inventory or privacy data map.
Static code analysis provides another source of evidence.
HoundDog.ai currently recognizes more than 1,000 third party and AI integrations and traces more than 100 categories of sensitive data through application code into destinations including APIs, AI providers, logs, storage, and third party services.
Finding an SDK alone, however, is not enough.
The more useful question is:
What data actually reaches it?
For example, a scanner may detect that a medical history field is constructed into a patient context string, wrapped in a LangChain message, and ultimately sent to OpenAI.
That produces a much richer piece of evidence than simply reporting that the repository imports an AI library.
 |
| PHI Exposure in OpenAI |
The same analysis can identify whether credentials reach logs, whether health identifiers reach an external CRM, or whether personal information flows into an analytics or communications platform.
 |
| MRN Exposure in Salesforce |
From Shadow AI Discovery to ISO 42001 and Privacy Governance
Discovering AI integrations directly from code creates another opportunity: continuously grounding AI governance in technical evidence.
ISO/IEC 42001 establishes an AI management system for organizations developing or using AI and emphasizes governance, risk management, traceability, transparency, and continual improvement.
A practical prerequisite for those processes is understanding which AI systems are actually being used.
Code level evidence can help answer questions such as:
Which applications contain AI integrations?
Which providers and frameworks are involved?
What categories of sensitive data can reach them?
Are those providers approved?
Is an appropriate Data Processing Agreement in place?
Is the integration represented in the organization's AI inventory and privacy documentation?
This is particularly important for AI frameworks and SDKs introduced directly through engineering. Some may not have gone through the organization's normal vendor review or DPA process.
In one HoundDog.ai customer environment, roughly 30 percent of detected AI integrations were Shadow AI. Some, including self-hosted agent frameworks that never went through vendor review.
The same evidence can feed existing privacy processes.
Instead of asking engineering teams to repeatedly reconstruct dataflows through questionnaires, detected changes can become suggested updates to GDPR Records of Processing Activities, PIAs, and other privacy documentation. For US government environments, the same technical evidence can also support digital dataflow documentation associated with FedRAMP System Security and Privacy Plans.
 |
| Org RoPA with Automated Suggestions |
This does not make static analysis an ISO 42001 or GDPR compliance solution by itself. Governance still requires policies, human judgment, risk decisions, contractual review, and organizational controls.
It does, however, provide something those processes often struggle to maintain: fresh evidence of what the software actually does.
From AI Coding Agents to AI SOC and Security Agents
Once an organization has a continuously updated dataflow graph, AI coding agents are only one possible consumer.
Replit Security Agent provides an early production example. Static findings become evidence an LLM can reason over.
The same pattern could apply to emerging SOC agents.
A data security investigation agent responding to PII discovered in application logs could query the context layer to determine which code path introduced the data, which field originated it, which repository contains the logging call, and where remediation needs to occur.
A threat hunting agent investigating a compromised third party integration could ask which applications use that SDK or API and which categories of sensitive data can potentially reach it.
An AI governance agent could ask which repositories introduced new AI SDKs during the last month, which sensitive data reaches them, and which integrations are missing from the approved AI inventory.
An application security agent could combine deterministic dataflow findings with business context to distinguish an exploitable issue from technically suspicious but legitimate behavior.
The common architecture is the same:
Deterministic evidence first. Agentic reasoning second.
 |
| One Evidence Layer, Multiple AI Agents |
Keeping AI Agent Context Fresh as Code Changes
Creating a service catalog or data map once is relatively easy.
Keeping it accurate is much harder.
Large engineering organizations merge code continuously. Services appear and disappear. APIs evolve. Fields gain new consumers. Developers add SDKs. Data begins flowing to new destinations.
A manually maintained catalog begins drifting as soon as the next pull request merges.
This is why the dataflow graph needs to be generated as part of development rather than maintained as a separate documentation exercise.
In HoundDog.ai's centralized deployment model, the scanner integrates with source control and CI workflows. The relevant context is regenerated as code changes and the catalog exposed to agents is updated accordingly.
The goal is not better documentation.
It is evidence that regenerates itself as the code changes.
That evidence can then serve humans and agents through the same underlying source of truth.
Why Not Just Build Another AI Agent?
In theory, an organization can build an AI agent to discover all of this itself.
Give it access to every repository. Ask it to search for services, reconstruct API relationships, discover SDKs, identify sensitive data, and maintain the resulting graph.
For smaller environments, that may be perfectly reasonable.
At enterprise scale, however, the economics become different.
If hundreds or thousands of developers repeatedly ask agents to reconstruct relationships across millions of lines of code and hundreds of repositories, the organization repeatedly pays for the same discovery in inference cost, latency, context consumption, and compute.
Building a centralized discovery agent moves the problem rather than eliminating it. The organization now owns another agent that must understand every supported language, framework, API protocol, repository structure, and evolving code pattern while keeping its conclusions current and consistent.
There is a simpler architectural principle:
Compute deterministic relationships once, refresh them continuously in CI, and let authorized agents query the resulting evidence.
Use AI where reasoning is valuable.
Avoid paying AI to repeatedly rediscover facts that can be deterministically extracted from code.
The Missing Context Layer for Enterprise AI
The next phase of enterprise AI adoption will not be defined only by better models or larger context windows.
It will also depend on the infrastructure surrounding those models.
Anthropic calls attention to the importance of the harness. MCP servers provide a standardized mechanism for connecting agents to information they cannot efficiently discover themselves. Structured context can make that mechanism substantially more useful.
For software organizations, one particularly valuable representation looks like:
Code → Services → APIs → Fields → Consumers → Sensitive Dataflows → Third Party and AI Integrations
AI coding agents can use that evidence to understand the blast radius of an API change.
Application security agents can use it to reason over deterministic findings.
SOC agents can use it to investigate the application behavior behind an alert.
Privacy agents can use it to understand processing activities and subprocessors.
AI governance agents can use it to discover Shadow AI and maintain an accurate picture of how AI is actually being used.
The underlying principle is simple: do not ask an AI agent to infer organizational context from scratch every time it needs it.
Generate the evidence from the code, keep it current at the speed of development, and make it available to every authorized agent that can benefit from it.
About the Author: Ankita Gupta is the Co-Founder and CEO of Akto, the Agentic AI Security platform for securing AI agents across the enterprise. She brings 15+ years across cybersecurity, engineering, enterprise software, and go-to-market leadership, with prior roles at VMware, LinkedIn, and JPMorgan Chase. Ankita is a leading voice in modern application and AI security, recognized across industry communities including Black Hat USA, DEF CON, RSA Conference, OWASP, and GraphQLConf. She serves on the CSA AI Safety Council and is a member of the Forbes Technology Council. Her AI Security newsletter reaches more than 5,000 subscribers, and her work is followed by a security community of over 25,000 professionals on LinkedIn.
Amjad Afanah — Co-Founder at HoundDog.ai https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhNH1Y-xvq30VRLFXTqFf2yMR6jGf7V4mupOW249cK2rv5AgVRWhHudwK8LJVuxsReNnefK1aLnWV6O_8ooyTU91EBsbYAiNZRDja0YU15yytF8ZZwwM3WtmBy62QoRHcPRKS7kssGMXSpQ2Jw-go3h50M2MhYAZ9YgR1nP6XWuikAWGcDDu19amq2or9Y/s1600/Amjad.png
