Building a New Security Model

The instinct is understandable. Something new arrives, it creates risk, and the response is to extend what already exists. Add a policy that covers the new thing. Expand a control to include the new surface. Bolt on a tool that addresses the new threat category. The existing security model was built incrementally through exactly this process; each new technology, each new threat category, each new compliance requirement producing another layer stacked on top of what was already there.

For AI, that instinct leads to false confidence rather than actual protection. And the difference between those two outcomes is worse than having no program at all, because false confidence stops the right questions from being asked.

Why Extension Fails Here

Acceptable use policies are the first extension organizations reach for. The policy governing enterprise technology gets updated to include AI. Approved services are listed. Prohibited behaviors are named. Personal accounts may not be used for work purposes. Sensitive data may not be submitted to unapproved services. Outputs must be reviewed before being acted upon. The policy is published, training is updated, and the governance checkbox gets marked.

The problem isn’t that the guidance is wrong. It’s that acceptable use policies were designed for a model of risk where communicating what’s permitted is sufficient to govern behavior, because the behaviors being governed are deliberate, and the people engaging in them have the context to recognize when they’re in scope.

AI exposure doesn’t work that way. The knowledge worker uploading a confidential document to an AI service isn’t consciously violating policy. They are summarizing a report. The connection between that action and the policy language about sensitive data exfiltration requires security literacy that most employees don’t have and most training programs don’t build. The policy exists. The behavior it’s supposed to govern continues, unrecognized by the person engaging in it as something the policy covers.

Vendor risk assessments present the same structural mismatch. The traditional assessment evaluates a vendor against defined criteria at a point in time; typically at procurement, sometimes at renewal. It was built for relationships that remain reasonably stable between cycles; where the product assessed is the product operated.

AI vendors don’t work that way. The model underlying an enterprise AI application can be updated by the provider without notice. Data handling terms can change. Integration capabilities can expand. An assessment accurate six months ago may be measuring a relationship that no longer exists in the form it was assessed.

Annual penetration tests are the starkest example. A penetration test validates a state, exercising a system’s defenses against known attack techniques to find gaps before a real attacker does. For traditional applications, that state was stable enough that the validation held. The code tested was the code that ran.

For AI systems, the state changes continuously. A test that validates a system on a Tuesday in April is not evidence of security posture in October, when the model has been updated twice, the knowledge base has grown, and three new tools have been connected to the agent. The test produced a valid finding about a system that no longer exists.

The Distribution Problem

The deeper failure of the extension instinct is who it positions as the solution.

Application security owns code. Cloud security owns the runtime. IT security owns endpoints and user devices. Each team manages their surface with clear lines of delineation around scope, tooling, and accountability. That model worked because the risk surface respected those lines closely enough to organize around.

AI doesn’t respect them. It runs through every function, on every device, in every workflow. The surface isn’t owned by any one team because it isn’t produced by any one team. Extending the existing ownership model to cover it doesn’t close the gap, it produces three teams with adjacent blind spots instead of one.

What the distribution of the surface requires is a distribution of security thinking. Not security responsibilities transferred to people who aren’t security professionals, the expertise and judgment security practitioners bring cannot be replicated by distributing a policy. What can be distributed is the capacity to recognize when a decision has security implications, and the knowledge of what to do when it does.

That changes what the security team does. Not from more to less, from primary enforcer of controls that can’t cover the surface to architect of a governance model that enables everyone else to make better decisions. The expertise stays in security. The application of it spreads.

The Common Language Is the Foundation

Everything described in this chapter, distributed security thinking, governance that scales with behavior, security as an enabler rather than a gate, depends on a prerequisite that doesn’t exist in most organizations yet.

A common language.

Security practitioners, business leaders, engineers, legal and compliance teams, executives; they all need to describe AI risk in terms that translate across those boundaries. Not the same technical depth. Not the same regulatory specificity. The same underlying map, expressed in vocabulary that each role can connect to the decisions they’re actually making.

Without it, distribution fails. Security thinking embedded in training lands in a room that speaks a different vocabulary. Risk that executives need to govern gets described in terms that don’t connect to the business decisions they’re responsible for. Legal and compliance enforce against a different set of categories than the controls practitioners are building. Everyone is working on the same problem and producing parallel solutions that don’t intersect.

The gap between those parallel efforts is where AI risk lives; not in any single function’s failure, but in the space between functions addressing their version of the problem without a shared framework for making those efforts add up.

A common language doesn’t require everyone to become security experts. It requires everyone to answer a small set of questions consistently:

• What are we talking about?
• Who is involved?
• What can go wrong?
• What does a good decision look like from where I sit?

What that language looks like, how it maps to the roles people actually occupy, the behaviors they exhibit, and the risks those behaviors create; that’s what we will explore next.