Skip to content

L2.2.3 — Application, agent & supply-chain planes in depth

Type: Theory · Duration: ~5 min · Status: Mandatory Module: Module 2 — AI Security Foundations Framework tags: OWASP LLM02, LLM05, LLM08 · ATLAS AML.TA0011 (Impact), AML.T0010 (ML Supply Chain Compromise)

Learning objectives

  1. List four attack surfaces unique to the application plane, three unique to the agent layer, and three unique to the supply chain.
  2. Recognize that infrastructure-plane attacks are mostly classical infra security — and where the AI specifics are bolted on.

Core content

Application plane — four primary surfaces

  1. The user-input boundary. Where untrusted text first enters the system. Most prompt-injection defenses (input filters, length limits, schema-validated input) live here.
  2. Prompt template authoring. The static prompt scaffolding — system prompt, few-shot examples, persona definitions. Often the most leaked artifact in production. System-prompt extraction (OWASP LLM07) lives here.
  3. The output renderer. Whatever displays model output to the user — HTML renderer, markdown parser, voice synthesizer. Output handling vulnerabilities (XSS via LLM output, SSRF via auto-fetched URLs, SQL injection via formatted-string queries) live here. OWASP LLM02.
  4. The tool-call boundary (if agentic). Where model output triggers a tool invocation. Authorization decisions about which tools to expose, and with what arguments validation, live here.

Agent layer — three unique surfaces (subset of the application plane, important enough to call out)

  1. Tool definitions. What tools is the agent allowed to call? Over-broad tool surfaces are the canonical excessive-agency vulnerability. A "send_email" tool that accepts any recipient is a different beast than one restricted to the user's own address.

  2. Agent loop logic. Many agents have a plan-act-observe loop. An attacker who lands a single injection can plant goals that persist across loop iterations — plan-hijacking. Module 3 has a lab on this.

  3. Inter-agent communication (multi-agent systems). When agent A's output becomes agent B's input, agent B treats it as authoritative — even though A may have been compromised by an injection three hops back.

Supply chain plane — three primary surfaces

  1. Model weights. Any pre-trained or fine-tuned model you pull from a registry. Risk: weight files with malicious pickle payloads (Module 4 lab L4.8), backdoor triggers planted during training, model card lies about training data or evaluation results.

  2. Datasets. Training data, fine-tune data, eval data downloaded from HuggingFace / Kaggle / other registries. Risk: poisoned examples, label flips, embedded triggers.

  3. Libraries and frameworks. LangChain, the embedding-model library, the vector DB SDK, the agent framework, the inference runtime. Classical supply-chain risk plus AI-specific concerns (e.g., a vulnerable LangChain version that lets arbitrary code execute in a chain definition).

Infrastructure plane

Mostly classical infrasec — GPUs, containers, K8s, network, secret stores. The AI specifics are: - API keys for LLM providers are high-value targets (theft = unbounded compute spend). - GPU schedulers can be a side channel for model-extraction attacks against shared inference clusters. - Vector DBs are new infrastructure components with their own auth and isolation stories. Don't assume they have the maturity of Postgres.

The general rule: do classical infrasec first, then layer the AI specifics. If your infra plane has classical gaps, those will be exploited long before anyone bothers with AI-specific cleverness.

Real-world example

LangChain has shipped multiple CVEs (notably CVE-2023-29374 and successors) where chain-definition strings could trigger arbitrary code execution via insufficient sandboxing of expressions inside templates. This is a supply-chain attack: a defender using the library with default config inherits the vulnerability without any AI-specific mistake on their part. Module 4 covers SBOM and dependency review for the AI stack specifically.

Key terms

  • Tool-call boundary — the API surface between the model's output and the agent's tool invocation.
  • Plan-hijacking — agent-loop attack where an injected goal persists across iterations.
  • AI-BOM — AI Bill of Materials; the inventory of artifacts and their provenance. Module 4.

References

  • OWASP LLM Top 10 entries LLM02 (Insecure Output Handling), LLM05 (Supply Chain), LLM08 (Excessive Agency).
  • LangChain CVE history — https://www.cve.org/CVERecord/SearchResults?query=langchain
  • MITRE ATLAS AML.T0010 (ML Supply Chain Compromise) — https://atlas.mitre.org/techniques/AML.T0010

Quiz items

  1. Q: A defender restricts the agent's send_email tool to only allow the authenticated user's own address as recipient. Which OWASP entry is this defending against? A: LLM08 — Excessive Agency.
  2. Q: Your model output renders into the user's browser as HTML. The model is tricked into emitting a <script> tag. Which OWASP entry? A: LLM02 — Insecure Output Handling (output XSS).
  3. Q: Why is the infrastructure plane "mostly classical" but not entirely? A: Classical infra controls apply, but AI-specific items (LLM API keys with unbounded compute spend, GPU side channels, immature vector-DB auth) need additional attention.

Video script (~620 words, ~4.5 min)

[SLIDE 1 — Title]

Application, agent, and supply-chain planes in depth. Plus a quick word on infrastructure. Five minutes.

[SLIDE 2 — Application plane: four surfaces]

Application plane — four surfaces. One: the user-input boundary, where untrusted text first enters the system. Most prompt-injection defenses live here — input filters, length limits, schema-validated input. Two: prompt template authoring. The static prompt scaffolding — system prompt, few-shot examples, persona definitions. Often the most leaked artifact in production. System-prompt extraction lives here.

Three: the output renderer. Whatever displays model output to the user — HTML renderer, markdown parser, voice synthesizer. Output-handling vulnerabilities live here. XSS via model output. SSRF via auto-fetched URLs. SQL injection via formatted-string queries. OWASP LLM02.

Four: the tool-call boundary, if the application is agentic. Where model output triggers a tool invocation. Authorization decisions about which tools to expose, and what arguments to validate, live here.

[SLIDE 3 — Agent layer: three unique surfaces]

Agent layer — three unique surfaces. Subset of the application plane but important enough to call out. One: tool definitions. What tools is the agent allowed to call? Over-broad tool surfaces are the canonical excessive-agency vulnerability. A send-email tool that accepts any recipient is a different beast than one restricted to the user's own address.

Two: agent loop logic. Many agents have a plan-act-observe loop. An attacker who lands a single injection can plant goals that persist across loop iterations — plan-hijacking. Module 3 has a lab on this.

Three: inter-agent communication, for multi-agent systems. When agent A's output becomes agent B's input, agent B treats it as authoritative — even though A may have been compromised by an injection three hops back.

[SLIDE 4 — Supply chain: three surfaces]

Supply chain plane — three surfaces. One: model weights. Any pre-trained or fine-tuned model you pull from a registry. Risk: weight files with malicious pickle payloads, backdoor triggers, model card lies. Two: datasets. Training data, fine-tune data, eval data downloaded from HuggingFace, Kaggle, others. Poisoned examples, label flips, embedded triggers. Three: libraries and frameworks. LangChain, embedding-model libraries, vector DB SDKs, agent frameworks, inference runtimes. Classical supply-chain risk plus AI-specific concerns.

[SLIDE 5 — LangChain CVE anchor]

One anchor. LangChain has shipped multiple CVEs where chain-definition strings could trigger arbitrary code execution via insufficient sandboxing of expressions inside templates. This is a supply-chain attack. A defender using the library with default config inherits the vulnerability without any AI-specific mistake on their part. Module 4 covers SBOM and dependency review for the AI stack.

[SLIDE 6 — Infrastructure plane]

Infrastructure plane. Mostly classical infrasec — GPUs, containers, Kubernetes, network, secret stores. The AI specifics: API keys for LLM providers are high-value targets, theft equals unbounded compute spend. GPU schedulers can be a side channel for model extraction against shared inference clusters. Vector DBs are new infrastructure with their own auth and isolation stories — don't assume they have the maturity of Postgres. General rule: do classical infrasec first, then layer AI specifics. If you have classical gaps, those will be exploited long before anyone bothers with AI-specific cleverness.

[SLIDE 7 — Up next]

Next three lessons we deep-dive on MITRE ATLAS. Tactics, techniques, case studies. See you there.

Slide outline

  1. Title — "Application, agent & supply-chain planes in depth".
  2. Application plane: four surfaces — quadrant with sample attack per surface.
  3. Agent layer: three surfaces — agent-loop architecture sketch with surfaces called out.
  4. Supply chain: three surfaces — supply-chain graph: registry → weights/datasets/libs → your system.
  5. LangChain CVE anchor — CVE history mini-timeline.
  6. Infrastructure plane — classical infra icons + AI-specific overlays.
  7. Up next — "L2.3.1 — What ATLAS is and how it relates to ATT&CK, ~4 min."

Production notes

  • Recording: ~4.5 min. Cap 5.
  • Slide 5 (CVE history) needs to be updated annually — flag in the production review SOP.