The Model Context Protocol has settled into a position similar to where package registries were a decade ago: an indispensable connective layer that nobody has fully secured. MCP servers expose tools — read this database, send this email, deploy this workload — that AI agents can call as part of their reasoning. Each tool is a privileged capability with consequences in the real world. The decisions about which agent gets which tool, under what conditions, and with what guardrails are starting to look very much like the decisions security teams have been making about workload admission for years. The discipline is the same. The vocabulary is just newer.
The risk profile of an MCP server is not theoretical. A poorly scoped MCP integration can expose internal databases to an agent whose instructions have been manipulated through prompt injection. A trusted-by-default tool list gives an agent capabilities the user never approved. A capability granted for one workflow gets reused for an unrelated workflow because nobody scoped the grant tightly. Each of these is the AI-era version of a problem the supply chain community already has language for. Capability policy is the answer.
The shape of capability policy
Capability policy decides three things, evaluated for every agent-tool interaction.
Which servers an agent can connect to. Not every agent in an organization needs every MCP server. A research-assistant agent has no business connecting to the production deploy server. A customer-support agent has no business connecting to the source-control server. The connection list is itself a policy decision, scoped per agent identity.
Which tools on a connected server an agent can call. A server may expose dozens of tools. The policy decides, per agent, which tools are reachable. The default is deny: a tool must be explicitly granted to be callable.
Under what conditions a granted tool can be called. Some tools are safe at any time. Others should be available only during specific operations, with specific arguments, or after specific approvals. The deploy tool is callable, but only against the staging environment, only with arguments matching the agent's current task, and only when no incident is in progress.
These three layers can be expressed as policy rules with the same shape as the supply chain rules in earlier sections, evaluated by the same engine, audited through the same pipeline.
Why MCP needs supply-chain-grade enforcement
The dynamics of MCP look more like supply chain than like classical access control.
The list of MCP servers an organization uses changes often. New servers are added when teams adopt new tools. Old servers are deprecated. Each addition is a supply chain event: the server is software running somewhere, exposing a capability surface that needs to be reviewed. PR-time policy on the configuration that adds an MCP server is a natural fit.
The capabilities an MCP server exposes change with each version of the server. A tool that took read-only arguments yesterday may take write arguments tomorrow. A new tool may appear that gives the agent access to data the original review never anticipated. Build-time and admission-time evaluation against the server's declared tool manifest catches these changes the moment they arrive, not when an incident reveals them.
Agent-tool interactions happen at runtime. The tool was permitted by policy at admission, but the specific call needs runtime evaluation: are the arguments within bounds, is the agent in a state where this call is appropriate, has the agent's recent behavior shown signs that warrant tighter scope. Runtime enforcement on tool calls is to MCP what runtime drift detection is to container workloads.
What the capability rules look like
A capability rule shares the structure of other supply chain rules but with MCP-specific inputs.
- Identity. The agent identity making the call, which may be a service principal, a user-attached agent, or a workflow component.
- Server. The MCP server being addressed.
- Tool. The specific tool on that server.
- Arguments. The structured arguments to the call.
- Context. The agent's current task, the user's session, the time of day, the active incident state.
- Verdict. Allow, allow-with-prompt, allow-with-approval, deny.
A useful pattern is the allow-with-prompt and allow-with-approval verdicts, which are halfway points between allow and deny.
Allow-with-prompt surfaces the call to the user — the agent is about to call send_email with these arguments, do you approve? — before executing. This is appropriate for tools whose effects are reversible but undesirable when wrong.
Allow-with-approval routes the call to a designated approver group, similar to a break-glass workflow. The agent waits, the approver decides, and the call either proceeds or is rejected. This is appropriate for tools whose effects are irreversible or whose blast radius is significant.
Both verdicts are policy outcomes, recorded in the audit log alongside denials and unconditional allows.
Recurring failure patterns
Several failure patterns recur in MCP capability deployments.
Trust-by-default. An organization adopts a popular MCP server and grants every agent every tool because the server is trusted. The grant breadth is invisible until an incident exposes which tools were callable that should not have been. The fix is explicit per-agent grants from day one, with the default being deny.
Argument blindness. A tool that takes a query string is granted to an agent without any policy on what queries are acceptable. The agent's instructions get manipulated and it issues a query that exfiltrates data. The fix is argument-level policy: structured rules about what arguments are permitted for granted tools.
Capability creep. A grant that was scoped tightly at first gets broadened over time as developers find it convenient to reuse the same agent for new workflows. The grant expansion is rarely reviewed because it does not look like a security event. The fix is grant expiry: every capability grant has a renewal date, after which it must be re-justified.
Audit gaps. The MCP server logs that a tool was called. The agent runtime logs that the call was made. Neither logs the policy decision, the agent's task at the time, or the user context. Reconstructing what happened during an incident becomes detective work. The fix is unified audit, capturing the full chain — agent, task, server, tool, arguments, verdict — in one place.
Inconsistent enforcement. PR time reviews MCP integrations once. Runtime enforces nothing. The gap is that an integration approved when the server exposed five tools is still approved when the server exposes fifty. The fix is the same as the unified-policy thesis: enforce at every gate, against the current state of the server.
What good MCP capability policy looks like
A team running MCP capability policy with discipline can answer specific questions quickly.
Which agents can call our deploy MCP server's apply tool? Returns a list, not a hand-wave.
What tools were called by agent X during incident Y? Returns a structured audit trail, with the policy verdict at the time of each call.
Which capability grants are expiring this month? Returns a list of grants whose owners need to re-justify them.
When did this MCP server's tool surface last change? Returns the version history, with which tools were added and which were removed at each version.
The questions are the same shape as the questions a mature supply chain program answers about packages and workloads. The data is just about agents and tools.
How Safeguard Helps
Safeguard treats MCP capability as another input to the unified policy engine, evaluated at the same four gates that govern code and container supply chain.
At PR time, Safeguard reviews changes to MCP server configurations and capability grants. A new MCP server connection in the configuration triggers a review against the trusted-server policy. A new tool grant to an agent triggers evaluation against the agent's authorized scope. PR comments name the change, the policy hit, and the override path.
At build time, Safeguard captures the MCP server's tool manifest as part of the artifact's attestation chain, so the capability surface is recorded at the moment of build and can be verified later.
At admission time, Safeguard's policy engine evaluates the agent's deployment configuration against the active MCP capability policy, refusing deployments whose grants exceed the agent's authorized scope or whose servers are not on the trusted list.
At runtime, Safeguard sits in front of agent-tool calls and evaluates each call against the active capability policy: identity, server, tool, arguments, context. Verdicts include allow, allow-with-prompt, allow-with-approval, and deny, with the prompt and approval workflows wired into the agent's user-facing surface and the approver rotation respectively.
The capability rules, the override workflow, and the audit log share infrastructure with the rest of Safeguard's policy plane. The same evaluate_policies decision engine that governs which dependencies enter a codebase also governs which tools an agent can call. MCP capability stops being a configuration sprawl and becomes a controlled, audited part of the supply chain.