Enterprise security has always had a comforting assumption baked into it: systems do what they were built to do.

Sometimes badly. Sometimes insecurely. Sometimes in ways that make auditors develop a nervous twitch. But still, the basic shape was understandable. Applications processed requests. Databases stored data. APIs connected systems. Users clicked things they probably should not have clicked.

Then AI arrived and made the whole thing a little weird.

AI did not introduce one neat new risk category. Security teams are very good at turning new risk categories into taxonomies, dashboards, and meetings with names like “working group.”

The real change is that AI cuts across the categories we already had.

Employees use AI tools to summarize, analyze, code, create, and make decisions faster. Developers embed models into applications connected to customers, documents, databases, and internal systems. Agents retrieve information, call tools, invoke APIs, and take action across workflows.

AI is no longer sitting politely inside a single application boundary. It is becoming a new execution layer across the enterprise.

A prompt entered in a browser can shape a business decision. A retrieved document can manipulate an application response. A model output can trigger an agent action. A tool call can move data, change a record, or initiate a workflow before a human has time to review what happened.

In other words, language has become executable.

That does not mean every prompt is code. It means natural language can now influence how systems behave, what they access, what they generate, and what actions they take.

This is already showing up in real security research. Check Point Research has disclosed vulnerabilities in AI developer tooling, including command injection in OpenAI Codex CLI and critical flaws in Claude Code that could expose API keys and redirect authenticated traffic. Researchers have also documented how hidden instructions in AI workflows can manipulate agents into exposing secrets or taking attacker-controlled actions.

That is why enterprises need an AI Defense Plane.

The AI security gap is architectural

Most enterprises understand that AI changes the risk model. The harder question is whether they have the architecture to control it.

According to Check Point’s 2026 Cloud Security Report, 77% of organizations have changed their security strategy in response to AI, but only 26% say they have the architecture to enforce it.

This creates a familiar enterprise pattern: the strategy has moved on, but the architecture is still looking for its shoes.

Policies get written. Governance boards are formed. Acceptable-use rules are published. Teams deploy filters, model safeguards, data controls, or testing processes. All of that matters. But it does not automatically create a coherent control model.

AI risk does not stay inside one layer. It moves between employees, applications, models, data, tools, APIs, and agents. It appears through interaction, context, intent, and behavior.

The issue is not whether an organization has AI policies or point solutions. The issue is whether it can enforce them across the places where AI is used, embedded, and allowed to act.

Point controls do not see the full path

Point controls can solve narrow problems. They can inspect a traffic path, filter an input, monitor a tool, or test a model at a specific moment in time.

But AI systems rarely fail in only one place.

A single AI workflow may begin with a user request, pull in retrieved context, pass through a model, generate an output, and trigger an action through an agent or tool. Every step may look legitimate in isolation. The risk often appears in the chain.

That is where fragmentation becomes a problem. One team may manage employee AI usage. Another may secure AI applications. Another may review models. Another may own identity and access. Another may manage data protection.

Each sees part of the picture. None sees the full execution path.

If AI risk travels through the system, security cannot sit in a corner and wait for it to arrive.

What is the AI Defense Plane?

The AI Defense Plane is a unified security architecture for discovering, protecting, governing, and validating AI behavior across the enterprise.

It is not one control point. It is a coordinated control model across three connected planes: employees using AI tools, applications embedding AI into workflows, and agents that access data, invoke tools, call APIs, and take action.

Across those planes, the AI Defense Plane brings together four capabilities: discovery, protection, governance, and assurance.

Discovery shows where AI is used, what data flows through it, and where it can act. Protection prevents prompt-based attacks, data exposure, unsafe outputs, tool misuse, and out-of-policy behavior at runtime. Governance enforces policy consistently across users, applications, agents, and environments. Assurance continuously tests whether AI systems and controls behave safely as models, prompts, tools, permissions, and workflows change.

These capabilities need to work together.

Governance without enforcement turns policy into guidance people can acknowledge, admire, and then route around. Testing without runtime control exposes weaknesses but does not stop production misuse. Runtime protection without assurance can drift as systems evolve.

Only 14% of organizations say they have AI security policies that are both enforced and audited. The AI Defense Plane connects these functions into one operating model.

The three planes of enterprise AI risk

These planes are useful because they show where AI enters, where it runs, and where it acts. But they are not hard walls.

That is part of the problem.

A copilot-powered workflow created by an employee can start to look a lot like an AI application built by a development team. It may access corporate data, combine context from multiple systems, and trigger actions across business tools. The owner may be different. The risk pattern is not.

1. Employees: AI enters through the normal path of work

For many organizations, employee AI use is where the risk shows up first.

People use AI tools to summarize documents, write code, analyze data, draft customer responses, and troubleshoot problems. Much of that usage happens through browsers, SaaS tools, personal accounts, copilots, and productivity applications.

The risk is not only malicious behavior. Often, the bigger issue is ordinary work happening faster than existing controls can follow.

Only 5% of organizations report full visibility into AI tool usage, data access, and data movement.

As Adam Ely, GM of AI Security at Check Point, put it: “A mistake that somebody makes has a bigger blast radius.”

Workforce AI Security needs to operate where employees actually use AI: across sanctioned and unsanctioned tools, uploads and downloads, browser sessions, SaaS applications, and workflows where sensitive data moves.

2. Applications: AI changes how software behaves

AI applications are different from traditional applications because their behavior is shaped dynamically at runtime.

Prompts are assembled. Context is retrieved. User input is interpreted. Model outputs are generated in real time. The same application can behave differently depending on the prompt, retrieved data, system instructions, tools, and state.

This is where traditional application security starts to feel like it has been handed a very confident intern who keeps making decisions no one explicitly approved.

The request may be syntactically valid and still unsafe. The response may appear helpful while leaking sensitive information. Retrieved content may manipulate the model without the user ever seeing the instruction.

Securing AI applications requires runtime protection in the path where prompts, context, outputs, and actions are evaluated.

3. Agents: AI becomes an actor inside the enterprise

Agents represent the sharpest version of the shift from response to action.

They do not only generate text. They retrieve data, make decisions, invoke tools, use credentials, call APIs, and execute tasks on behalf of users, teams, applications, or workflows.

The 2026 Cloud Security Report found that 64% of organizations already have AI agents in pilot or production, and 12% have granted agents privileged access to core systems.

Or, as Adam Ely put it: “We’ve never had this non-human workforce that is autonomous or semi-autonomous.”

Least privilege remains essential, but incomplete. An agent can be allowed to access a tool and still use it at the wrong time, for the wrong reason, with the wrong context.

AI Agent Security needs to control the execution layer: prompts, data flows, outputs, tool calls, and actions.

Runtime is where AI risk becomes real

AI security has to operate at runtime because runtime is where AI behavior is determined.

A static review can evaluate a system design. A policy can define what should be allowed. A model safeguard can reduce known categories of unsafe output. But AI behavior depends on the live interaction: the user’s prompt, retrieved context, available data, connected tools, agent instructions, permissions, and environment state.

Only 17% of organizations have broadly deployed runtime LLM controls, even as AI workloads and agentic systems move into production.

That is why detection after the fact is not enough. A prompt can lead to a tool call. A tool call can change data. A changed record can trigger another workflow. By the time an alert is reviewed, the action may already have happened.

Runtime protection extends existing controls into the semantic layer where AI behavior is shaped. It asks questions traditional controls were not built to answer: What is the user or system trying to get the AI to do? Is sensitive data being exposed? Is the agent action aligned with user intent and business policy? Is the tool call appropriate given the context?

These questions require controls that understand language, context, and behavior, not only files, packets, identities, or API calls.

From testing to enforcement

AI security cannot be treated as a one-time deployment gate.

Models change. Prompts change. Applications change. Agents gain tools. Permissions shift. Attack techniques evolve. A system that behaved safely last month may behave differently after a model update, new integration, or workflow change.

56% of organizations have no formal AI security testing process or test only ad hoc.

This is the part of AI security that makes “we tested it before launch” sound a little like “we checked the weather in March, so the whole year should be fine.”

AI Red Teaming helps teams understand how AI systems can be manipulated under realistic conditions. AI Agent Security applies runtime control in production, helping prevent prompt-based attacks, data leakage, unsafe behavior, and out-of-policy tool use before they turn into business impact.

Together, they create a feedback loop: red teaming reveals realistic failure modes, runtime protection turns those lessons into controls, and production signals inform future testing.

The goal is not to certify an AI system once. The goal is to keep security aligned with how the system actually behaves over time.

The path forward

Enterprises do not need a new disconnected AI control. They need a security model that matches how AI now operates.

AI is already embedded in employee workflows. It is already entering applications. It is already moving toward agents that can retrieve data, invoke tools, and take action across business processes.

That means discovering AI usage across the enterprise, protecting the runtime paths where AI behavior is shaped, governing policy consistently, and continuously validating whether AI systems and controls behave as intended.

For CISOs and security leaders, this creates a path to say yes to AI with greater confidence. For platform and application teams, it creates a way to deploy AI without treating security as a blocker. For governance teams, it turns policy into enforceable control.

AI has moved from language to action.

Security now needs to move from fragmented controls to a unified AI Defense Plane.