Agentic dev tools are the new shadow IT — with a bigger blast radius.
This month’s agentic-tooling incidents expose a class of exposure the old shadow-IT playbook was never built to catch. It lands on the teams shipping software and on the vendors selling the guardrails.
Two things happened in mid-July. An agentic coding tool was shown to transmit an entire repository — source, secrets, all of it — as a normal part of doing its job. Around the same time a major enterprise banned an AI coding assistant internally over what it was sending home and how little of that was written down.
The reflex in most security teams is to file these as data-leak incidents. That is a category error, and it changes how you defend against them.
- Agentic coding tools move code as a core function, at the developer's privilege level.
- Shadow-IT controls miss them because the app looks sanctioned.
- Buyers will start demanding action logs, least privilege, and enforced human checkpoints.
What actually happened.
An agentic dev tool reads your codebase, acts on it, and moves code off the machine because that's the job. When it exposes something, it exposes it in proportion to the developer's own access — which for a senior engineer is most of what matters. Neither incident was exotic. The tool did what it was built to do, in an environment that assumed it would behave like the software it replaced.
Why the shadow IT framing fails here.
For fifteen years shadow IT meant somebody expensing an unapproved SaaS app. Everything we built for that — discovery, SSO enforcement, acceptable-use policy — assumes the risky thing is access to a service.
Agentic tools break that assumption. The problem isn't that someone signed up for something unapproved. It's that an app which looks completely sanctioned has codebase-level reach and instructions to act on its own.
- They carry the developer's privileges, so the blast radius scales with whoever is running them.
- They transmit code as a feature, which means the data movement looks like normal traffic.
- Their behavior is steered by natural language, so guardrails hold only as well as the model honors them.
- They live inside developer workflows that move faster than any review board.
If you sell security, this is an opening.
The buyer just found out, in public, that their existing category of controls doesn't cover the thing they're most worried about. Name that gap plainly — agentic access governance, tool identity, action traceability — and you've handed them language for a budget line that didn't exist last quarter. Whoever defines this before the analysts do will own it.
We wrote about the liability side of this shift in our piece on agentic AI as production liability. The controls buyers will reach for map cleanly onto the NIST AI Risk Management Framework.
The buyer just learned, in public, that their existing controls do not cover the thing they are most worried about.
What buyers start asking for next.
Expect security questionnaires to grow a new section over the next two quarters. The questions come straight out of these incidents:
- What does this tool transmit, where does it go, and can we see a log of every action it took?
- Does it run with least privilege, or with the full reach of whoever invoked it?
- Can a human checkpoint be enforced before it acts, and is that enforced in code or just in a prompt?
- What is actually documented about how the vendor handles the code it receives?
For both sides of the table.
If you ship software, treat agentic tooling as a governed capability with its own controls rather than waiting for the review board to catch up. If you sell into that anxiety, speak to the category your buyer now knows they're missing. Either way, the companies that get ahead of this are the ones who stop calling it shadow IT and govern it as what it is.