How do we govern agentic coding assistants and AI developer tools?

Traditional shadow IT programs were designed to find unapproved software subscriptions, rogue cloud storage accounts, and "sign in with Google or Microsoft" connections that employees set up without procurement review. The underlying model is that data exposure happens through access control gaps: an employee stores files somewhere IT did not approve, and those files can be reached by the unauthorized service.

Agentic coding assistants do not fit this model. They expose data through their core function, not through a gap in access controls. A coding assistant is designed to read your code, send it to the vendor's AI service, and return a response. Every request sends data out of the company. The tool is not bypassing a control to reach the data; it is operating exactly as designed. Standard shadow IT monitoring looks for unapproved cloud storage and unknown app connections. It will not detect a tool installed on a laptop that sends code to the vendor with every keystroke, over the same encrypted web traffic as any website.

This distinction matters because it changes where the governance intervention needs to happen. For traditional shadow IT, the control is discovery and blocking. For agentic developer tools, the control is evaluation before approval: understanding what the tool transmits, whether opt-out controls are meaningful, and whether the deployment mode matches the sensitivity of the developer's access. Approval is not a yes-or-no question; it is a set of conditions.

The most important due diligence question for any agentic coding tool is not whether it has a privacy opt-out. It is whether that opt-out prevents transmission or governs retention. These are different things with different compliance implications.

A tool that sends your code to the vendor's servers on every request, but commits not to store it beyond the session, is still transmitting your code on every request. Data minimization requirements under GDPR, internal data handling policies, and contractual confidentiality obligations all potentially apply to the transmission event itself, not only to what the vendor retains afterward. An opt-out that governs retention does not satisfy data minimization if the business requirement is that proprietary code should not leave your infrastructure.

Verify this through vendor documentation and, where possible, by having your security team inspect what the tool actually sends. Ask specifically: does the opt-out prevent the code from being sent to your servers, or does it govern what happens to it after arrival? If vendor documentation does not answer this clearly, treat the answer as unknown and require clarification before approval. Document the finding in the data boundary review regardless of the outcome.

Not all developers carry the same data exposure risk when using agentic tools. A developer who works on internal utility scripts with no access to live systems carries a very different risk from a senior engineer who holds the passwords and keys to live systems, proprietary AI models, or the systems that move customer data.

Governance that applies the same approval conditions to both populations either over-restricts the first (blocking useful tools for no proportionate risk reduction) or under-restricts the second (allowing tools with broad transmission scope into high-sensitivity environments). Tier your developer population by access level and calibrate approval conditions accordingly.

For the highest-privilege tier, the practical constraints are stricter: tools must have verified no-training commitments backed by a data processing agreement, not just a terms-of-service policy. Versions that run on your own servers or in a private cloud are preferable where the vendor offers them. Tools that send large parts of the codebase with each request need more scrutiny than tools that send only the file being edited.

Approving a tool once is not sufficient. Agentic developer tool policies change, and the changes are not always announced prominently. Opt-out defaults shift, the amount of code sent per request grows, and training data policies update. A tool that satisfied your data boundary review at approval may not satisfy it twelve months later.

Build a re-evaluation trigger into the approval process: require re-review when a vendor publishes a material change to its data handling policy, when the tool's default behavior changes in a new version, or on a fixed annual cycle. Monitor vendor announcements and, for tools in sensitive environments, subscribe to the vendor's security or privacy disclosure channels.

Monitoring outgoing network traffic gives you a basic way to catch unapproved tool use between formal reviews. Ask IT security to flag connections from company devices to known AI services. This will not catch every tool, but it provides visibility into the most common unauthorized usage patterns and gives you evidence of compliance with your approved tool list policy when auditors ask.

Anthropic shifted Claude Code to auto-mode by default, cutting the human-approval step that previously gated riskier actions. Nothing about your own configuration changed; the tool's risk profile changed underneath you through a vendor default flip. The re-evaluation trigger in your approval process needs to fire on default-behavior changes, not only on major version releases or policy documents you were told to expect.

Two other patterns are worth building into your review cycle directly. Cisco Talos showed that simply talking the tools into it, with no hacking required, gets past the safety checks in Claude Code, Codex, Cursor, and Gemini at once. Separately, tampered settings files have turned approved coding agents into tools for smuggling data out, and coding agents with more permission than a task required have deleted live databases. Add a check that the tool's settings files have not been tampered with to your approval conditions, and default every tool to the narrowest permission scope the task allows, regardless of what the vendor's safety checks claim to catch.