The AI attack surface: in 9 layers

Most published AI attack surface maps today are drawn by vendors. And it shows because these maps typically stop around the inference endpoint.

Everything above that… the tools an agent can call, the actions it takes, the humans approving those actions… either isn’t shown or is grouped into a single box labelled the “application layer”.

Yet that is where incidents have happened during 2026.

So I’m introducing this reference map for the rest of this series, so we have a common view to speak to. It has nine layers, read from bottom to top:

For each layer we look at the same three questions:

1. What it is
2. What an attacker gets from it
3. Who in your organisation owns it today

That third question is the one that really matters first. Because every layer is technically securable. But the layers that get breached are typically the ones where the answer to “who owns this” is met with silence.

Now diving deeper…

Layers 1 to 4: build

Layer 1: Compute and hardware.

1. The GPU estate, its tenancy model, and its physical and supply chain integrity.
2. An attacker at this layer gets everything above it, which is why it is also the layer with the most mature existing controls.
3. Owned by infrastructure. Typically fine in most enterprises.

Layer 2: Data pipeline.

1. Ingestion through cleaning, transformation, staging, storage and serving.
2. An attacker who reaches training or grounding data gets to shape model behaviour without ever touching the model. Poisoning is the obvious case; less so is simply reading data that was aggregated for training and never re-classified.
3. Owned by data engineering.

Layer 3: Training environment.

1. Orchestration, dependencies and build process.
2. This is a software supply chain problem in a different light, and the controls that work are the ones already known there.
3. Owned by data science – usually without security engagement, making this a remediation finding.

Layer 4: Model artifacts.

1. Weights, adapters, configs and checkpoints.
2. An attacker gets theft, tampering or a backdoor that survives every downstream control you apply. Most organisations cannot tell you where their model artifacts are stored, who can write to that location or whether the model running in production is the one that was approved.
3. Nominally owned by data science, but effectively unowned.

Layers 5 to 6: serve

Layer 5: Deployment infrastructure.

1. Containers, endpoints, secrets, configuration.
2. Standard cloud security, applied to a workload type with unusual dependency patterns and an unusual rate of change.
3. Owned by platform engineering, and mostly done reasonably well.

Layer 6: Inference runtime.

1. The live request path.
2. Adversarial inputs, extraction, inversion, membership inference. Also the point where a model that behaves in testing behaves differently against real traffic. Owned by platform engineering, at least in name.
3. In practice, nobody monitors it the way they monitor an API, because the thing being monitored is non-deterministic and the existing tooling assumes it isn’t.

Layers 7 to 9: act

This is where the map stops being a redrawing of the cloud security stack.

Layer 7: Tool and connector layer.

1. Model Context Protocol servers, function definitions, agent-to-agent interfaces, the plugins and integrations that give a model the ability to do rather than say.
2. An attacker who compromises a tool definition doesn’t need to compromise the model at all. The model will faithfully call the poisoned tool because calling tools is what it was built to do.
3. No owner – ask different teams who approved the connector list and you will get different answers, none of them being “we did”.

Layer 8: Agent layer.

1. Planning, memory, autonomy, credentials.
2. An agent holds access, makes decisions, and acts across systems on a schedule nobody is watching. Compromise here looks less like an intrusion and more like an insider who was hired without a background check and given admin rights on day one.
3. Also no owner – and this is the layer where that impacts the most.

Layer 9: Human and process layer.

1. Approval workflows, oversight and the shadow AI running outside all of it.
2. An attacker’s best result at this layer is a human clicking approve on an action they did not understand, which happens because approval fatigue is real and because a confident explanation from an agent is indistinguishable from a correct one.
3. Owned by security and risk, though only the portion of it they can see – which is why shadow AI sits here rather than in a box of its own.

The gap

As above, from what I’ve seen, Layers 7 and 8 have no owner in most Australian enterprises. I’m not talking a dotted line owner, nor a partial owner. I’m talking no owner. Security doesn’t own them because they weren’t in the architecture review. Platform engineering doesn’t own them because they arrived as a feature of a SaaS product. Data science doesn’t own them because they aren’t model concerns.

Meanwhile the state of play has evolved. The OWASP GenAI Security Project published State of Agentic AI Security and Governance v2.01 on 1 June 2026, updating a first edition from July 2025. The framing shift between the two is worth looking at: the 2025 report catalogued plausible threats, and in the 2026 report almost every one of those categories has a CVE, a vendor advisory or a production incident attached to it. The report’s co-leads note that the supply chain and code execution categories are tied for the highest volume of disclosed incidents, and that an audit nicknamed IDEsaster found vulnerabilities in every major AI coding environment it tested.

Both of those categories live at layers 7 and 8.

One nuance worth introducing

In the previous post I separated AI security from AI safety and argued they have different owners. The 2026 OWASP report makes a case that puts a nuance to this viewpoint.

Its framing is that safety and security converge at the deployment layer. Model-level safety stays with the provider. But once an agent is acting on production systems, the same controls govern both kinds of harm and the same investigation surfaces both kinds of cause. The report contrasts the Replit production database deletion with the Cursor allowlist bypass – one had no adversary and one required one, but the permission surface that let each happen was the same.

Though I conceptualise the four disciplines are distinct as disciplines, the nuance is that they stop being distinct in practice at layer 7. Above that line, an agent deleting a database because it was tricked and an agent deleting a database because it reasoned badly produce identical incidents, identical evidence, and identical questions from a supervisor.

How to use this layer map

For each layer, if you can fill in a name for a person who could be called at 2:00am and would answer, you are ahead of most of the market and the rest of this series will be about depth rather than coverage.

If you get to layer 6 and stall, you have located your program’s actual boundary, and it sits directly underneath the part of your AI estate that can take actions in production.

Next in this series: why the control library you already have covers layers 1 through 5 better than you think, and fails at 7 through 9 in ways that are not obvious until you test them.