Banning AI coding tools fails. Governance doesn't
Javier Garza trains developers on AI security for Snyk. In a session the AI Engineer channel published on Sunday, he gave the number he guarantees: ban AI coding tools, and 80 to 90 percent of developers will find a way around it. The worklogs on this site run on those very tools, so the number deserves to be taken seriously.
What does the Snyk workshop actually claim?#
Garza is a staff developer advocate at Snyk who normally runs this material as a three-hour seminar. The AI Engineer channel posted a two-hour cut on Sunday under the title AI Security Engineer Foundations, six modules covering the OWASP Top 10 for LLMs, threat modeling, supply chain risks, shadow AI, MCP server security and vibe coding. Snyk hosts the course site with a certificate at the end.
The claim that matters to anyone running an engineering team sits in the shadow AI module. His scenario: a company bans every AI coding tool except the ones with approved policies. His guarantee, in the wording of the session notes: "You can install in companies as much as possible more rules to restrict people from nonsense, but if you don't teach people and don't teach them, they will get around anything." Eighty to ninety percent find the way around, he says. The conclusion he draws is to assume the usage exists and build for it.
Shadow AI has numbers behind the guarantee#
He cites surveys without naming them, so treat these as his numbers rather than settled research: 80 percent of organizations have no authorized usage policy for AI, 60 percent of workers use unauthorized AI tools, and he puts that second figure closer to 80 percent today. More than half of people use personal accounts for work tasks, by his account.
The picture he paints from companies that do ban tools is specific. Employees keep a personal laptop next to the work machine, run the coding assistant there, and message the results back to themselves. The tool leaves the building and takes every prompt with it.
The workaround is the vulnerability#
A banned tool creates a visibility problem before it creates a compliance problem. A sanctioned tool sits in an inventory, produces logs and gets scanned. A routed-around tool produces none of that, while the code it writes still lands in your repository.
Two supply chain numbers from the session make the point. He cites a scan of third-party agent skills, the text files that teach coding agents automated tasks, in which 367 of 10,000 contained malware. In a survey he mentions, developers were asked whether AI code completion belongs to the software supply chain, and roughly 45 percent answered no, while pasting its output straight into the codebase. His claim about that output: in over half of cases, code generated from a simple prompt carries at least five vulnerabilities. He adds a newer cousin, package names the agent invented, where whoever registers the name first owns the supply chain that follows.
I write with these tools daily, and the discipline that keeps me honest is dull. Agent output is an unreviewed pull request until someone has read the diff, so a policy that pushes the tool off the books pushes the diff review off with it.
What governance looks like on a small team#
His countermeasures need no procurement. Treat everything a model reads or writes as untrusted input. Keep a human approval step in front of destructive actions, and he described his own setup, where every agent he uses confirms before deleting anything or sending mail in his name. Keep an allowlist of tools and sources and re-verify after every update, because a clean MCP server does not stay clean through its next release. Maintain an inventory of AI assets, an AI bill of materials in his terminology, and scan it daily, since models and datasets drift. Log what agents do. He claims most people never set up any logging, so an agent's side effects go unnoticed until they become incidents. And secrets: most agent tools ship no secrets manager, so people paste API keys straight into the chat, where they get stored.
| A ban produces | A gate produces |
|---|---|
| Shadow usage with no logs | Tools you can scan and audit |
| Review skipped under pressure | Review built into the workflow |
| Zero provenance in an incident | Provenance to answer with |
The interesting part is what he does not claim. He never says the tools are safe, and his own supply chain numbers say the opposite. The claim is narrower: rules without teaching fail, so the working lever is process around tools you can see.
Say yes with a gate#
The teams that handle this well do one thing differently. They pick a sanctioned assistant, wire it into the workflow, and make the sanctioned path faster than the workaround. That is a rollout, and rollout machinery is something I already trust for product features: this week I wrote up how my multi-tenant platform ships capabilities behind per-tenant feature flags. Gate first, open gradually, audit afterwards, and the same pattern fits a coding tool. This week the pattern got hardware: Chainguard launched agent workspaces that give every coding agent an isolated microVM with injected credentials and a full command log. For a team asking what Monday looks like: write down which tools are allowed, wire the list into the repository config so review can see it, and ask once a quarter which tools people actually use. The gap between the two lists is the real security posture.
Model behavior needs the treatment too. OpenAI's six misalignment reports documented models that smuggled instructions into their own summaries and invented data, and the fix there was also process: trace assertions, allowlisted hosts, a kill switch. Garza's guarantee and those reports agree on the shape of the answer, one about people, one about models. The same week went regulatory: India's CERT-In documented agents under test reaching live systems through exposed credentials nobody had rotated. A ban is a policy file. Governance is a pipeline.