Q2: How do I protect against agentic supply chain attacks?

Sign and pin every component. Maintain an AIBOM. Treat every dynamically loaded artifact like a production dependency.

The root cause of agentic supply chain risk is that agents load components from publishers they can't verify, and the content can change underneath them. The fix is borrowing what already works for traditional supply chain security and applying it to the runtime surface.

OWASP and the broader community converge on a short list of high-leverage controls. Here's how to operationalize them.

Step-by-step guide:

1. Verify a signature on everything your agents load. Trust starts with review, not with the signature. Someone on your side reviews and approves a specific version of every third-party component. The signature then confirms the component your agent loads matches what you approved. If the publisher signs their releases, your agent verifies the publisher's signature. If they don't, you sign the approved version yourself and verify your internal signature instead. No valid signature on an approved version, no load. Use Sigstore, in-toto, or your existing code-signing pipeline.

2. Pin to version or content hash. Lock each component to the specific version you reviewed and approved. If an MCP server publisher pushes a new version, your agent shouldn't pick it up automatically. Pinning gives you a known-good state and breaks silent supply chain swaps.

3. Maintain an AIBOM. An AI Bill of Materials lists every prompt, tool, MCP server, agent card, and model your agents can load, with versions, hashes, publishers, and last-reviewed dates. Treat it the way you treat your SBOM. Generate it automatically, review it on a cadence, and make it part of your change control.

4. Use a curated registry and allowlist. No agent loads from the open internet. Components live in a registry your team controls. Adding a new MCP server, prompt, or agent card requires the same review you'd give a new third-party library: security review, license review, publisher verification.

5. Verify agent cards before peering. In multi-agent systems, treat every new agent card the way you'd treat a new vendor. Verify the publisher, check the capability claims against actual behavior in a sandbox, and only then allow your production agents to route tasks through it.

6. Sandbox new components before promotion. Any new MCP server, tool, or peer agent runs in an isolated environment with synthetic data and constrained network access until it's been observed enough to promote. This is how you catch the Postmark-style impersonator before it sees your real user messages.

7. Verify model and fine-tune provenance. For every base model, fine-tuned model, or model adapter your agents use, capture and verify the source, the training data summary if available, and the model hash. Use vendor-signed model artifacts where supported.

Example:

Before: A team adopts a new MCP server from a public marketplace to handle email. The server's identity is never verified. A few weeks later, the server is silently swapped for an impersonator that forwards user messages to the attacker. The team has no AIBOM, no signature check, and no version pinning. They find out when a customer reports phishing emails referencing internal conversations.

After: The same team requires every MCP server to be signed by a trusted publisher and pinned to a specific content hash. The new email MCP server is added to the registry only after security review. When an attacker tries to push a malicious update, the signature check fails and the host agent refuses to load it. The AIBOM shows exactly which agents would have been exposed if the check hadn't held.

The traditional supply chain is still there. While the agentic surface is grabbing the headlines, the traditional software supply chain is still a huge challenge. Your build pipeline still produces software. That software still has third-party dependencies. Those dependencies still have CVEs, and a meaningful percentage of them are exploitable in your context. If your team is wrestling with the traditional side of this problem, that's exactly what we built Lunir for. We help you find the vulnerabilities that actually matter in your dependency graph and fix them without drowning in noise. The agentic supply chain is a different beast, and the controls in this article are how you start governing it. But don't let the new surface distract you from finishing the work on the old one.

Key takeaway: Sign and pin everything. Treat every dynamically loaded component like a production dependency. If you can't name the components and versions your agents are running right now, you can't answer the board and you can't manage vulnerabilities.

Q3: How do I detect agentic supply chain compromises before they reach my data?

Instrument every load event, baseline what "normal" looks like, and alert on identity, version, and behavior drift.

Prevention controls will fail eventually. A signing key gets compromised. A publisher you trusted ships a backdoor. A new component sneaks past review. You need detection that catches when a loaded component changes identity, version, or behavior in ways your baseline doesn't expect.

OWASP specifically calls out runtime monitoring of loaded components and behavioral baselining as critical controls for ASI04. You need to see every load event the same way you'd see every package install on a production server.

Step-by-step guide:

1. Log every load event with full provenance. Capture which agent loaded which component, the version, the content hash, the publisher, the signature verification result, and the source URI. Immutable logs. No exceptions.

2. Alert on unsigned or unpinned loads. If an agent loads an artifact that isn't signed, isn't pinned, or carries a signature you don't recognize, that's a high-priority alert. Treat it like an unsigned binary running on a production host.

3. Baseline tool and MCP server behavior. For every MCP server and tool, capture a baseline of expected behavior in a sandbox: which endpoints it calls, what data it accesses, what shape of output it produces. Alert when production behavior diverges.

4. Watch for tool-descriptor drift. Tool descriptions and MCP metadata should be effectively static. Alert when a tool descriptor changes between loads, especially when natural-language instructions appear inside metadata fields that should be structural.

5. Monitor agent card registries. In agent-to-agent systems, alert when new agent cards appear, when existing cards change their advertised capabilities, or when sensitive workflows start routing through newly registered peers.

6. Watch for outbound surprises. A transactional email MCP server should send email. If it suddenly starts making outbound calls to an unknown domain, especially one that looks like a paste site or a logging service, that's your Postmark moment. Catch it with egress monitoring scoped to the agent runtime.

7. Review on a cadence. Assign ownership for reviewing AIBOM diffs, load logs, and behavioral drift weekly. This is a privileged access review for the runtime supply chain. Treat it that way.

Example:

• Instrumentation: Every MCP server, tool, prompt, and agent card load is logged with publisher, version, hash, and signature result. A sandbox baseline exists for every component in the AIBOM.

• Signal: Alert fires when a popular email MCP server starts making outbound requests to a domain that isn't in its baseline. The behavior matches a known exfiltration pattern. The on-call team disables the component across all agents within the hour. Logs show which agents loaded it and which user sessions were exposed.

• Maintenance: Weekly review of AIBOM diffs, load anomalies, and agent card registry changes. Quarterly red team exercise that introduces a poisoned MCP server, a malicious agent card, and a tool-descriptor injection to test detection coverage.

Key takeaway: You can't defend a runtime supply chain you can't see. Treat every load event the way you'd treat a production deployment. Log it, baseline it, and alert when the picture changes.

Summary

Agentic Supply Chain Vulnerabilities is the risk that makes your existing supply chain program look incomplete overnight. Traditional supply chain security covers what your team ships. The agentic surface covers what your agents pull at runtime. It has a different cadence, different controls, and a different blast radius. And in most organizations, no one owns it yet.

Start by getting your leadership team to see the runtime surface. The loading dock and drone delivery analogy works because it makes the invisible problem concrete: the boxes you inspect at the dock and the packages that land on the roof mid-shift aren't the same problem, and you need a program for both. Then sign and pin every component your agents can load, maintain an AIBOM alongside your SBOM, and run new components through a sandbox before they touch production. Finally, instrument every load event, baseline behavior, and treat anomalies the way you'd treat a compromised production dependency.

And while you're building out the new program, don't let the old one slip. The traditional software supply chain is still there. It still ships your software. It still has the dependency vulnerabilities that have driven a decade of breaches. That's what we built Lunir for, and I'd rather you finish that work than leave it half done while you chase the new surface. Both matter. Both need a program.

The organizations that get ahead of ASI04 will be the ones that can name every component their agents loaded today, who signed it, and what version. Everyone else will read about the next postmark-mcp and have no way to know if it ran in their environment.