The Seven Layers of AI Security Risk (And Why You Cannot Solve Them With One Tool)

When an organisation tells me they have addressed their AI security risk, my first question is: which layer?

The question sounds pedantic. It is not. The AI security market has produced a range of tools and services, most of which are excellent at what they do and incomplete as a total programme. A model monitoring platform that tracks output distribution drift is solving a real problem at the model behaviour layer. It tells you nothing about whether your scaffolding is vulnerable to prompt injection, whether your training data was poisoned before you ever loaded it, or whether your governance structure would detect an AI-enabled fraud scheme operating within the outputs your system is generating.

The reason the question matters is that AI systems are not monolithic. They have structure. That structure has distinct attack surfaces, distinct failure modes, and distinct mitigation approaches at each layer. A single tool, however capable, is solving for some of those layers and not others. An organisation that has bought tool coverage at one layer and assumed general coverage across all of them has a gap they are not aware of.

The Seven Layers

We treat AI security as a seven-layer problem:

1. Dataset integrity. The training and fine-tuning data the model learned from. If that data was poisoned, biased, or selectively curated, the model's behaviour reflects it in ways that are difficult to detect from the outside. This layer is relevant to any organisation that fine-tunes a base model on proprietary data, uses a model trained on data they do not control, or incorporates retrieval-augmented generation from a corpus that can be influenced by external parties.

2. Model behaviour. What the model does with inputs. Adversarial robustness, jailbreak resistance, alignment with intended use, and resistance to manipulation are all tested at this layer. This is the layer most AI security tools focus on — and the layer where most published research on AI safety concentrates. It is necessary but not sufficient.

3. Scaffolding and application architecture. The system built around the model. Retrieval-augmented generation pipelines, tool-use capabilities, API integrations, memory systems, and the prompting logic that mediates between user and model are all attack surfaces distinct from the model itself. This is where most real-world exploits land in production AI systems.

4. Human-in-the-loop oversight. Whether and how humans are in a position to detect and intercept AI failures. Many systems marketed as having HITL oversight have checkpoints that do not engage at the speed or depth that adversarial conditions require. If a human is reviewing outputs but can only sample a fraction of them, the review is not catching what a systematic attacker is doing.

5. Governance. Policies, accountability, audit trails, and response procedures for AI failures. The absence of governance does not cause immediate failures. It determines whether failures are detected, attributed, and corrected. An AI system producing harmful outputs that nobody is responsible for detecting and stopping is a governance failure, not a model failure.

6. Exploitability. How findings across the other layers can be chained to produce outcomes that matter to an attacker. A dataset integrity issue that affects a low-stakes classification task may be benign in isolation and critical when combined with a scaffolding vulnerability that surfaces the output in a privileged context. Exploitability is the layer that connects individual findings to real-world consequences.

7. Privacy. How the model and system handle personal data, including the risk of training data extraction, membership inference, and data leakage through model outputs. This layer is particularly relevant for organisations operating under the Privacy Act, the My Health Records Act, or comparable data protection regimes, where AI-generated outputs could inadvertently surface personal information the system should not have retained or disclosed.

Why Tools Optimised for One Layer Create False Confidence About the Others

A tool that monitors model output for policy violations is working at layer 2. It does not observe the scaffolding inputs that produced those outputs (layer 3), the training data that shaped the model's response patterns (layer 1), or the human oversight gaps that allowed the output to reach an end-user without review (layer 4).

This matters for how you buy and deploy AI security services. If you have purchased a guardrail tool and you believe you have addressed AI security, you have addressed model behaviour under known attack patterns — which is a meaningful but partial coverage. The scaffolding layer, the governance layer, and the privacy layer are still exposed.

The layers interact. A scaffolding vulnerability that allows indirect prompt injection can be used to trigger model behaviour that leaks training data (layers 3, 2, and 7 in sequence). A governance gap that prevents incident detection allows an exploitability chain to operate undetected (layers 5 and 6). Testing any single layer in isolation understates the real risk.

What a Multi-Layer Assessment Looks Like

A properly structured AI security assessment covers all seven layers and produces a coverage matrix: what was assessed at each layer, what attack categories were exercised, and what findings were identified. Findings are mapped to layers and to exploitability chains — showing not just what is vulnerable individually, but what an attacker could achieve by chaining vulnerabilities across layers.

The assessment output is distinct from a network penetration test report. Rather than CVEs with CVSS scores, the report covers attack categories exercised, model and scaffolding behaviours observed, exploitability pathways identified, and remediation prioritised by business risk and exploitability — with explicit mapping to governance and policy gaps at layer 5.

How ISO 42001 and the NIST AI RMF Map to the Layers

ISO/IEC 42001:2023 (the AI management system standard) addresses layers 5 and 7 most directly: the governance structures, AI risk management policies, and data handling obligations that organisations must demonstrate. The standard's Measure and Govern functions require that organisations not only have policies but that they have tested their AI systems against a defined risk model and maintain audit trails of that testing.

The NIST AI Risk Management Framework addresses all seven layers through its four core functions: Govern (layer 5), Map (layers 1, 6, and 7), Measure (layers 2, 3, and 4), and Manage (ongoing treatment across all layers). Organisations using the NIST AI RMF as their governance anchor can use the seven-layer model as a measurement instrument: a structured way to assess coverage against the Measure function's requirements.

For organisations that need to demonstrate AI security assurance to clients, regulators, or procurement committees — whether under the APRA AI guidance, the Australian Government's Voluntary AI Safety Standard, or enterprise vendor questionnaires — a seven-layer assessment provides the documented evidence base that a single-tool deployment does not.

To discuss an AI security assessment for your organisation, contact Cyberlinx at info@cyberlinx.com.au.