Why AI is a new security domain

The five things that are genuinely different

If you have been doing information security for a while, your first encounter with AI security probably went one of two ways. Either the AI people described things you already knew using new vocabulary, or they described things that did not fit any of the categories you knew. The first kind is exhausting; the second kind is the part of the field that actually requires new thinking.

There are, in my experience, five things that are genuinely new about securing AI systems. Everything else is traditional security with an AI flavour.

1. Natural language is the attack surface. In traditional systems, attackers exploit code, configuration, or network paths. In AI systems, the attacker can also write English, paste it into an input box, and change the system's behaviour. Prompt injection has no equivalent in pre-LLM systems. Input validation as we previously understood it does not catch it.

2. The model is stochastic. Given the same input, the same system will sometimes do different things. This is not a bug; it is how language models work. Traditional security controls assume deterministic behaviour — given input X, the system always does Y. AI controls have to handle a distribution of outputs. Your test cases will pass and the production behaviour will still surprise you.

3. The data that trained the model is part of the supply chain. A model trained on poisoned data is a permanently compromised model. You cannot patch a model the way you patch software. If a malicious sample was in the training set, the behaviour it induced is baked in. This makes provenance of training data a security concern, not just a data-management concern.

4. Agents amplify the blast radius. A traditional vulnerability in a system might allow an attacker to read data or run code on that one system. An agent with tools — search, file write, API access, payments — turns a single successful prompt injection into the agent doing whatever the agent can do, in your name. The privilege you grant the agent becomes the privilege you grant the attacker.

5. The economic incentives have not caught up. Traditional security has decades of insurance, regulation, certification, and case law to lean on. AI security has roughly two years. Many of the controls you would want to insist on do not have audit standards. Many of the products that promise them do not work. The market is immature in a way that has implications for how you procure and govern.

If a single one of these is new to you, the rest of this course will be useful. If all of them are familiar, you may already be operating well in this space — but the second half of this lesson, on the framework landscape, will still be a useful map.

What is not new (and the trap of treating it as new)

The opposite mistake is treating every AI security topic as a fresh problem. Most of it is not.

Authentication and authorisation for AI systems work the same as for any other system. The principles of least privilege, defence in depth, and separation of duties apply directly. Identity and access management is identity and access management.

Logging, monitoring, and incident response are not fundamentally different. You log what the model did, the same way you log what any other component did. You alert on anomalies. You have runbooks.

Vendor risk management is vendor risk management. The provider of your LLM API is a third party. The vendor due-diligence questions you would ask any major cloud vendor apply, with a few AI-specific additions (training-data provenance, model versioning policy, content filter behaviour).

The trap is when an organisation declares AI security a new discipline and rebuilds half its security programme on first principles when nothing was wrong with the principles. The right approach is to identify what is genuinely new (the five points above), and apply existing security disciplines to the rest.

The framework landscape

You do not have to invent the response to AI security. Several frameworks already exist and have converged enough that you can pick one as your spine and refer to the others where they add value. Here are the ones that matter, with brief notes on each.

MITRE ATLAS. The Adversarial Threat Landscape for AI Systems. The closest equivalent to MITRE ATT&CK for AI. Catalogues tactics, techniques, and case studies of real attacks on AI systems. The right starting point for threat modelling and red-teaming. Free. We cover this in Lesson 3.

OWASP Top 10 for Large Language Model Applications. A community-maintained list of the most common LLM application vulnerabilities. Currently in its 2025 revision. The right starting point for understanding what tends to go wrong, with examples and mitigations. Free. We cover this in Lesson 2.

NIST AI Risk Management Framework (AI RMF 1.0, plus the 2024 Generative AI Profile). A US framework for managing AI risk across the lifecycle. Voluntary but increasingly cited by US regulators. Risk-focused, suitable for board-level documentation. The Generative AI Profile is particularly useful for organisations deploying LLMs.

ISO 42001. The 2023 international standard for AI management systems. Modelled on ISO 27001 (information security management) and 9001 (quality). Certifiable. Useful when you need to demonstrate to customers, regulators, or auditors that you have systematic AI governance. Many organisations are heading toward ISO 42001 certification through 2026 and 2027.

EU AI Act. The Act came into force in August 2024 and is rolling out in stages through 2026 and 2027. Classifies AI systems by risk tier (prohibited, high-risk, limited risk, minimal risk) and imposes specific obligations on each. High-risk classification — which covers a lot of financial, healthcare, employment, and critical-infrastructure AI — brings substantial documentation, monitoring, and human-oversight requirements. We cover the Act in detail in Lesson 5.

Sectoral frameworks. DORA for EU financial services (in force since January 2025) and NIS2 for EU critical infrastructure both contain specific provisions for ICT third-party risk and resilience that apply to AI vendors. If you are in scope of either, your AI risk register has to talk to your DORA or NIS2 register.

If you are starting from scratch, the practical sequence is: OWASP for vulnerability awareness, MITRE ATLAS for threat modelling, NIST AI RMF for risk management documentation, ISO 42001 if you need a certifiable management system, and the EU AI Act if you operate in Europe or sell to European customers.

The blast-radius problem in agentic AI

The most consequential idea in AI security in 2026 is also the simplest. We covered it briefly in the AI Agent free course; here is the security-specific version.

A traditional vulnerability in a single application has a bounded blast radius. The attacker can read what that application can read, write what that application can write, and reach what that application can reach. Network segmentation, identity boundaries, and the principle of least privilege limit the damage.

An agent extends that blast radius dramatically. An agent that can read a webpage, send an email, and call an API has the combined blast radius of all three. If an attacker can compromise the agent — most commonly through prompt injection in the content the agent reads — the attacker can use any tool the agent has access to. The agent is the new perimeter.

The mitigation, which we will return to in Lesson 4, is that agents should follow the same principle of least privilege as every other identity in your environment. An agent that reads untrusted content should not also have the ability to send money, modify production data, or impersonate users. The tools available to a given agent should be the minimum set required for its task.

This sounds obvious. It is routinely violated by people who do not yet see agents as identities. The single most useful thing you can do as a security leader in 2026 is to insist, in your AI-system review process, that every agent be assigned a privilege budget — exactly like every other principal in your IAM model — and that the budget be as small as possible.

The honest position to take

A security leader in 2026 has to take a position on AI security in front of the board, the audit committee, and the regulators. The position that holds up to scrutiny — and that we will spend this course building toward — looks something like this.

"AI introduces new attack surfaces and amplifies the consequences of some traditional ones. The frameworks we need already exist, in immature but credible form. We are mapping our AI systems against the OWASP Top 10 for LLMs, threat-modelling them against MITRE ATLAS, applying defence-in-depth controls calibrated to each system's risk tier under the EU AI Act, and documenting the entire programme against NIST AI RMF. We treat agents as identities and assign them privileges accordingly. We red-team continuously rather than annually."

That paragraph is what good looks like. It is achievable. It is what the rest of this course teaches you to build.

Looking ahead

In Lesson 2 we work through the OWASP Top 10 for LLM Applications — the catalogue of vulnerabilities your AI systems are most likely to have. By the end of it, you will recognise these patterns when you see them in your own architecture review meetings.