Supply-Chain Vulnerability

Issue: Agent uses compromised tool, plugin, package, MCP server, or model dependency.

Frequency: Rare but Catastrophic

Symptoms

• Dependency/tool behavior changes unexpectedly.
• MCP server or tool plugin version auto-updates and agent behavior diverges from previous results.
• Tool output contains unusual formatting, requests for credentials, or attempts to exfiltrate data.
• Agent’s tool calls start failing or returning unexpected data after a dependency update.
• Third-party library included in agent codebase suddenly includes obfuscated or suspicious code post-update.
• Model behaves erratically after model provider publishes new version; hallucinations increase.

Root Cause Dependencies — packages, tool plugins, MCP servers, even the underlying model version — are consumed with loose or unpinned version constraints and no software-composition-analysis scanning gate in CI/CD, so a new version can reach production automatically the moment it’s published, without any review of what changed. Because no signature or integrity verification confirms a package actually came from its legitimate maintainer, and no staging/approval step tests a version before it’s live, a compromised upstream release (a hijacked maintainer account, a poisoned package) is indistinguishable from a legitimate update to the pipeline, and nothing short of the compromise being independently discovered and reported would ever surface it.

Example

Scenario: Agent uses a popular Python package for data validation.

Setup:
- Agent depends on: "schema-validator==2.1.3" (legitimate package, 500K weekly downloads)
- Package has no vulnerability scanning or pinned versions in requirements.txt
- Dependency auto-updates enabled in CI/CD

Attack/Failure:
Attacker compromises PyPI account for maintainer of schema-validator.
Attacker publishes schema-validator==2.2.0 with backdoor:
- Normal validation works
- When validating user emails, silently exfiltrates to attacker@evil.com
- No visible error or warning

Agent updates to 2.2.0 automatically. After update:
- All user email data is exfiltrated to attacker
- Agent appears to work normally
- Data goes to attacker's server without agent logic involvement

Impact:
- 100,000+ users' email addresses leaked
- Customer data leaks at scale, bypassing application controls
- Difficult to detect because agent's code didn't change
- Attacker gains user contact list for phishing campaign

Contributing Factors

• Dependency versions not pinned; auto-update or loose version constraints (e.g., >=2.0 instead of ==2.1.3).
• No vulnerability scanning or software composition analysis (SCA) in CI/CD pipeline.
• MCP servers or tool plugins auto-update without testing or approval gate.
• Third-party package not signed; no cryptographic verification of integrity.
• Dependency pulled from single source (PyPI, npm) with no mirrors or local cache.
• No code review of dependency updates before deployment.
• Model provider updates without notification or testing period; agents forced to use new model version.
• Insufficient monitoring of package updates or behavioral changes in dependencies.

Test Scenario & Reproduction

Scenario Setup

• Agent depends on third-party libraries/packages
• Third-party code not scanned for vulnerabilities
• Vulnerable package version installed
• No dependency auditing or patching

Trigger Mechanism

1. Agent imports vulnerable library (e.g., requests==2.20.0)
2. Library has known RCE vulnerability
3. Attacker crafts malicious input exploiting vulnerability
4. Input triggers code path in vulnerable library
5. Arbitrary code executes with agent privileges

Expected Failure State

• Vulnerable library code executes
• Arbitrary code execution via dependency
• Agent/system fully compromised
• No detection of vulnerability in dependency tree

Mitigation Validation Protocol

Test Checklist:

• Reproduce: Exploit works on vulnerable version
• Apply mitigations (update library, scan dependencies)
• Re-run with patched version → exploit fails
• Verify: No other vulnerabilities in deps

Success Criteria:

• All dependencies scanned regularly
• Vulnerable packages updated/removed
• Dependency audit in CI/CD pipeline

Eval Recipes

Test Cases

Metrics

Mitigation Strategies

Prevention

1. Pin all dependency versions: Use exact version pinning (e.g., schema-validator==2.1.3) in requirements.txt/package-lock.json. Never use >= or ~ for agent dependencies.
2. Software composition analysis (SCA): Integrate tool like Snyk, WhiteSource, or Dependabot into CI/CD. Scan all dependencies for known CVEs before merging.
3. MCP server/tool registry + signing: Publish agent tools and MCP servers through controlled registry. Require cryptographic signatures and integrity checks before loading.
4. Approval gate for updates: Do not auto-update. Require explicit review and testing of dependency updates. Test in staging environment first.
5. Vendor hashes and mirrors: Download dependencies from multiple sources or verified mirrors. Verify cryptographic hash matches official source.
6. Tool usage allowlisting: Configure agent to only use approved tool plugins/MCP servers from allowlist. Reject unknown tools.
7. Dependency monitoring in production: Monitor for behavioral changes in dependencies post-deployment. Alert on unusual network traffic or data access patterns.
8. Model provider versioning: Pin model API version or request specific model version. Do not auto-upgrade model versions.

Detection

• Dependency/tool behavior changes unexpectedly.

Recovery

Immediate (Stop the Attack)

1. Identify the compromised dependency (from alerts, version monitoring, or behavioral anomalies).
2. Roll back to last known good version in production immediately.
3. Revoke or isolate any affected systems (kill containers, restart agents, revoke API access).
4. Notify all users/customers affected by the compromised dependency.

Investigation (Understand Scope)

1. Analyze compromised dependency version for malicious code (decompile, review source, static analysis).
2. Determine update timeline: when was compromised version published? How many services pulled it?
3. Query application logs and network logs for suspicious behavior during compromise window (data exfiltration, anomalous connections).
4. Trace which agent instances consumed the compromised dependency; correlate with data access logs.
5. Work with package maintainers and platform (PyPI, npm) to investigate account compromise and remove malicious version.

Remediation (Prevent Recurrence)

1. Implement SCA scanning and approval gates for all dependency updates (see Prevention).
2. Audit all currently installed dependency versions against CVE databases.
3. Rotate all credentials potentially leaked by compromised tool.
4. For affected data: audit access logs to determine what was exposed, notify customers per regulations.
5. Implement continuous monitoring for behavioral anomalies in production (see Production Signals).
6. Review and harden package registry access: use artifact repositories with access controls and signature verification.
7. Join security advisory mailing lists for critical dependencies to receive early notice of vulnerabilities.

Production Signals

Key Metrics

Alerts

References

• OWASP-LLM-Top10
• Note: LLM application risks including prompt injection, insecure output handling, supply chain, sensitive information disclosure, excessive agency.