Answer box
AI security is the discipline of protecting the models, prompts, agents, and data flows that make up your enterprise AI stack — across discovery, runtime inspection, policy enforcement, and audit. It's not a sub-branch of application security. It's a new control plane that sits on top of every app you've already shipped, every SaaS tool your employees touched this morning, and every agent your platform team is quietly piloting. If you're a CISO trying to answer the board's "are we safe with AI?" question, this is the surface you have to defend.
What changed when AI moved from feature to layer
Three years ago, AI was a product. A chatbot. A recommender. A fraud model. You could draw a box around it, threat-model it, and hand it to the application security team. Done.
That's over. AI is now a layer. It's inside your CRM (Einstein), your collaboration suite (Copilot), your dev tools (Cursor, Copilot), your support stack (Intercom Fin, Zendesk AI), and your data warehouse (every BI tool now ships a natural-language interface). Your employees are pasting customer data into ChatGPT during their commute. Your platform engineers are wiring agents to MCP servers that have write access to production databases. Your procurement team is approving SaaS vendors who silently added an LLM to their pipeline last sprint.
Traditional perimeter controls can't see this. A CASB sees the domain, not the payload. A DLP sees regex, not intent. A SIEM sees the API call, not the chain of tool invocations behind it. The Cloud Security Alliance's 2026 Shadow AI Agents Report found 79% of enterprises lack visibility into the AI agents already running inside their environment — and that's the agents IT knows about. The real number is worse.
So when we talk about enterprise AI security, we mean a stack of controls built for a world where AI is the medium, not the message. Different surface. Different threats. Different tooling.
The four layers of AI security
Every credible AI security framework eventually decomposes into four layers. Different vendors will use different names, but the shape is the same. Model. Prompt. Agent. Governance. Each needs its own control set because each has its own threat model.
Model layer
This is the model itself — weights, training data, fine-tuning artifacts, inference endpoints. Threats here include model theft, training-data poisoning, membership-inference attacks, and unauthorized fine-tuning.
- Provenance: where did the weights come from, who signed them, what's the SBOM-equivalent for the training corpus
- Integrity: hash-verified model serving, signed checkpoints, controlled fine-tuning pipelines
- Access: who can call the inference endpoint, with what quota, from what network
- Egress: can a model exfiltrate training data through carefully crafted prompts
If you're using a hosted model (Anthropic, OpenAI, Google), you've outsourced most of this — but you've also signed a contract that says you've done so. Your auditors will ask. Have the answer ready.
Prompt layer
This is the wire between your application and the model. Every user input, system prompt, retrieved document, and tool result that gets concatenated into a context window. It's also where most active attacks land.
- Inline inspection: every prompt and response screened for injection, sensitive data, jailbreaks, and policy violations
- Latency budget: this has to happen in single-digit milliseconds or your users route around it
- Redaction: PII, PHI, source code, customer records pulled before the model sees them
- Context isolation: untrusted retrieved content (a webpage, a PDF, an email) treated as untrusted
The prompt layer is the new HTTP. You inspect HTTP requests in real time. You'll inspect prompts in real time. The math is the same.
Agent layer
An agent is a model that's been given tools and a loop. The tools call APIs, query databases, send emails, write code, deploy infrastructure. The loop lets it chain steps. This is where AI security gets operational — and where it gets dangerous.
- Tool allowlisting: explicit list of MCP servers, functions, and APIs an agent can invoke
- Scoped credentials: agents authenticate as themselves, not as the user, with least-privilege roles
- Step budgets: hard caps on tool calls, recursion depth, and time per task
- Kill switches: a human-in-the-loop or automated trip that halts an agent mid-execution
- Provenance logging: every tool call, argument, response, and decision recorded for replay
Agents are the part of the stack that will make your incident-response team earn their salary. A real-world agent incident took nine seconds from "summarize the table" to a DROP TABLE on a production database. Kill switches aren't optional anymore.
Governance layer
This is the layer auditors care about. Policies, evidence, ownership, mapping to frameworks. Without it, the other three layers are just security theatre.
- Inventory: every model, every agent, every prompt template, every tool, mapped to an owner
- Policy: documented rules for what AI can do, with what data, on whose behalf
- Evidence: continuous logs that satisfy NIST AI RMF, ISO 42001, EU AI Act, and your sector regulator
- Identity: agents have identities, not borrowed credentials — non-human identity as we knew it is dead
The six biggest enterprise risks
This list isn't exhaustive. It's the six that show up in actual incident post-mortems and actual board questions in 2026.
Shadow AI
Employees use AI tools you didn't approve, didn't procure, and didn't security-review. The Cloud Security Alliance's 2026 report puts shadow AI agents at 79% prevalence across surveyed enterprises. Your sales rep pastes a deal-room call transcript into a free AI summarizer. Your developer wires Cursor to a repo containing customer PII. Your CFO uses an unvetted browser extension to summarize earnings calls.
Consequence: regulated data leaves your perimeter without a contract, a DPA, or a log. When the breach surfaces, you find out from a news article.
Data leakage to LLMs
Even approved AI tools become exfiltration channels. A well-meaning analyst pastes the customer churn export into Claude to "find patterns." A support engineer drops a stack trace containing API keys into a public model. Once that data hits an external inference endpoint, it's out — whether or not the vendor retains it.
Consequence: Ponemon's 2024 Cost of a Data Breach pegged the average breach at $4.88M; AI-mediated breaches skew higher because nobody knows what got sent.
Prompt injection
Attackers embed instructions in content the model later reads — a webpage, an email, a PDF, a comment in a Jira ticket. The model treats the instruction as authoritative and acts on it. OWASP's Top 10 for Agentic Applications 2026 lists prompt injection as the #1 risk for a reason. We've annotated each item for enterprise impact.
Consequence: your support agent reads a customer email, follows the hidden instruction inside it, and emails internal docs to the attacker. The agent's logs show "completed task." Your SIEM shows nothing.
Tool poisoning and supply chain
Agents call MCP servers. MCP servers are software. Software has dependencies. Dependencies get compromised. An attacker who poisons an MCP server you depend on now has a pipe into every agent in your fleet that uses it. This is the new npm-typosquatting, except the payload runs with agent privileges.
Consequence: a compromised "calendar" MCP server reads every meeting your assistant agents touch, including the M&A war room.
Agent goal hijack
An agent is given a goal. An attacker — through prompt injection, tool response manipulation, or a poisoned document — substitutes a different goal. The agent still feels like it's doing its job. It isn't. Goal hijack is harder to detect than prompt injection because the surface looks normal.
Consequence: the procurement agent quietly approves a fraudulent invoice because a PDF told it to. Finance signs off because the agent had authority.
Compliance and audit failure
You can have great controls and still fail an audit because you can't prove they ran. The EU AI Act, NIST AI RMF 1.0, and ISO/IEC 42001 all demand continuous evidence — not annual screenshots. If your AI controls don't emit machine-readable logs your GRC team can map to controls, you have a compliance problem regardless of your security posture.
Consequence: a regulator asks for evidence of agent decision-making during a specific 48-hour window six months ago. You don't have it. The fine writes itself.
What enterprise AI security must actually do
Strip away the marketing. An AI security program needs to do seven things, continuously, at production scale. Continuous discovery of AI usage — apps, models, agents, MCP servers — across managed and unmanaged surfaces. Inline inspection of every prompt and response at sub-50ms p99, because anything slower gets disabled by the platform team within a week. Tool allowlisting per agent, per role, per environment. Kill switches that actually halt running agents, not just revoke future calls. Provenance logging of every model call, tool invocation, and decision chain. Agent-to-agent (A2A) message signing so an agent can verify which agent it's talking to. And evidence packs auditors can drop into their SOC 2, ISO 42001, or EU AI Act workpapers without translation.
Most of your existing stack wasn't built for this. The table below shows where the gap is.
| Capability | Legacy security tools (CASB / DLP / SIEM / IAM) | AI-native security |
|---|---|---|
| Visibility | Domain and API endpoint — sees that ChatGPT was called, not what was sent | Discovers shadow AI, classifies models and agents, maps every tool call |
| Inspection | Regex on payloads, signature matching, file-type rules | Semantic inspection of prompts and responses, injection detection, intent classification |
| Policy | Allow/block by URL, user group, or file type | Per-agent tool allowlists, role-scoped data access, step budgets, context isolation |
| Audit | Authentication and access logs; little context on intent | Full decision-chain replay, signed provenance, framework-mapped evidence |
| Kill switch | Revoke credentials, block IP — takes minutes, doesn't stop in-flight work | Halts agent mid-step, quarantines state, preserves forensics, recovers in seconds |
You don't replace your CASB or your SIEM. You add the AI-native layer next to them and pipe its signals into the SOC you already run. The wrong move is treating AI security as a feature your incumbent vendor will ship next quarter. They won't, fast enough.
How to measure your AI security maturity
Five questions. Answer honestly. Score yourself out of five.
- Inventory. Can you, today, produce a list of every AI model, agent, and MCP server in use across your environment, with owners and data classifications? If the answer involves a spreadsheet maintained by one person, that's a zero.
- Inline controls. When a developer wires a new agent to a production database, does anything in your stack inspect the prompts and tool calls in real time? Or does it only show up in logs after the fact?
- Identity. Do your agents authenticate as themselves with scoped credentials, or do they piggyback on a human's session token?
- Kill switch. If you discovered a misbehaving agent right now, how many minutes until it's stopped, and is "stopped" reversible without losing forensic data?
- Evidence. Can you hand an auditor 90 days of AI control evidence — mapped to NIST AI RMF or ISO 42001 — without a 3-week project?
Fewer than three yes-answers means you're behind your peer group. For a deeper version of this self-check with benchmarks against industry, run the AI governance maturity assessment. If you want to translate the gap into dollars, the AI agent risk calculator estimates expected loss based on agent count, data sensitivity, and current controls.
What to do this quarter
Inventory first. You can't secure what you can't see. Run a discovery pass across SSO logs, expense reports for AI SaaS, browser telemetry, and your code repos for direct API calls to model providers. Aim for a complete list of AI surfaces and owners by end of month. Don't try to evaluate risk yet — just count.
Assessment next. Once you have the inventory, score each surface against your existing data classification policy. Customer PII flowing through an unvetted SaaS plugin is a different problem than a marketing team using Claude to rewrite blog posts. Prioritize by exposure, not by vendor logo. The maturity assessment linked above gives you a framework that maps to the four layers.
Policy and platform last. Now you can write a defensible AI acceptable-use policy (because you know what's actually being used) and pick a platform that enforces it inline. Don't reverse the order. A policy written before the inventory is a policy your engineering team will route around within two sprints.
FAQ
What's actually in scope for AI security?
Models, prompts, agents, tools, training data, retrieval corpora, and the governance wrapped around all of it. In practice: any system where an LLM or other model influences a decision, generates content, or invokes an action. That includes SaaS tools with embedded AI, internal apps calling external APIs, and agentic systems that chain tool calls.
How is AI security different from cybersecurity?
Cybersecurity defends networks, endpoints, identities, and applications against known and unknown adversaries. AI security defends the model-and-agent layer that now sits on top of all of those. They overlap — an agent uses a network, an identity, an endpoint — but the threats are different. Prompt injection isn't a network attack. Tool poisoning isn't a phishing attack. You need both stacks. AI security is additive.
Who owns AI security inside the org?
The CISO owns the program. In practice, it's a shared operating model: security engineering builds the controls, GRC owns the framework mapping and evidence, data/AI platform teams own the model and agent inventory, and legal owns vendor and data-flow contracts. The anti-pattern is making it the AI team's problem — they'll optimize for shipping, not for defensibility. The other anti-pattern is making it pure GRC — you'll get binders, not controls.
Which frameworks actually cover AI security?
Three matter most in 2026. NIST AI RMF 1.0 (plus the Generative AI Profile, NIST AI 600-1) gives you a voluntary, functions-based framework — Govern, Map, Measure, Manage — that maps cleanly to enterprise controls. ISO/IEC 42001:2023 is the certifiable AI management system standard; if you're already ISO 27001, this is the natural extension. EU AI Act is the regulatory hammer — risk-tiered, with real obligations for high-risk and general-purpose AI systems and enforcement ramping through 2026 and 2027. We maintain a crosswalk between all three so you're not maintaining three separate control sets.
Build or buy?
Buy the inline controls. Build the governance wrapper. The inline pieces — sub-50ms prompt inspection, agent runtime enforcement, tool-call provenance — are infrastructure problems that take years to get right and rapidly evolve as attack patterns shift. The governance wrapper — how AI security maps to your specific business processes, risk appetite, and regulator — is where your team's institutional knowledge wins. If a vendor pitches you a "complete" AI security program with no integration into your existing GRC, they're either naive or selling you something you won't use.
What budget category does AI security sit in?
Today, it's split across cybersecurity, GRC, and AI platform — which is why it's underfunded everywhere. The pragmatic move is to carve out a named AI security line in the security budget for FY26 planning, with a dotted line to data and AI platform spend. Anchor the request in concrete risk: number of agents in flight, data classifications they touch, expected loss from the agent risk calculator. Boards fund AI security when you frame it as protecting AI investment, not as another security tax.