AI Security ยท Supply Chain
MCPs And Agent Skills Are A Supply Chain Problem
Useful automation still needs provenance, review, least privilege, and an assumption that helpful tools can be hostile.
Agent skills and MCP-style connectors are powerful because they let people package repeatable workflows. That same packaging makes them easy to trust too quickly.
This feels familiar. Security teams already learned painful lessons from dependencies, shell scripts, browser extensions, and CI plugins. A useful tool can still be a risky tool.
The review questions are not exotic:
- Who wrote this?
- What can it access?
- What commands can it run?
- What data can it transmit?
- Can the behavior change after approval?
- Is there a narrower way to grant the same capability?
The point is not to avoid automation. The point is to make useful automation reviewable, observable, and appropriately constrained.
What I Would Review First
For agent tools, I care less about the label and more about the authority boundary.
A useful review starts with the boring questions:
- What data can the tool read?
- What actions can it take without another approval step?
- What external systems can it reach?
- What user or service identity does it borrow?
- What changes if the package updates later?
- What logs would prove what happened?
That keeps the review practical. An agent skill, MCP server, browser extension, CI plugin, or shell helper can all create the same kind of problem: a small package gets trusted with more authority than anyone meant to grant.
The fix is not to ban useful automation. The fix is to make the trust decision explicit. Prefer narrow permissions, stable provenance, reviewable source, pinned versions, visible update behavior, and logs that show which tool acted on which data.
For a checklist version of this idea, use AI Security Review Notes. For AI-assisted research workflows, pair it with Offensive Security With AI.