規制対応エンジニアリングチーム向けエージェントの出自証明を提示する「Compliance-first AI」

July 27, 2026

Regulated engineering teams must prove which files an AI agent read before it shipped a change. How scoped retrieval turns agent context into an audit trail.

For a CISO or CTO, one of the many questions that stalls enterprise AI adoption isn't whether an agent can write the code. It's whether the agent looked at the right things to make the right change, and whether you can prove it after the fact. A clean audit trail still isn't enough: an agent can document its reasoning perfectly and still patch the symptom instead of the vulnerability. What matters is that it had the right context before it acted, and that you can verify it did.

That distinction is where a lot of executive conversations are landing right now. We talk to engineering and security leaders across banking, healthcare, and large software organizations and the hesitation about agentic development rarely comes down to model capability. What we are told is it comes down to proof. When an auditor tests your change-management controls, an exception doesn't mean one file looked wrong; it means the process broke down, a change went out without the review, approval, or testing the control promised.

In auditing, two foundational management assertions, accuracy and completeness, determine whether you can rely on evidence at all, and they're verified by stress-testing the process behind it. With AI agents, the process is the retrieval. A transparent record of exactly which files an agent read, and why, lets an auditor reverse-engineer the agent's logic and confirm both assertions: the agent acted on the complete set of requirements, using only relevant, authorized code context.

When a human engineer ships a change, the Pull Request (PR) record is usually enough: approvals, review comments, CI checks. And when questions come up later, there's an engineer who can explain what they touched and why. Nobody expects a list of every file a person reads. In a SOC 2 review, auditors may pull individual PRs to confirm the promised scans and approvals actually ran, and deeper, file-level scrutiny tends to be reserved for high-blast-radius artifacts like the Terraform applied to customer environments.

The gap appears when the "engineer" is an agent. The PR still shows the diff and the approval, but there's no one to ask why the change was made the way it was. When an agent modifies an authentication flow, a data-handling routine, or a dependency with a known CVE, the context that informed the change disappears the moment the session ends unless it's captured. For most teams today, reconstructing it means a lot of manual work. That missing record is agent provenance: the evidence of which files an agent read, and why, before it changed anything. That gap, more than any model limitation, is what keeps AI from scaling in regulated environments.

Capability was never the hard part

Early code assistants were autocomplete on top of the file you had open. They could surface available functions and their parameters and fill in boilerplate, but their view was limited to the current file and a small context window; everything else came from static training data. They had no awareness of your wider codebase, and they worked strictly side-by-side with a developer. The fix was giving models live access to repositories, tools, and documentation, which is what the Model Context Protocol (MCP) and the wave of agentic tooling formalized. That's what made agentic coding practical. It also made one thing very clear: getting an agent to act is increasingly easy. Getting it to act accountably is much harder.

An agent that retrieves broadly, pulling in whole repositories, guessing at context, and hallucinating when it can't find what it needs, produces output no one can vouch for. When that output is a security-critical change, "the model decided" is not an answer that survives a compliance review. The capability is there; the problem is that engineers, and ultimately the CISO and CTO, still have to verify the accuracy and completeness of what agents produce, and they can't do that without seeing the context the agent used. Make that visible and two things follow: reviewers can check output against the exact sources consulted, and teams can set guardrails so agents follow the same retrieval patterns consistently. No more surprises turning up for the first time at audit time.

Focused retrieval is a control

The engineering community has been converging on a pattern: scope the problem first, then reason. Narrow, deliberate retrieval keeps token costs down, but the more important benefit for the enterprise is that it makes an agent's behavior legible.

An agent grounded in precise, scoped context leaves a trail. You can see what it asked, what it found, and what it read. That trail is the difference between an AI workflow you can put in front of an auditor and one you have to quietly keep out of regulated systems.

What an audit-ready agentic workflow looks like today

Sourcegraph's Deep Search returns an explicit list of sources with every answer: a record of which searches it ran and which files it read to reach its conclusion. That source list isn't a debugging nicety; it's an evidence trail. When an agent's reasoning is questioned, you can point to exactly what it consulted.

Underneath that, the Sourcegraph MCP server exposes discrete, named operations (read a file, search by keyword, jump to a definition) rather than an opaque "do the thing" interface. Every action an agent takes is a legible, individually observable event. Access is governed by repository permissions and scoped tokens: agents can only read the repositories a user is already permitted to see. Processing happens inside your own instance; the only external call is to the model itself. Put together, that's not just retrieval. It's a permissioned, observable record of what your agents touched.

Auditors want a timestamped, traceable answer grounded in real code and config changes: not just what changed and how, but why. It's the difference between "we modified this line" and "we added JWT claim enforcement on this endpoint because your audit found it missing, and here's the exact change that closed the gap."

That's Deep Search's value. It cites commit history, file paths, and code context, then ties them back to the reasoning behind each change, instead of relying on someone's memory or a stale Confluence doc. And the record is a concrete artifact: every conversation exports as a PDF you can hand to an auditor instead of asking them to take the agent's word for it. That does more than satisfy the control; it shortens the audit. The auditor doesn't have to poke around your environment piecing together what informed a change, because the sources and context are already laid out in a traceable line.

Exporting a Deep Search conversation as a PDF

Ask Deep Search the questions your auditors ask you

Change management / access control

• "Show me all commits touching the authentication service in the last audit period."

Deep Search groups every commit touching the authentication service by theme, with SHA, date, and author for each one

• "When did we implement the 'right to be forgotten' / user data deletion endpoint?"

• "Where is PII encrypted at rest, and when was that encryption added?"

• "Do we have code that logs or stores IP addresses without consent checks?"

Sourcegraph MCP server: the Deep Search tool in Claude Code, run against the public gitlab-org/gitlab repository

Security controls (SOC 2 / ISO 27001)

• "When was MFA enforcement added to the admin login flow?"

• "Where do we validate that access tokens expire, and what's the expiration window?"

• "Show me all places where secrets/API keys might be hardcoded instead of pulled from a vault."

PCI-DSS (payment data)

• "When was the last change to the payment processing module, and who approved it?"

• "Where does credit card data touch our codebase, and is it tokenized before storage?"

Deep Search traces credit card data from entry point to storage in the public gitlab-org/gitlab repository, naming the files and the fields that get hashed

SOX (financial controls)

• "Where is revenue recognition logic implemented, and when did it last change?"

HIPAA (healthcare)

• "Where is PHI access logged, and when was audit logging added?"

• "Do we have role-based access control gating PHI fields, and when was it introduced?"

Primary sources: SOC 2, ISO/IEC 27001, PCI-DSS, GDPR Article 17, HIPAA 45 CFR 164.312, SOX Section 404.

From productivity tool to system of record

The instinct is to evaluate a context engine as a developer-productivity tool: faster search, better answers, less time hunting through repos. That's real, but it undersells what matters most to the people signing off on enterprise AI.

For a security or platform leader, the context layer is also the audit and compliance layer for agentic development. It serves as the system of record for agent provenance, answering the questions regulators and risk teams actually ask: what did the agent read, and why did it act the way it did.

Once your organization shifts from experimenting with agents to depending on them, that answer stops being optional. The teams that can produce it are the ones that get cleared to use AI where the stakes are highest. It is the same shift that separates detection in one repo from an actual security posture: the capability is only worth what you can demonstrate across the whole codebase.

Ready to prove what your agents read? Book a demo.

*A special thanks to André Eleuterio, Dora Neumeier, Jamie Lindsay, Makenna Freauf, Matt Tanner, and Stephanie Jarmak for their contributions to this blog post.*