Your Organization Just Got a Code Cannon. Who Controls the Trigger?

Here is the part nobody is saying clearly enough. AI does not just help your developers write faster code. It hands every person in your organization the ability to generate production-grade risk at machine speed. Marketing. HR. Finance. The intern who just got access to your tenant. All of them.

That is the actual headline.

Most security conversations about AI orbit the familiar anxieties: data exfiltration through LLM prompts, model poisoning, deepfake social engineering. Those are real. But they are downstream of a more fundamental shift that most security programs have not yet reckoned with. The threat surface is no longer just your attack surface. It is your entire workforce, now operating with capabilities that used to require a software engineering degree and a sprint cycle.

I run enterprise cybersecurity for dozens of state agencies across hundreds of thousands of devices. The environment is heterogeneous in ways that keep me sharp. Different risk appetites, different legacy architectures, different levels of technical maturity, all of them now connected to the same AI tools the rest of the world is using. What I have watched happen over the last twelve to eighteen months is not a gradual adoption curve. It is a step function. And step functions break security programs that were designed for linear change.

The real problem is not that AI is being used. The problem is that most organizations treated AI adoption as a productivity question and forgot to ask the risk question at the same time.

Think about how production code used to get written. A developer sat down, wrote something over days or weeks, it went through review, it hit staging, it went through QA, and eventually it made it to production. That pipeline had friction, and friction is a risk control. Not a great one. Not sufficient on its own. But every gate was a chance to catch something.

AI collapses that pipeline. A developer, or a non-developer with some prompting skill, can go from idea to deployed artifact in an afternoon. The friction is gone. And friction, it turns out, was doing more security work than we gave it credit for.

Aviation safety culture figured this out decades before software did. The principle is not that you slow down every operation. The principle is that you build chains-of-error checks into the workflow so that no single point of failure, human or machine, can cause a catastrophe without at least two other things also having to go wrong. That is why cockpit checklists exist. Not because pilots are careless, but because speed and cognitive load are a dangerous combination and deliberate process controls offset both.

We need the same instinct for AI-assisted development and AI-assisted work generally. The answer is not to ban the tools. Organizations that refuse to embrace AI will lose, and they will lose badly. The answer is to instrument the workflow, not just the output.

This distinction matters. Most security teams are focused on what AI produces: the code, the document, the output. They want to scan it, classify it, flag it. That is necessary but not sufficient. You also have to understand what the AI is doing while it is working. Agentic AI, which can execute multi-step tasks, interact with live systems, call APIs, and iterate on its own output, introduces a category of risk that static analysis does not catch. The risk is in the execution path, not just the artifact.

If you are still thinking about AI risk as a data classification problem, you are one generation behind.

Here is what the right mental model looks like for enterprise security leaders right now.

First, your data governance posture has to be ahead of your AI deployment posture. I have seen organizations race to deploy AI productivity tools while their data labeling is still aspirational and their access controls still run on the assumption that humans, not automated agents, are making requests. Those two things do not coexist safely. Get your data house in order first. If you do not know what data your employees are touching, you definitely do not know what your AI agents are touching on their behalf.

Second, agentic AI needs its own identity and access management framework. An agent is not a user. It should not inherit a user's permissions. It should have scoped, auditable, time-limited access to exactly what it needs to complete the task it was given. If your IAM infrastructure cannot express that, fix your IAM infrastructure before you let agents run in production.

Third, you need behavioral baselines that account for AI-assisted activity. The traditional insider threat model assumes human-speed behavior. An agent can exfiltrate a year's worth of sensitive documents in the time it takes a person to make a cup of coffee. Your detection logic has to be calibrated to that reality. If your anomaly thresholds were built before your organization started using agentic tools, recalibrate them now.

Fourth, and this one is less technical, give your employees the framework before you give them the tools. The gap I see most often is not that people are malicious. It is that they do not know what the rules are. They use AI to help draft a document and paste in data they would never email externally but do not think of an AI prompt as an external channel. They build an agent that solves a real problem and give it access they would not give a contractor without a background check. They are not bad actors. They are operating without a mental model for the risk they are creating.

The discipline that separates sound risk management from reactive firefighting is not better detection. It is better anticipation. You have to understand what your organization is going to do before they do it, build controls into the path, and make the secure path the easy path. If your security controls make AI harder to use than it needs to be, people will route around them. That is not defiance. That is human nature. Design for it.

AI is not going away. The productivity gains are real, the competitive pressure is real, and the expectation that your workforce uses these tools is now real. My job is not to be the person who slows that down. My job is to make sure the organization can move fast without generating risk it cannot manage.

The code cannon is already loaded. The question is whether anyone has thought about where it is pointed.