What is AI security?

By Cameron McClellan, Growth Engineer

·Published May 14, 2026

Most organizations deploying AI agents have the same security stack they had before agents existed. That stack was built for a model you query. Agents do not work that way. They read files, call APIs, query databases, and execute decisions without a human in the loop for each step, and none of that activity is visible to firewalls, EDR, or SIEM tools. Where AI governance defines what AI is allowed to do, AI security is the layer that enforces it.

The result is a new class of risks. Prompt injection through untrusted content in the context window, data exfiltration through authorized tool calls, and ungoverned agent actions with no audit trail. These risks concentrate at two layers that conventional security tooling was not designed to see:

1. Model call layer. The agent submits prompts and receives completions from an AI provider. The entire context window is processed as potential instruction, with no inherent separation between trusted and untrusted content.

2. Tool call layer. The model acts on those completions by calling real systems with real credentials. There is no inherent constraint on scope.

A developer running a Claude Code session against a production database with no MCP gateway and no hooks deployed has full credentials, no audit trail, and produces no record in any security system the organization has.

These layers introduce attack vectors that firewalls, EDR, and traditional DLP were not designed to detect. OWASP’s Top 10 for LLM Applications — compared with NIST AI RMF and MITRE ATLAS in AI security frameworks — identifies the most critical of these vulnerabilities:

• Prompt injection. Agents process external content (documents, tickets, API responses) with the same trust as the original user prompt, so any untrusted content entering the context window becomes a potential instruction.
• Data exfiltration through authorized tool calls. An agent with legitimate access to a database can be instructed to exfiltrate records through a tool call that looks authorized to every layer of the existing stack.
• Tool poisoning. Malicious tool descriptions or responses manipulate the agent’s behavior without triggering any conventional security control.

An AI control plane is built to cover the model call and tool call layers. It enforces policy on every tool call an agent makes and produces an audit trail of agent actions that conventional security tooling cannot see.

AI security is still being defined

Security vendors are shipping products under the “AI security” label to address the risks that agentic AI introduces:

• CrowdStrike — Charlotte AI and AI Security Posture Management, focused on AI-assisted threat detection and posture visibility.
• Palo Alto Networks — AI Access Security through Prisma SASE, providing inline inspection of AI sessions and sensitive data transfer monitoring.
• Wiz — detects misconfigurations in AI infrastructure at the cloud layer.
• Runlayer, MintMCP — purpose-built for MCP security and agent governance at the tool-call layer.
• ServiceNow — extending existing enterprise governance frameworks to cover AI systems.

The scope of these tools does not overlap. That is because the field of AI security is still being defined, with each vendor addressing the risks it covers.

For example:

• CrowdStrike covers threat detection and endpoint visibility but has no governance over tool calls an agent makes after a model responds.
• Runlayer governs tool calls at the MCP layer but does not address cloud misconfigurations or endpoint threats.
• Wiz detects infrastructure risks at the cloud layer but has no visibility into what an agent does at runtime.

Security leaders evaluating these products need to look past the “AI security” label and assess what each tool actually covers and where its coverage ends.

The five AI security layers

Legacy security tools were not built for agents that call APIs and act autonomously on model responses. Enterprise security covers five layers:

• Identity and access — authentication, tokens, and identity propagation
• Endpoint and device — EDR, MDM, and agent runtime configuration
• Network and infrastructure — firewalls, ZTNA, and cloud posture
• Application and AI — model calls, tool calls, and gateway policy
• Data — storage access controls, output filtering, and audit logging

Traditional tools have strong coverage at the identity, endpoint, and network layers. None of them see prompts, tool calls, or what an agent does after a model responds.

An AI control plane is a policy enforcement and observability layer that sits between AI agents and the systems they interact with. It covers:

• Intercepting and inspecting model calls and tool calls
• Enforcing access policy on what tools an agent can call
• Filtering model outputs before they reach the user
• Producing a structured audit log of agent actions

The diagram below maps all five layers against what traditional security tools cover and where an AI control plane takes over.

Identity and access

SSO, MFA, and identity providers (Okta, Entra ID, Ping) authenticate users and issue tokens at this layer. For AI workloads, OAuth On-Behalf-Of tokens pass a user’s identity and permissions through the request chain, making downstream tool calls attributable to a specific user rather than an anonymous process.

Endpoint and device

This layer covers the devices and processes that AI agents run on. Traditional controls at this layer include:

• EDR (CrowdStrike Falcon, SentinelOne) — detects and responds to threats at the process level
• MDM (Jamf, Intune) — monitors device health and enforces configuration policy

EDR operates at the OS process level. When an agent runs, EDR sees a process start and stop. It does not see the prompt that triggered it or the tool calls the agent made inside that session.

Agent hooks operate one level deeper, inside the agent runtime itself. They are user-defined handlers that execute at specific points in the agent’s lifecycle:

• Before a prompt is submitted to the model
• Before a tool call is executed
• After a model response is returned

Each event is emitted as a structured log entry, giving security teams a complete record of what the agent did within a session.

This layer is also where shadow AI is most visible. Shadow AI is any AI tool usage that has not gone through IT or security review:

• Coding agents installed on developer laptops with their own MCP servers
• Personal API keys stored in developer configs or dotfiles
• Unapproved model providers accessed outside sanctioned tooling

Without hooks deployed at the agent level, none of this activity is visible to the security team.

Network and infrastructure

This layer covers the network controls and cloud infrastructure that AI agents operate within. Traditional controls at this layer include:

• Firewalls and ZTNA — enforce access policy based on destination and device posture
• Cloud security posture tools (Wiz, Palo Alto Prisma SASE) — detect misconfigurations and exposed credentials in cloud infrastructure

For AI workloads, these controls have a gap. They authenticate users and devices, but not the agent processes making requests. A request arriving at a database or API looks like any other service call. There is no way to verify it came from a registered, approved agent.

SPIFFE SVIDs address this by issuing cryptographic identity credentials to workloads. Each agent is issued an SVID, a short-lived certificate that encodes its identity. When the agent makes a request, the receiving service can verify the certificate and confirm which agent it is talking to. This is workload identity, the network equivalent of user authentication applied at the agent level.

Application and AI

This layer is where AI-specific controls live. Traditional security tools have no presence here. Firewalls, EDR, and identity providers operate below this layer. Nothing in a standard enterprise security stack inspects what goes into a model, what comes back, or what the model decides to do next.

Two gateway types operate at this layer.

LLM gateway (also called an AI gateway) sits between agents and model providers. It intercepts every model call and can:

• Inspect prompts and completions for policy violations and PII
• Enforce rate limits per agent or user
• Apply policy rules using OPA or Cedar
• Log every request and response

MCP gateway sits between agents and the tools they call. When a model generates a tool call, the MCP gateway intercepts it before it reaches the tool server. It can:

• Authenticate the calling agent before the tool call is forwarded
• Enforce tool-level access policy
• Validate tool-call schemas against expected inputs
• Apply DLP to tool responses before they re-enter the context window
• Provision credentials just-in-time from a secrets manager rather than storing them in agent configs

Data

This layer covers what AI agents can access and what they can return. Storage systems enforce their own access controls:

• Row-level security and column encryption at the database level
• Bucket policies and object-level permissions in object stores
• Scoped API credentials for external services

The MCP gateway governs which tool calls reach these systems at all. The data layer then enforces what those tool calls can return. These are two distinct controls operating in sequence. The gateway decides whether the call is allowed. The storage system decides what the call can see.

Output DLP adds a third control. When an agent processes sensitive records in its context window, those records can appear in the model’s response even if the original data access was authorized. Output DLP filters completions before they reach the user, catching data that should not leave the system.

Across all of this, the structured record of agent actions is what makes AI observability possible. Security teams can reconstruct exactly what an agent did in a session and what data its tool calls returned.

The fragmented AI security vendor landscape

The AI security vendor market is fragmented by layer. Each vendor category covers a different part of the five-layer stack:

• CrowdStrike — primary coverage at the endpoint and identity layers. Falcon AIDR adds session-level AI visibility but does not cover tool calls or agentic workflows.
• Palo Alto Networks — primary coverage at the network layer. AI Access Security adds inline inspection of AI sessions but does not cover the tool-call layer.
• Wiz — cloud infrastructure posture, focused on misconfigurations and exposed credentials.
• Runlayer, MintMCP — purpose-built for MCP security and agent governance.

No vendor in this category covers all five layers. Speakeasy is building the AI control plane to address that gap. It combines agent hooks and an MCP gateway on a shared identity foundation, starting at the application and AI layer and extending toward full coverage across all five.

Before selecting a vendor, security leaders need to identify which layer represents their most urgent exposure. Mapping current coverage against the five-layer framework shows what an organization has and where the gaps are.

The most urgent AI security risks in 2026

Prompt injection attracts significant attention, but it is not the most widespread risk in deployed systems today. The risks that affect the widest range of production deployments are covered below.

Ungoverned tool calls. An agent running without an MCP gateway has no constraint on what tools it can call or what data those tools return. An agent with write access to a production database and no MCP gateway in front of it can read, modify, or delete records with no audit trail and no policy enforcement.

Credential scatter. As organizations deploy more agents, provider API keys accumulate across environment variables, developer dotfiles, and CI pipelines. Each key is a potential exposure point. An LLM gateway centralizes provider credentials and removes per-application key management. The same discipline applies to tool-call credentials. Secrets should be provisioned just-in-time at the MCP gateway rather than stored in agent configs.

Agent runtime blindness. Without hooks at the agent level, security teams have no visibility into which MCP servers are installed in their environment, what tools those servers expose, or what actions they are performing. AI-powered detection in existing SIEM tools and prompt-filtering firewalls see model inputs and outputs. They do not see what the agent does after the model responds, which is where tool calls execute and where most of the risk lives.

A note on Speakeasy

Speakeasy is building the AI control plane. It covers the model-call and tool-call layers where traditional security tooling has no visibility.

The diagram below shows how shared identity, agent hooks, and MCP gateway connect on a single governed path from every agent to every system.

Agent hooks for runtime visibility

Speakeasy ships hook configurations for Claude Code and Cursor as native plugins. From the moment a hook is active, every prompt submission, tool call, and model response is captured as a structured event.

This gives security teams:

• A complete record of every agent session across every developer and model provider
• Visibility into which MCP servers are active and what tools they are calling
• The ability to enforce policy before a prompt is submitted or a tool call is made

MCP gateway for tool-call governance

An agent with access to a production database through an MCP server and no gateway in front of it has full credentials and no audit trail. The Speakeasy MCP gateway sits between every agent and every tool it can reach, and handles:

• Authenticating the calling agent before forwarding any tool call
• Enforcing tool-level access policy
• Provisioning credentials just-in-time rather than storing them in agent configs
• Logging every call with its arguments and result

MCP servers that were previously managed per-developer are registered once in the control plane and governed from that point forward.

Shared identity foundation

Both layers operate on the same identity. Every tool call is attributable to a specific user and agent rather than an anonymous process. That attribution is what makes the audit trail actionable across the full five-layer stack.

For organizations working through the five-layer framework, ungoverned tool calls are almost always the most urgent gap. The MCP gateway is the right starting point.