What Does “AI Security” Actually Mean?

How this started…

These days when I speak to an organisation about their AI security policy, what I hear back (much too often) is that they have an acceptable use…

How this started…

These days when I speak to an organisation about their AI security policy, what I hear back (much too often) is that they have an acceptable use document calling out what can and can't be uploaded into public Generative AI LLMs (like ChatGPT or Claude). Mic drop. Silence. Blank stares.

Well yes that's a real policy addressing a real risk. But… it's not an "AI security policy"… and the distance between those two things is where a lot of budget is currently going missing.

So let's kick this series off and define our terms shall we… …

"AI security" — this phrase actually covers four (yes four) s_eparate_ d_isciplines_ …

Different owners. Different skills. Different evidence. And even different regulators.

Collapse them into a single line and you get organisations approving AI security investment without anyone able to work out afterwards what it bought. Can you relate?

So, breaking these four disciplilnes down…

1. Securing AI systems

This is where your AI estate is an attack surface. This includes: data pipelines, training environments, model artifacts, inference endpoints, the tool & connector layer and agents that hold credentials and take actions without a "human in the loop" (more on that later in this series).

The question here is: "can the system be compromised?" This is the question that belongs to the CISO.

This is the discipline most people think they mean when they say AI security. In my experience it's also the one with the least resourcing attached, because it's the only one of the four that requires you to have an inventory first.

2. AI for security

This is using AI in defence. This includes: alert triage, detection engineering, investigation support and response automation.

The question here is: "does it make the security function faster or cheaper?" This is the question that security operations owns, and it shares nothing with the first discipline except the acronym of AI.

Here's the rub: a vendor selling you an AI-powered SOC is not selling you anything that reduces your AI risk. And procurement conflates the two constantly.

3. AI safety

This is whether the model behaves. This includes: harmful output, unpredictable failure, doing things it was never meant to do and refusing things it was meant to.

Some of this you inherit from the LLM provider. Some of it becomes yours the moment you fine-tune or ground the model in your own data… or… let it act.

This part usually sits with product or engineering. Security teams are typically least equipped to assess this one and often do not realise they have been handed it.

4. AI governance

This includes: fairness, transparency, explainability, contestability, human oversight and the regulatory obligations attached to each.

The question here is: "can you justify an automated decision to a customer, a court or a supervisor?" Risk, legal and compliance own this question.

This is the discipline that has the most published material and the most standards attached to it, which is part of why it gets mistaken for the whole field.

The diagnostic

If your "AI security program" is a staff usage policy and a procurement questionnaire, you bought governance. If it's a gateway product, you bought a slice of the first discipline and none of the other three. And neither is a mistake on their own. Both become one the moment they reach a board and are described as AI security without qualification, because the board then believes a question has been answered that nobody has asked yet.

It's worth calling out that the Australian government drew this line a couple of years before most enterprises did. Just review ASD's Australian Cyber Security Centre Engaging with Artificial Intelligence, published in January 2024, and developed with CISA, the FBI, the NSA and the UK's NCSC, among others. Note the scoping: it addresses using AI systems securely, and points anyone building AI systems to a separate publication — the joint Guidelines for secure AI system development. Each of these two documents addresses a different problem. ASD followed this up with an AI Data Security information sheet in May 2025 and Principles for the secure integration of AI in Operational Technology in December 2025, with each one narrowing further.

So while the national cyber authority has been careful about scope since the beginning, most of the enterprises reading its guidance have not been.

Where the four disciplines converge

There is one place all four meet (and this is the reason that this series exists):

.. ahh the production of evidence that a stated risk is managed to a stated tolerance, signed by someone who can be held to it. Every one of the four disciplines above eventually has to produce that evidence. Securing the estate has to demonstrate the controls work. Defensive AI has to demonstrate the automation did not make things worse. Safety has to demonstrate the model behaves inside a defined envelope. Governance has to demonstrate the decision can be explained and contested.

And… APRA named assurance explicitly in its 30 April 2026 letter to industry, as one of four themes where practice is not keeping pace with AI adoption. Yes that's the word the supervisor used. And not in a way that's a synonym for testing or audit. And I will take that apart properly later in the series too.

For now, here's my practical instruction…

1. Before you write an AI security strategy, name which of the four you own.
2. Write it down, and write down who owns the other three.
3. If you cannot fill in all four names, you have found the actual finding… and it is a governance gap rather than a technical one.

A note on sources for this series. Every figure I cite will link to a primary source. There is a large amount of AI security statistics in circulation that trace back to three vendor blogs that then trace back to a report that turns out not to exist any more (or ever). Rather than echo those further, I strive for quality over quantity.

Originally published at https://www.satheeshan.com on August 9, 2026.