The Code You Didn't Authorize

A CISO is reviewing a vendor security questionnaire when an engineer messages her. If we're using Copilot in our IDE, does that count as a third-party data processor? We don't use Copilot, she replies. We do, he says. Most of the backend team has been on it since August.

No procurement. No security review. Engineers had signed up individually, connected their repos and started pasting code, including internal API logic, database schemas and, in at least one case, environment variables with production credentials. Nobody asked permission. Nobody needed to. The tool just worked.

Coding assistants are the fastest-adopted category of enterprise AI, and not because leadership chose them. Developers did. They live inside developer tools, so they look like productivity features rather than enterprise software, and they skip the intake every other tool goes through.

I use these tools every day, and so do many of the people I build with. Not all of them, and that is fine. What matters is not whether people use the tools. It is whether anyone knows who is using them, for what, and inside which boundaries.

Suggest and act are different rungs

The newest assistants do not just suggest code. They open pull requests, modify files across repositories, run commands and interact with internal systems. Once a tool can act rather than recommend, the risk changes.

This is the delegation ladder arriving without anyone choosing the rung. A tool that drafts while you read every line sits low on the ladder. A tool that opens its own pull requests across repositories sits much higher. Most teams moved up that ladder by upgrading an extension, not by answering the two questions that are supposed to set the rung: how much of the judgment is written down where the machine can read it, and how expensive is wrong.

If a tool can act, it needs least-privilege permissions, scoped tokens and an audit trail. Suggest and act are different governance categories because they are different rungs.

The zones that stay by hand

Not all code carries the same risk. Authentication flows, encryption, payment processing and anything under regulatory audit deserve heightened scrutiny, or should be off-limits to generation entirely.

That is the practical edge of what cannot be delegated. Some knowledge is tied to one system's history and to the people who have watched it fail, and the restricted zones are where that knowledge lives. Writing them down, as a boundary that both the tools and the next engineer can see, is how the judgment survives the next tool change.

Three questions

Ask your team three things this week. How many AI coding tools are active right now, sanctioned and not? What code and data have been sent to external models in the last 90 days? If you had to revoke access to all of them by end of day, could you?

"We're not sure" is a visibility problem. "We don't know" is an exposure problem. "Not easily" is a dependency problem. Any one of them is manageable. All three together is an incident waiting for a trigger.

Adapted from The Code You Didn't Authorize in The Forward View. Read the full issue.