AI Supply Chain Security: How Open-Source Dependencies Become Attack Vectors in LLM Applications

In March 2026, Mercor, a $10 billion AI recruiting startup that provides data training services to OpenAI, Anthropic, and Meta, confirmed a supply chain compromise traced to LiteLLM. The attack group TeamPCP planted credential-harvesting code in the widely-used open-source library before it was detected and removed within hours. Data potentially exposed included up to 4 terabytes: Slack communications, internal ticketing, source code, database records, and confidential AI project information for Mercor’s enterprise customers.

The root cause was not in Mercor’s own code. It was in a dependency they trusted implicitly.

This is the defining characteristic of supply chain attacks: you write clean code, you build rigorous tests, you pass every security review, and you still get compromised because something upstream from you was altered. The AI toolchain layer adds a specific and underappreciated dimension to this risk. Libraries like LiteLLM, LangChain, LlamaIndex, and Instructor are newer, less scrutinized, and deeply embedded in the code paths that handle credentials, model API calls, and sensitive user data. Most teams auditing their OSS exposure have not yet applied the same rigor to their AI dependencies that they apply to their general application stack.

Why AI Toolchain Risk Differs from Traditional OSS Supply Chain Risk

Traditional supply chain security advice centers on well-understood categories: malicious packages with typosquatted names, compromised maintainer accounts, dependency confusion attacks in private registries, and known CVEs tracked by tools like Snyk or Dependabot.

The AI toolchain layer introduces several factors that make this harder:

Rapid dependency churn. LangChain’s changelog between minor versions frequently includes breaking changes and new network call patterns. Teams pin a version that works, accumulate version drift over months, and then upgrade in a batch because they want a new feature. That batch upgrade may include changes to how credentials are passed, how model responses are streamed, or which external services are contacted.

Opaque network behavior. When your AI framework makes an outbound HTTP call, it may be legitimate routing to an LLM provider, it may be telemetry to a third party, or in an attack scenario, it may be exfiltration to an attacker-controlled endpoint. Unlike application code you wrote, you rarely audit every network call made by your framework layer. The LiteLLM incident pattern follows this exactly: injected code piggybacked on the library’s existing network activity.

Deep privilege access. LLM libraries sit at the intersection of your API key management, your prompt data (which often contains user context or business logic), and your model provider credentials. A compromised package at this layer is not just an exfiltration risk. It can silently alter the prompts sent to your models, inject instructions, or swap out model routing to redirect calls through an attacker-controlled proxy.

Multi-agent cascade risk. Security research from Galileo AI simulating multi-agent failure scenarios found that a single compromised agent poisoned 87% of downstream decision-making within four hours. In multi-agent architectures where agents share context, use shared tool registries, or pass structured state between steps, a compromise at any node propagates with speed that does not give human operators a realistic intervention window.

Mapping the AI Dependency Attack Surface

Before you can defend it, you need to know what you are defending. A typical production LLM application has four dependency categories, each with a different risk profile:

Framework layer. LangChain, LlamaIndex, LiteLLM, LlamaStack, CrewAI. These libraries have the broadest access: they call model provider APIs, handle prompt assembly, manage tool invocations, and often manage memory or state. Compromise here affects every inference call your application makes.

Utility and integration layer. Instructor (structured output parsing), tiktoken (token counting), sentence-transformers (embedding generation), openai/anthropic/cohere SDK packages. These are lower-risk individually but represent a larger surface area because there are more of them and they update more frequently.

Orchestration and agent tooling. LangGraph, Haystack, Semantic Kernel, AutoGen, Pydantic AI. These libraries often manage execution graphs, handle agent state, and coordinate multi-step workflows. A compromise here can silently alter agent routing or inject steps into execution plans.

Data pipeline adjacents. Packages used for document processing, PDF extraction, chunking, and embedding storage. PyMuPDF, unstructured, chromadb client libraries, pinecone-client. These handle raw document content before it ever reaches the model, making them a vector for data exfiltration.

Dependency Validation in TypeScript

The following implementation provides a practical starting point for auditing and monitoring your AI toolchain dependencies in a Node.js / TypeScript environment. It checks pinned versions against a known-safe registry, detects unexpected new transitive dependencies, and alerts on network behavior anomalies at the HTTP client level.

import { exec } from "child_process";
import { promisify } from "util";
import * as fs from "fs/promises";
import * as crypto from "crypto";
import * as https from "https";

const execAsync = promisify(exec);

// Represents a validated baseline for a dependency
interface DependencyBaseline {
  name: string;
  pinnedVersion: string;
  integrityHash: string; // SHA-256 of the resolved package tarball
  approvedAt: string; // ISO timestamp
  approvedBy: string;
  allowedTransitives: string[]; // Expected transitive dep names
}

interface AuditResult {
  dependency: string;
  status: "ok" | "version_drift" | "integrity_mismatch" | "new_transitive";
  detail: string;
}

// Load your baseline from a checked-in file, not generated at runtime
async function loadBaseline(path: string): Promise<DependencyBaseline[]> {
  const raw = await fs.readFile(path, "utf-8");
  return JSON.parse(raw) as DependencyBaseline[];
}

// Compute the integrity hash of a package as installed on disk
// Uses the resolved tarball URL from package-lock.json
async function getInstalledIntegrity(packageName: string): Promise<string> {
  const lockRaw = await fs.readFile("package-lock.json", "utf-8");
  const lock = JSON.parse(lockRaw);

  const entry =
    lock.packages?.[`node_modules/${packageName}`] ??
    lock.dependencies?.[packageName];

  if (!entry?.integrity) {
    throw new Error(`No integrity entry found for ${packageName}`);
  }

  // npm uses SRI format: sha512-<base64>
  // Return as-is for comparison against your baseline
  return entry.integrity as string;
}

// Compare installed state against approved baseline
async function auditDependency(
  baseline: DependencyBaseline
): Promise<AuditResult> {
  try {
    const installedIntegrity = await getInstalledIntegrity(baseline.name);

    if (installedIntegrity !== baseline.integrityHash) {
      return {
        dependency: baseline.name,
        status: "integrity_mismatch",
        detail: `Expected integrity ${baseline.integrityHash}, found ${installedIntegrity}. Package content has changed since approval.`,
      };
    }

    // Check for unexpected new transitives by diffing installed dep tree
    const { stdout } = await execAsync(
      `npm ls ${baseline.name} --json --depth=3 2>/dev/null`
    );
    const tree = JSON.parse(stdout);
    const installedTransitives = extractTransitiveNames(tree, baseline.name);

    const unexpected = installedTransitives.filter(
      (t) => !baseline.allowedTransitives.includes(t)
    );

    if (unexpected.length > 0) {
      return {
        dependency: baseline.name,
        status: "new_transitive",
        detail: `Unexpected transitive dependencies detected: ${unexpected.join(", ")}`,
      };
    }

    return {
      dependency: baseline.name,
      status: "ok",
      detail: "Integrity verified, no unexpected transitives",
    };
  } catch (err) {
    return {
      dependency: baseline.name,
      status: "integrity_mismatch",
      detail: `Audit failed: ${(err as Error).message}`,
    };
  }
}

function extractTransitiveNames(
  tree: Record<string, unknown>,
  rootPackage: string
): string[] {
  const names: string[] = [];
  function walk(node: Record<string, unknown>) {
    if (node.dependencies && typeof node.dependencies === "object") {
      for (const [name, child] of Object.entries(
        node.dependencies as Record<string, unknown>
      )) {
        names.push(name);
        walk(child as Record<string, unknown>);
      }
    }
  }
  // Find the subtree for the target package
  const top = (tree as Record<string, unknown>).dependencies as Record<
    string,
    unknown
  > | undefined;
  if (top?.[rootPackage]) {
    walk(top[rootPackage] as Record<string, unknown>);
  }
  return [...new Set(names)];
}

// Run a full audit against all baselines and return results
async function runAudit(baselinePath: string): Promise<AuditResult[]> {
  const baselines = await loadBaseline(baselinePath);
  const results = await Promise.all(baselines.map(auditDependency));
  return results;
}

export { runAudit, AuditResult, DependencyBaseline };

The key design decisions here are worth noting. The baseline file is checked in alongside your source code, not generated dynamically. This means a pull request that modifies it is visible in code review. The integrity hash is taken from package-lock.json rather than computed live, which means it reflects the actually-installed binary state rather than what npm reports the package should be. Transitive dependency tracking catches the class of attack where a malicious payload is delivered not in the top-level package but in a transitive dependency it introduces.

Monitoring Outbound Network Behavior at Runtime

Integrity checks at install time catch tampering in the package files. They do not catch runtime behavior where a legitimate package file makes unexpected network calls. For AI applications, you want a second layer: monitoring the actual outbound HTTP traffic your AI framework layer produces.

import { URL } from "url";

// A list of approved outbound hosts for your AI stack
const APPROVED_AI_HOSTS = new Set([
  "api.openai.com",
  "api.anthropic.com",
  "api.cohere.com",
  "api.mistral.ai",
  "generativelanguage.googleapis.com",
  "bedrock-runtime.us-east-1.amazonaws.com",
  // Add your specific provider endpoints here
]);

interface OutboundCallEvent {
  host: string;
  path: string;
  method: string;
  timestamp: string;
  approved: boolean;
}

type NetworkAuditCallback = (event: OutboundCallEvent) => void;

// Monkey-patch https.request to intercept and audit outbound calls
// Use this in development and staging, not production hot paths
function installNetworkAuditHook(callback: NetworkAuditCallback): () => void {
  const originalRequest = https.request.bind(https);

  (https as unknown as Record<string, unknown>).request = function (
    options: https.RequestOptions | string | URL,
    ...args: unknown[]
  ) {
    const url =
      typeof options === "string" || options instanceof URL
        ? new URL(options.toString())
        : null;

    const host =
      url?.hostname ??
      (typeof options === "object" ? (options as https.RequestOptions).hostname : null) ??
      "unknown";

    const event: OutboundCallEvent = {
      host,
      path:
        url?.pathname ??
        (typeof options === "object"
          ? (options as https.RequestOptions).path ?? "/"
          : "/"),
      method:
        typeof options === "object"
          ? (options as https.RequestOptions).method ?? "GET"
          : "GET",
      timestamp: new Date().toISOString(),
      approved: APPROVED_AI_HOSTS.has(host),
    };

    callback(event);

    if (!event.approved) {
      throw new Error(
        `BLOCKED: Unapproved outbound host "${host}" from AI framework layer. ` +
          `If this is a legitimate new endpoint, add it to APPROVED_AI_HOSTS and document the change.`
      );
    }

    return originalRequest(
      options as https.RequestOptions,
      ...(args as Parameters<typeof originalRequest>)
    );
  };

  // Return a cleanup function
  return () => {
    (https as unknown as Record<string, unknown>).request = originalRequest;
  };
}

export { installNetworkAuditHook, OutboundCallEvent, APPROVED_AI_HOSTS };

This approach works well in CI integration tests and staging environments where you want to catch new unexpected outbound calls during framework upgrades before they reach production. The blocklist-throws approach in staging will surface any new telemetry endpoints, update check URLs, or exfiltration attempts added in a new package version, letting you make a deliberate decision about each one.

Tradeoffs

Approach	What it catches	What it misses	Operational cost
Integrity hash baseline	Tampered package files after install	Runtime behavior, legitimate version upgrades	Low (check in CI)
Transitive dep diff	New attack-vector packages added in updates	Malicious payload in existing transitives	Low
Runtime network audit hook	Unexpected outbound calls at test time	Encrypted/tunneled traffic, UDP	Medium (maintain allowlist)
Isolated network execution	All unexpected outbound traffic at runtime	Performance overhead in high-throughput paths	High
SBOM generation + CVE scanning	Known CVEs in any dependency	Zero-day attacks, novel injection patterns	Low-medium (automate in CI)

The full defense-in-depth posture uses all five. But if you are starting from nothing, integrity hashes and transitive diff checks in CI give you the highest signal-to-noise ratio for the least operational overhead.

Multi-Agent Cascade Risk

The Galileo AI research finding, 87% of downstream decisions poisoned within four hours from a single compromised agent, reflects a property of multi-agent architectures that is not well-understood at the system design level.

In typical multi-agent systems, agents share context through a shared memory layer, a message bus, or structured state objects. When one agent is compromised, the attacker does not need to compromise every agent independently. They need to inject content into the shared context in a way that influences downstream agents’ decisions.

The practical mitigations here operate at the architecture layer:

Agent isolation boundaries. Each agent in a pipeline should operate on a minimal context slice: only the data it needs for its specific task, not the full shared state. An agent performing summarization does not need access to the credentials the retrieval agent uses.

Output validation before propagation. Before a compromised agent’s output gets passed to downstream agents, validate its structure against a known schema. Use Zod or equivalent schema validation on every inter-agent message. A malicious injection payload typically cannot conform to a strict schema. This does not catch every attack, but it eliminates the class of attacks that work by injecting prompt text or structured data with unexpected keys.

Human checkpoints on high-risk decisions. Multi-agent systems that take consequential external actions (sending emails, making API calls to external services, writing to persistent storage) should require human approval before execution when those actions were not explicitly authorized in the original task specification. The speed advantage of fully autonomous pipelines is real, but the cascade failure mode is also real. Choose your intervention points deliberately.

Production Dependency Lockdown Checklist

The following is a practical checklist for AI-native applications going into production. It assumes a Node.js / TypeScript stack with npm but the principles apply to Python toolchains equally.

Repository controls:

• Lock file (package-lock.json or yarn.lock) is committed and CI fails on any uncommitted lock file changes
• Direct AI framework dependencies are pinned to exact versions, not semver ranges ("litellm": "1.34.2" not "^1.34.2")
• A baseline integrity file (as shown above) is committed alongside package.json and reviewed in PRs
• Dependabot or Renovate is configured with a review-required policy for AI framework packages specifically, not the default auto-merge

CI pipeline:

• Integrity audit runs on every pull request before any deployment job
• npm audit with --audit-level=high is a required status check
• A SBOM (Software Bill of Materials) is generated on every main branch merge using npm sbom and stored as an artifact
• New transitive dependencies introduced by an upgrade trigger a manual review flag

Runtime:

• AI framework calls are isolated in a service boundary with egress firewall rules permitting only approved provider endpoints
• All outbound calls from the AI layer are logged with host, method, and timestamp to your observability stack
• Model API key rotation is automated on a 90-day or shorter cadence
• API keys for model providers are scoped to minimum required permissions (not “all models” if you only use one)

Incident response:

• You have a documented procedure for: detect a compromised AI package, rotate all affected credentials, identify data that may have been exposed during the exposure window
• Your AI provider dashboards (OpenAI, Anthropic, etc.) are monitored for unexpected usage spikes, which are often the first signal of credential compromise
• You can enumerate every version of every AI library you have deployed to production in the last 90 days from your deployment logs

Organizational:

• Upgrades to AI framework packages are treated as the same risk category as upgrades to your authentication library, not as routine dependency updates
• At least one engineer is subscribed to the security advisories or GitHub security alerts for your top five AI dependencies

Production Considerations

The Mercor incident pattern will not be the last. The AI open-source ecosystem is growing faster than its security review processes can keep up with. Package downloads for LangChain, LiteLLM, and similar libraries have grown by orders of magnitude in two years. That growth attracts both well-intentioned contributors and adversarial actors looking for high-impact injection points.

The software supply chain attack against SolarWinds in 2020 and the Cl0p MOVEit attack in 2023 both demonstrated that even well-resourced organizations with mature security programs can be compromised through trusted third-party software. The AI toolchain is at an earlier maturity stage than either of those systems were when they were attacked.

Two additional factors make this harder than traditional supply chain defense. First, AI library updates often ship as point releases that look routine but change network behavior, credential handling, or prompt assembly logic in ways that are difficult to review without deep framework knowledge. Second, the teams building AI applications are often moving fast and not applying the same scrutiny to their framework layer that they apply to their own code.

The runtime network audit hook shown above is intentionally blunt: it throws on any unexpected outbound call. Some teams will prefer a warn-and-log approach in production. Either way, the goal is to build an observable boundary around your AI framework layer so that a future supply chain compromise surfaces as a detectable anomaly in your monitoring, not as a silent data exfiltration event that you learn about months later from a threat intelligence report.

Defense in depth applies here the same way it applies everywhere else in distributed systems. No single control is sufficient. Integrity checks at install time, egress filtering at runtime, observability on model provider API usage, and rapid credential rotation capability combine into a posture that significantly raises the cost of a successful attack.

The AI dependency layer is not yet treated with the same security maturity as the rest of the stack. That gap is closing as incidents like the LiteLLM compromise make the risk concrete. The teams that close it proactively are the ones that will not be explaining a supply chain breach to their customers next quarter.