AI Security: what it actually means, and what actually works

What is AI security?

AI security is the practice of protecting artificial intelligence systems, the data they consume and produce, and the organisation that depends on them. It covers three distinct problems that are routinely confused: securing the AI you build, securing the AI your people use, and defending against AI used by attackers. Most enterprise programmes address only one and assume they have covered all three.

That confusion is not academic. It determines who owns the budget, which tools get bought, and whether anything is actually safer at the end of it. So before anything else, separate the three:

If a vendor, a consultant or an internal proposal says “AI security” without saying which of those three it means, you are not yet having a technical conversation. You are having a procurement one.

Robin Johns, Worldwide AI SME, Cato Networks

Why is securing AI different from securing normal software?

Because the boundary between instructions and data collapses. In conventional software, code is code and input is input, and the whole discipline of application security rests on keeping them apart. A large language model reads everything as one stream of text, so any content it ingests — a document, a web page, an email, a tool response — can behave like an instruction.

Four consequences follow from that one property, and they explain nearly every AI-specific vulnerability class you will read about:

1. Input is untrusted in places you did not expect. A retrieval-augmented system that ingests a poisoned document has effectively let an attacker write part of its prompt.
2. Behaviour is probabilistic, so testing is statistical. You cannot prove a model will never do something with a unit test. You can only reduce likelihood and constrain blast radius — which makes containment more important than prevention.
3. Capability is granted, not coded. Give an agent a tool and you have given it a permission, not a feature. Excessive agency is the AI-era version of over-privileged service accounts, and it fails the same way.
4. The supply chain is opaque. Weights, fine-tunes, embeddings, plug-ins and MCP servers arrive with far less provenance than a signed package from a well-run registry.

None of that makes existing security irrelevant. Identity, least privilege, segmentation, logging, egress control and data classification all still apply — they simply have to be applied to a new kind of participant in the network, one that reads, decides and acts.

What are the main AI security threats?

The dominant enterprise AI threats are prompt injection (direct and indirect), sensitive data disclosure, shadow AI, excessive agency in agentic systems, supply-chain and model poisoning, insecure output handling, and unbounded consumption. The OWASP Top 10 for Large Language Model Applications is the most widely used public taxonomy for these.

Prompt injection

The signature AI vulnerability. Direct injection is a user talking the model out of its instructions. Indirect injection is far more dangerous: hostile instructions hidden inside content the model retrieves — a web page, a PDF, a calendar invite, a support ticket, a code comment. The user never sees it; the model obeys it. There is no known complete fix. Treat it the way you treat social engineering of a human employee: reduce what a successful attempt can reach.

Sensitive information disclosure

Two directions. Out: employees pasting customer data, source code, deal terms or unreleased financials into consumer AI tools. Back: a model or retrieval index surfacing data to a user who should never have seen it, usually because the RAG layer inherited the permissions of a service account rather than the permissions of the person asking.

Shadow AI

The most common finding in any first assessment, and the one that most often surprises the board. Employees adopt AI tools faster than any approval process can move, so the real question is never “should we allow AI?” but “which forty tools are already in use, by whom, and with what data?” Blocking alone reliably makes this worse: it pushes usage onto personal devices and personal accounts, where you have no visibility at all.

Excessive agency

An agent with a broad tool belt, standing credentials and no human checkpoint is an insider threat that never sleeps and cannot be interviewed. The failure mode is rarely a rogue model; it is a confused one, acting with permissions far wider than the task required.

Supply chain and data poisoning

Fine-tuned weights from an unverified source, a compromised dependency in an inference stack, a third-party MCP server, or a training or retrieval corpus an attacker can write to. Provenance is weak across the whole ecosystem, and few organisations maintain an AI bill of materials.

Insecure output handling

Treating model output as trusted input to something else — a shell, a SQL statement, a browser, a downstream API. This is a classic injection bug wearing a new hat, and it is the most avoidable item on the list.

Unbounded consumption

Denial of wallet. Inference is metered, so an unauthenticated or unthrottled endpoint is a direct line to your budget as well as your availability.

What controls actually work for AI security?

The controls that work are the ones that assume the model will eventually be manipulated: constrain what it can reach, inspect what leaves, scope permissions to the human, not the service account, keep a human in the loop for consequential actions, and log everything as a security event. Guardrails on the prompt are useful; they are not a control boundary.

1. Get visibility before you get a policy

You cannot govern what you cannot see. Discovery of AI usage — which applications, which users, which data, on which devices and networks — has to come first. In most organisations this is a network and egress problem before it is an application problem, which is why it tends to land with the team that already owns web and cloud access control.

2. Enable a sanctioned path, then steer traffic to it

Every successful programme I have seen offers people a good, fast, approved way to use AI, and then makes that path the easiest one. Pure prohibition has a near-perfect record of failure. Steering — allow the sanctioned tool, coach on the unsanctioned one, block only the genuinely hostile — changes behaviour where blocking does not.

3. Apply data controls at the point of use

Data loss prevention needs to understand AI destinations and AI-shaped interactions: prompts, file uploads, pasted content, API calls. Inline inspection of traffic to AI services, with policies that differ by data class and by user, is the control that stops the most common real incident — which is not an exotic model attack, but somebody pasting something they should not have.

4. Scope retrieval to the asking user

If your RAG index runs on a service account with broad access, your chatbot is a permissions laundering machine. Propagate the requesting user’s identity and entitlements through to retrieval, and re-check them at answer time rather than at index time.

5. Constrain agents like you constrain service accounts

• Least privilege per tool, not per agent.
• Short-lived, scoped credentials — never standing keys.
• Human approval gates on actions that move money, change access, delete data or talk to customers.
• Egress allow-lists so a compromised agent cannot phone home.
• Full audit trail of tool calls, not just conversations.

6. Test adversarially, and keep testing

AI red-teaming is not a one-off gate before launch. Model versions change under you, prompts get edited, retrieval corpora grow, and new jailbreak families appear monthly. Continuous adversarial testing — with results fed back into policy and guardrails — is the only honest way to hold a risk position over time.

7. Log AI interactions as security telemetry

Prompts, retrievals, tool calls, outputs and refusals belong in the same place as your other security events, with the same retention and the same detection engineering attention. Most organisations discover the gap during an incident, which is the worst possible moment.

Where does SASE fit into AI security?

SASE is where the enforcement point already sits. Because most enterprise AI usage is traffic to a cloud service, a converged SASE platform is the natural place to discover AI applications, apply identity-aware access policy, inspect prompts and uploads with DLP, and log every AI interaction — without deploying a separate agent for every new AI tool.

This is not an argument that SASE solves AI security. It does not touch model behaviour, agent permissions or supply-chain provenance. But three of the seven controls above — visibility, steering, and data control at the point of use — are network-and-identity problems, and a converged platform gives you one policy and one log for all of them.

• Discovery of shadow AI via cloud application visibility on egress traffic.
• Access policy per user, per tool — allow the sanctioned assistant, coach on the risky one, block the hostile one — enforced by identity rather than by IP.
• Inline DLP on prompts, uploads and API traffic to AI destinations.
• ZTNA for internal AI applications, so an internal copilot is not simply reachable by anything already on the network.
• Unified logging across every user, device and location without backhauling.

If you want the architecture underneath that, start with SASE explained.

How should an enterprise govern AI?

Effective AI governance is thin, fast and enforced in the toolchain rather than in a document. It needs an inventory of AI systems and their data, a risk tier per use case, a named owner per system, a lightweight approval route that is faster than going around it, and evidence collection that happens automatically. NIST AI RMF and ISO/IEC 42001 are the usual reference frames; the EU AI Act is the usual regulatory driver.

The failure mode of AI governance is not laxity. It is friction: a review board that takes six weeks produces shadow AI, not safety. Design the approved route to be genuinely faster than the unapproved one and most of the problem solves itself.

NIST AI Risk Management Framework (AI RMF 1.0)

Voluntary US framework organised around four functions — Govern, Map, Measure, Manage. The most practical starting structure for a programme that has to be built from nothing.

ISO/IEC 42001

The certifiable AI management system standard. Useful when you need to demonstrate governance to customers, auditors or procurement rather than only to yourselves.

EU AI Act

Risk-tiered regulation with obligations phasing in over several years, reaching general-purpose AI models and high-risk systems. If you operate in or sell into the EU, your classification work starts here — and it starts with an inventory you probably do not yet have.

OWASP Top 10 for LLM Applications

The working engineer’s list. Best used as a test plan rather than a policy document.

Whatever framework you adopt, three artefacts do most of the real work: an AI system inventory, a data-flow map per system, and a named accountable owner. Organisations that have those three can answer a regulator, a customer and an incident. Organisations with a forty-page policy and none of the three cannot.

How do you start an AI security programme in 90 days?

Start with discovery, not policy. In the first 30 days find out what AI is already in use and what data is reaching it. In the next 30, stand up a sanctioned path and put data controls in front of it. In the final 30, extend the same controls to agents and internal AI applications, and start testing adversarially.

Notice what is not in there: choosing a model, writing a forty-page standard, or forming a committee. Those are not wrong, they are just not first — and programmes that start with them typically reach day 90 with excellent documentation and no idea what their people are doing.

The five most common AI security mistakes

Blocking instead of steering; writing policy before doing discovery; treating prompt guardrails as a security boundary; giving agents standing credentials; and testing once instead of continuously. Every one of them is a governance mistake rather than a technical one, which is why buying a product rarely fixes them.

1. Blanket blocking. Drives usage to personal devices and personal accounts, and converts a visible risk into an invisible one.
2. Policy before discovery. Writing rules for a landscape you have not surveyed produces a document that describes an organisation you do not have.
3. Mistaking guardrails for controls. System prompts and content filters reduce the rate of bad outcomes. They do not bound them. Never let a guardrail be the only thing between a model and a production system.
4. Standing credentials for agents. The single highest-severity design error in most agentic deployments, and the easiest to fix before launch.
5. One-off assurance. A model version bump can invalidate your entire test result and nobody will send you a changelog.

Frequently asked questions