MCP Server Supply Chain Is Runtime Supply Chain: Tool Manifests Need Policy and Evidence

A useful framing for 2026 comes from the DaedalusAgents signal that “MCP servers are part of a supply chain”. That statement is not metaphorical; it is operational reality. Traditional software supply-chain controls assume most dependencies are frozen at build or deploy time, but MCP can include runtime decision-making as part of its model, where agents discover tools, parse natural-language descriptions, and call live servers with credentials and host permissions.

As the WorkOS analysis of MCP supply-chain security argues, this is an agentic supply chain problem, not just a package-management problem. If your model can choose tools dynamically, then your trust boundary includes server identity, tool semantics, and runtime decisioning—not just source code hashes. That is why MCP supply chain governance has to combine pre-approval with continuous runtime authorization.

Why MCP supply chain extends into runtime

In classic CI/CD, dependencies are mostly static artifacts. In MCP, the dependency is a live capability endpoint whose behavior can change after approval. The model also consumes tool descriptions as decision input, so text in a manifest is effectively execution guidance.

This is why MCP server vetting cannot end at install time. A server approved last month can still become risky today through manifest edits, infrastructure compromise, or dependency updates. The Drel guidance on third-party MCP server vetting emphasizes this explicitly: review is staged, gated, and repeated, not “approve once forever.”

Four surfaces every MCP security review should cover

A practical MCP security review should evaluate four surfaces together:

Source: maintainer identity, release hygiene, disclosure process, and maintenance cadence.
Manifest: full tool manifest audit of names, descriptions, schemas, and scope alignment.
Host permissions: filesystem, network egress, process execution, and secret exposure.
Dependencies: vulnerability posture, provenance, pinning, and transitive risk.

The Drel checklist structure (source → manifest → permissions → dependencies) is a good baseline for this sequence. Meanwhile, Dan Grafham’s “Capability Bus” model is useful for architecture thinking: MCP is not a tiny plugin layer, but a cross-layer capability boundary with identity, blast radius, and policy implications.

Tool manifests are authorization inputs, not documentation

The biggest conceptual error is treating tool descriptions as passive metadata. In MCP, manifest text helps decide what the model does, which makes it security-relevant input. That makes tool poisoning (malicious or manipulative descriptions) and manifest drift (unreviewed changes to tools, descriptions, or schemas) authorization issues, not just quality issues.

So the manifest belongs in the policy path. If a description changes, that is a potential change in action semantics and should trigger review before re-enable. If a new tool appears, deny it by default until risk classification and explicit approval are complete.

Governance loop and runtime control plane (Permit.io as enforcement)

The durable pattern is a closed governance loop:

Approve server identity.
Baseline manifest.
Classify each tool by risk and assign trust levels.
Enforce action-time policy at a policy decision point.
Log every decision and invocation outcome.
Re-review detected changes before re-enabling capabilities.

Permit.io is best positioned as a runtime enforcement/control plane, not as generic “security marketing.” At runtime, approved tools still need argument validation, approval gates for high-risk actions, and deny-by-default behavior for unknown tools or changed manifests. Your objective is zero standing permissions: agents should receive only short-lived, scoped capability to perform a specific approved action, then lose that authority immediately.

This aligns well with OWASP Top 10 for Agentic Applications guidance, especially around agentic supply chain and governance controls: what matters is not only what was scanned, but what was actually authorized at decision time.

Evidence quality is the difference between “secure” and “provable”

A mature program keeps MCP audit evidence at five layers:

Baseline evidence: approved manifest hash, version, and review timestamp.
Policy evidence: the exact rule evaluation and decision at call time.
Invocation evidence: tool name, arguments, response class, and side effects.
Identity evidence: agent identity plus human delegator/approver where applicable.
Outcome evidence: success/failure, rollback/containment, and incident linkage.

Without this, incident response becomes guesswork. With it, you can reconstruct whether the issue was poisoned metadata, unauthorized argument shape, mis-scoped credential, or policy gap—and then remediate precisely.

Frequently asked questions

How do you vet a third-party MCP server before connecting it to an agent?

Use staged gates: source review, tool manifest audit, host-permission review, and dependency scanning. Require documented maintainer accountability, explicit scope justification per tool, and pinned versions before approval. Treat failures as blocks, not warnings, and schedule periodic re-review even if no visible change is reported.

Why are MCP tool descriptions and manifests security boundaries?

Because the model reads them to decide which actions to take. A description edit can change behavior without changing executable code, so manifests influence authorization outcomes in practice. In other words, manifests are part of the control plane, not just developer docs.

How should teams detect manifest drift or tool poisoning?

Capture a known-good manifest baseline (including descriptions and schemas) and compare it on every reconnect or startup. Alert on any delta: added tools, removed tools, changed descriptions, or changed parameter contracts. Route those deltas into a review workflow and keep changed tools disabled until re-approved.

What is the difference between supply-chain scanning and runtime tool authorization?

Supply-chain scanning evaluates code and dependencies pre-deployment (or periodically) for known defects and provenance issues. Runtime tool authorization decides whether a specific call should execute now, with current context, arguments, identity, and policy state. You need both: scanning reduces latent risk, while runtime authorization controls live action.

What evidence should be kept for MCP server approval, tool calls, and incident response?

Keep the approval record (who approved what, when, and why), the manifest baseline hash, and risk classification per tool. For each invocation, store agent identity, human delegator (if any), policy decision, arguments, and outcome. For incidents, preserve timeline-linked artifacts so responders can trace from approval to call path to impact.

How do trust levels and zero standing permissions reduce MCP blast radius?

Trust levels let you map tools to policy strictness: low-risk tools can auto-run with strong validation, while high-risk tools require explicit human approval gates. Zero standing permissions ensure agents do not retain broad credentials between tasks; authority is issued just-in-time and scoped per action. Together, they convert broad persistent risk into narrow, auditable, time-bounded access.