2938 Members
Join Permit's SlackA 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.
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.”
A practical MCP security review should evaluate four surfaces together:
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.
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.
The durable pattern is a closed governance loop:
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.
A mature program keeps MCP audit evidence at five layers:
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.
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.
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.
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.
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.
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.
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.
Co-Founder / CEO at Permit.io
