Architecting one yes sounds like a favor you do for the business, a bit of paperwork to unblock a nagging request. It is closer to the most strategic thing a security team can do this quarter. Here is the story that made me believe that.
A security team I know blocked a GenAI writing tool last year. The call was clean on paper. A vendor review flagged loose data retention, the risk register lit up, and the tool went on the block list by Friday. Everyone did their job. The policy was airtight.
Three months later, someone on that team pulled a quarter of egress logs and cross-referenced the CASB. Roughly sixty percent of the marketing org was using the exact same category of tool through personal accounts on personal devices. Same sensitive briefs, same customer language, now flowing through channels with no logging, no retention terms, and no security review at all. The block had worked perfectly. It had changed one thing only, and that thing was visibility.
The CISO's first instinct was the natural one. Tighten. Add DNS filtering, push the block to the endpoint, send the sternly worded reminder. She sat with it over a weekend and came back Monday with a different question. Not "how do we stop this," but "why is the unsafe path the only path we built?"
That question reframes the entire job. The team had spent its energy defending a door while the whole department climbed through a window nobody thought to watch. The demand for the tool was never in question. The people wanted it, the work rewarded it, and **no policy was going to out-argue a deadline. **The only real variable was which channel that demand ran through.
Name the pattern and you can plan around it. Demand does not disappear when you block it. It relocates. Prohibition without a substitute does not reduce risk, it just chooses which risk you get to see. You trade a governed tool you dislike for an ungoverned one you never hear about until the incident.
This is not new, and that is the encouraging part. Every control that actually won over the last decade won by aligning with what people already wanted, not by fighting it. Single sign-on beat password complexity rules because it made the secure path the fast one. Managed devices beat banning phones. SASE beat the VPN because friction was the thing driving people around the VPN in the first place. The pattern holds: security wins when the safe road is also the easy road, and loses every time it asks people to choose between doing their job and following the rule.
Platform engineering already has a name for this. They call it the paved road. You do not forbid the twelve risky ways to deploy. You build one well-lit path that is so much easier than the alternatives that people take it without being told to. Security is late to this idea, and AI is the forcing function that makes catching up urgent.
Here is the part most teams get backwards. They keep score by what they blocked. The block list becomes a kind of trophy case, a wall of decisions that all read as wins in the moment and quietly double as a map of everywhere the org is now working in the dark. Every entry says "we said no," and says nothing about what happened next.
The few teams who get this right keep a different scoreboard. They measure what they safely enabled. They can point to the tools people use through a gateway they own, with logging they read and controls they set. The difference shows up in one behavior. When security is the team you route around, you learn about adoption from an incident. When security is the team that builds the paved road, you learn about it from a request, because saying yes through you is faster than sneaking around you.
So the move is not softer governance. It is governance placed where the work actually happens. Take the one use case your org is blocking today and design the version you could sign. Three questions carry most of the weight. What data does it touch, and what is the worst thing that could leak? Which identity uses it, human or machine, and how is that identity proven? What access path puts it behind something you can see, a gateway, an SSO boundary, an inline DLP check, a logged proxy?
Write that on one page. Not a policy, an architecture. The one-pager that a skeptical peer could read in five minutes and sign.
The second-order effect is where this pays off, and it takes a few weeks to show. Once one paved road exists, the flow reverses. The next team with a blocked tool does not route around you, they bring it to you, because you have proven that yes is the faster answer and that you are the group who knows how to build it safely. You stop being the office of no and start being the shortest distance between an idea and a controlled launch. That reputation compounds. It is the difference between a security program people hide things from and one they build with.