Version 1.1. Eleven categories. Standards mappings are to OWASP AISVS 1.01, MITRE ATLAS 5.6.0 and CWE. The categories are a review framework, not a severity ranking.
What inference security is
Inference is the part of an AI system that runs a trained model to answer requests: the servers, caches, schedulers, gateways and model loaders between a user's prompt and the model's reply. Inference security is stopping those parts from leaking, corrupting or running things they should not, especially when many customers share them.
It is not about whether a model says something harmful, and it is not about training data. It is about the systems around the model.
Three ideas that explain most of it
Speed features become security boundaries
Caches, batching and scheduling were built to be fast. In a shared deployment they decide who can see whose data, although nobody designed them as access control.
The internal network is large
A serving cluster splits work across many processes and machines that talk to each other, often with no login, on the assumption that the network is trusted.
Failures look like success
Many of these bugs return a normal answer with no error. A leaked or corrupted response looks the same as a good one unless you check what is in it.
Who the attacker is
Each category names the attacker it assumes. Some failures need none: a rejected request that still reads another customer's data is an engine bug, not an attack.
| Label | Attacker | What they can do |
|---|---|---|
| A1 | Remote, unauthenticated | Reach exposed routes and measure response timing |
| A2 | Authenticated tenant | Send chosen prompts, use permitted artifacts, observe service behavior |
| A3 | Internal workload | Has a foothold in one pod and can reach cluster-local services |
| A4 | Artifact supplier | Influences a model, adapter, tokenizer, media or dataset input |
| A5 | Control-plane | Holds a compromised service account or bypasses admission policy |
How to use this reference
- Pick the category that matches your question from the table below.
- Read the plain explanation and the evidence level. An incident, an advisory and a design risk are different strengths of proof.
- Work through the checklist, then run the tests. Each test must be able to fail, or it proves nothing.
The eleven categories
| ID | Category | Evidence | Impact |
|---|---|---|---|
| INF01 | Cache identity that fails to bind security context | Advisory-backed | C and I |
| INF02 | Unauthenticated internal control and data planes | Incident-backed | C, I and A |
| INF03 | Self-asserted peer and tenant identity | Architectural | C and I |
| INF04 | Host and accelerator memory isolation failure | Advisory-backed | C |
| INF05 | Observable cache behavior as a side channel | Advisory-backed | C |
| INF06 | Routing metadata treated as trusted input | Advisory-backed | C, I and A |
| INF07 | Artifacts and configuration as executable input | Incident-backed | C, I and A |
| INF08 | Artifact path resolution outside the intended root | Advisory-backed | I and C |
| INF09 | Control-plane over-privilege | Incident-backed | C, I and A |
| INF10 | Silent removal of a configured control | Architectural | C and I |
| INF11 | Request state that outlives its owner | Incident-backed | C and I, some A |
Evidence levels
| Label | Standard |
|---|---|
| Incident-backed | A public exploitation report, confirmed production compromise or operator postmortem, with a primary source. |
| Advisory-backed | A CVE, vendor advisory or maintainer-confirmed vulnerability, without a known exploited incident. |
| Architectural | Follows from the design and is supported by research or vendor guidance, without a public implementation-specific finding. |