The Scope has Changed

There is a version of the AI security problem that many organizations understand. It lives in the engineering organization. It involves developers using AI coding agents, models being integrated into applications, and agents being deployed into production environments. It has technical vocabulary, defined owners, and a reasonably clear connection to the security functions that have always governed what engineers build and ship.

That version of the problem is real, but it’s only a fraction of what’s actually happening.

The larger challenge with AI is just how much it has permeated every single part of the organization at once; carried out by people who have never written a line of code or access various cloud services with nothing more than a single prompt. Sales, finance, HR, legal, marketing…they are using AI the way they use any productivity tool; to get work done faster, to do more with less, to hit the targets in front of them before the deadline that’s behind them.

They are also, without knowing it, creating security events at a scale and pace that no security team currently has the visibility, or bandwidth, to address.

The People Who Aren’t Thinking About Security

Imagine for a moment that you work in sales. You connect ChatGPT to the CRM to help draft an outreach email based on summarized call notes. You aren’t thinking about data leakage or privacy considerations. You’re thinking about how you are going to hit your quota this quarter!

The connection that was just made gives an external AI service access to customer records, deal stages, contact information, and the internal notes that have been accumulating for years.

The OAuth grant that was a single click, will persist indefinitely.

The data that flows through it is not bounded by session, it’s available to the connected service for as long as the connection exists. None of this crossed your mind as a member of the sales team (and why would it). What mattered is that you just saved two hours a week in manual email drafts and prospecting.

And sales isn’t alone. It’s the finance analyst uploading a quarterly earnings document for summary and analysis by Gemini. It’s the operations manager who asked AI to pull customer support data, analyze ticket patterns, and generate a weekly report. These people are not negligent. They are not reckless.

Their job isn’t to think through the security or legal ramifications of using AI, they are simply trying to get work done. They are making productivity decisions with tools designed to make those decisions frictionless, in an environment where the gap between “this is easy to do” and “this has been approved to do” has never been wider or less visible.

Every one of them has created a security event. None of them know it.

The Assumption That Is Now Wrong

Every security model has assumptions buried in it. Most of those assumptions were never written down, because they didn’t need to be, they were true enough that making them explicit would have felt like stating the obvious.

The most foundational assumptions in enterprise security, the one that shaped decades of how security programs were designed and where controls were concentrated, is this: the people who create security risk are often the people who build software.

It’s an assumption that made sense for most of computing history. Risk lived in code. Code was written by developers. If you governed what developers built and where it was deployed, you governed the risk surface. Security organized itself accordingly, application security programs, secure development lifecycles, code review, dependency scanning, penetration testing, and cloud security misconfiguration detections. The controls targeted the people who touched the systems, and the people who touched the systems were the people with the technical training to do so.

This assumption was never perfectly true. Insiders have always posed risk. Social engineering has always targeted non-technical employees. Data governance has always had to account for what people do with information, not just how systems handle it. But the assumption was true enough to organize around; close enough to reality that building a security model on top of it produced programs that covered most of the relevant surface most of the time.

That assumption has now been turned on its head. It’s broken in a way that requires acknowledging rather than accommodating.

The attack surface is no longer defined by who writes code. It is defined by who uses AI. That population is not the engineering organization. It is not the technical staff. It is not the employees with elevated permissions or privileged access or specialized training in how systems work. It is everyone. Every person in the organization who has access to an AI, which is increasingly every person in the organization, is now capable of creating a security event without any technical knowledge, any awareness of the implications, or any involvement from the functions that were designed to govern this kind of risk.

A security model built around the assumption that risk is created by builders cannot govern a world where risk is created by everyone. The coverage gap isn’t marginal. It is the majority of the surface.

The Scale of What’s Already in Motion

The AI adoption that matters most for the overall risk posture isn’t happening in engineering. It’s happening in every other function, simultaneously, driven by tools designed for maximum accessibility and adopted by people whose professional incentives point entirely toward using whatever makes them more productive.

The risk surface compounds because AI tools are not passive. Connecting any form of AI to corporate systems doesn’t create a static exposure that can be assessed and left in place. It creates a dynamic one. OAuth grants that started narrow get extended as users discover new capabilities. Tools add features, change behavior, and sometimes change ownership or terms of service in ways that alter the risk profile of every connection already made to them. The picture of what’s running, if a picture exists at all, is a snapshot of a prior moment, already outdated before it was finished.

When the consequences surface, they won’t announce themselves as AI failures. A breach shows up as a breach. The investigation that traces it back to a connected AI tool operating with excessive OAuth scope, processing data it was never authorized to touch…that happens after the breach is already a fact.

A regulatory penalty shows up as a regulatory penalty. The audit trail connecting it to a workflow processing personal data across jurisdictions without the required residency controls gets constructed during the proceeding. A board conversation nobody was prepared for arrives because something external made it inevitable, and the answer gets assembled in real time by teams that have never had to characterize this exposure comprehensively.

None of it announces itself early. It accumulates invisibly and arrives suddenly. And when it arrives, the organization that was treating AI security as a technology problem discovers it was always an organizational one.