Agent Skills vs MCP: Trust Boundaries, Credentials and Governance Compared

Agent Skills and the Model Context Protocol (MCP) both extend what an AI agent can do, but they put the trust boundary in completely different places, and teams that govern one like the other leave gaps. A skill is a folder of instructions and optional scripts that the agent loads into its own context and runs inside its own environment, with its own access. An MCP server is a separate process or remote service that exposes tools through a protocol, holds or brokers its own credentials, and answers the agent's calls across a defined interface. This guide compares the two as a security architect would: where code runs, whose credentials are exposed, how each supply chain is attacked, how to review and govern each, and when to choose one, the other, or both. It is for platform owners, security engineers and AI governance leads deciding what agents may load. Facts were checked against the Agent Skills specification, the MCP specification (current revision 2026-07-28; security best practices and tools pages cited from revision 2025-11-25) and implementer documentation on 14 November 2026.

Key takeaways

• Skills run inside the agent; MCP servers run beside it. A skill has no identity of its own and acts with everything the agent can reach. An MCP server is a separate component with its own process, transport and, for remote servers, its own OAuth authorisation.
• Skills expose the agent's credentials; MCP servers concentrate their own. A malicious skill reads what the agent can read. A malicious or compromised MCP server misuses the token it was given, and in local mode can also run code with the client's privileges.
• Both supply chains have already been abused. Hundreds of malicious skills on one public registry delivered credential stealers in early 2026, and a counterfeit MCP server package silently copied outgoing email in 2025.
• Review differs in kind. A skill is reviewed like code plus prompt text; an MCP server is reviewed like a third-party integration: transport, authorisation, token audience, scopes and publisher.
• They combine. A skill can tell the agent to call MCP tools, so the effective risk of a skill includes every MCP server it references.

What each one is

Agent Skills

The Agent Skills specification defines a skill as a directory containing at minimum a SKILL.md file: YAML frontmatter followed by Markdown instructions, with optional scripts/ (executable code), references/ (documentation) and assets/ (templates and data). Only two frontmatter fields are required: name (up to 64 characters, lowercase letters, digits and hyphens, matching the directory name) and description (up to 1,024 characters). An experimental allowed-tools field lists tools that are pre-approved to run, and the specification notes that support varies between agent implementations.

Skills load by progressive disclosure: the name and description of every installed skill (about 100 tokens each) at start-up, the full body (under 5,000 tokens recommended) when a task matches, and bundled files only when needed. Implementer documentation adds that scripts run through the agent's shell and only their output enters the model's context. The operational and hardening detail for skills is in the Agent Skills Security Guide; this page focuses on the comparison.

MCP servers

MCP is a client-server protocol. A host application runs an MCP client that connects to one or more servers, each of which exposes tools, resources and prompts. Tools are described by a name, description and JSON Schema inputSchema, discovered with tools/list and invoked with tools/call. Servers run either locally, usually over the stdio transport, or remotely over Streamable HTTP. For HTTP transports the authorisation specification makes the MCP server an OAuth 2.1 resource server; for stdio it says implementations should not follow the OAuth flow and should instead retrieve credentials from the environment. The broad MCP picture is in the MCP Security Guide.

Side-by-side comparison

Where the trust boundaries sit

Skills: the boundary is the agent. When a skill activates, its instructions enter the model's context with the authority of other trusted instructions, and its scripts run wherever the agent runs. Nothing in the format authenticates the author or limits what instructions may ask. The same skill therefore carries very different risk by environment: implementer documentation describes one surface where skills run in a code-execution container with no network access and no runtime package installation, and another, a local coding agent, where skills have full network access like any other program on the user's machine. The only reliable limit on a skill is the limit on the agent that loads it.

MCP: the boundary is the protocol interface, if you enforce it. An MCP server can be isolated from the agent: it receives structured arguments and returns structured results, and a remote server should only accept tokens issued for it. The specification requires that MCP servers validate that access tokens were issued specifically for them as the intended audience and forbids token passthrough to downstream APIs. That gives a real boundary, but two things weaken it. First, a local stdio server is a program on the user's machine; the security best practices document warns that MCP servers run with the same privileges as the client unless sandboxed. Second, everything a server returns flows back into the model, so the interface is a data boundary, not an instruction boundary.

Combined boundary. Implementer review guidance rates a skill that references MCP tools as a high concern because it extends access beyond the skill itself. When you approve a skill, you are also approving its use of every MCP server it names, with the tokens those servers hold.

Agent Skills: threat model, failure modes and controls

Threat model. The attacker's goal is to get instructions or code into the agent's trusted context. Routes include publishing a look-alike skill to a public registry, committing a skill to a repository that others clone, changing an external URL or dependency that a reviewed skill fetches, or hiding directives in the description that is loaded into every session.

Failure modes.

• "Prerequisite" commands: the ClawHub malicious skills campaign used a Prerequisites section telling the user or agent to run a command that fetched information stealers, which targeted exchange API keys, wallet keys, SSH keys, browser passwords and the agent's own credentials.
• Over-broad pre-approval: allowed-tools lets listed tools run without a prompt; it is a convenience, not a sandbox.
• Secrets in the skill: review guidance rates hardcoded credentials as high concern because they end up exposed in Git history and the context window.
• Repository skills: anyone who can merge to a repository can change what agents do on every clone.
• Drift after review: skills that fetch remote content can change behaviour without any file changing.

Controls. Run skill-heavy agents under a dedicated non-human identity with least privilege rather than a developer's full profile; keep .env files, SSH keys and browser profiles out of the agent's readable paths; review SKILL.md, every script and every URL; require a reviewer other than the author; pin versions and verify checksums at deployment; and allow third-party skills first in sandboxed, credential-free environments. Treat built-in skill scanning as one layer: the ClawHub page notes the registry itself described scanning as "not a silver bullet".

MCP servers: threat model, failure modes and controls

Threat model. The attacker wants either the server's credentials and data path, or the model's attention. Routes include publishing a counterfeit server package, compromising a legitimate one, running a malicious remote server that a user connects to, poisoning tool descriptions or results, and abusing OAuth flows around proxy servers.

Failure modes.

• Counterfeit or trojanised servers: the postmark-mcp malicious MCP server copied a legitimate open-source server, behaved correctly for fifteen versions, then added one line that blind-copied every email the agent sent, using the victim's own credentials.
• Local server compromise: the security best practices document describes malicious startup commands in client configuration and payloads inside the server, with risks including arbitrary code execution with client privileges and no user visibility.
• Token passthrough and audience failures: a server that accepts tokens issued for other services, or forwards a client's token downstream, breaks accountability and lets a stolen token be replayed through it.
• Confused deputy at proxy servers: a proxy using a static client ID with a third-party authorisation server can let an attacker obtain codes without consent unless it implements per-client consent.
• Tool poisoning and changing tool lists: descriptions and annotations shape model behaviour; the tools specification says clients must treat annotations as untrusted unless they come from trusted servers. See MCP Tool Poisoning Detection.
• Over-broad scopes: the best practices document lists publishing every scope in scopes_supported and wildcard scopes as common mistakes.

Controls. For local servers, the specification requires one-click configuration to show the exact command and obtain explicit consent, and recommends sandboxed execution with restricted file system and network access. For remote servers: OAuth 2.1 with PKCE (S256), resource indicators (RFC 8707) on every request, audience validation, no passthrough, minimal initial scopes with step-up, and a gateway or allowlist so only approved servers are reachable. Give each server its own narrowly scoped credential. Hardening detail is in the Local MCP Server Security Guide and the Remote MCP Server Hardening Guide.

Credentials exposure compared

The practical consequence: MCP gives you a per-extension credential you can scope and revoke, skills do not. If a capability needs a sensitive credential, putting it behind an MCP server (with its own token, audience and logs) is usually easier to govern than handing the agent the credential and a skill that uses it. See API Keys vs OAuth for MCP Servers and the Credential Vaulting for AI Agents Guide.

Supply chain and governance

Implementer guidance for skills recommends that authors should not be their own reviewers, that production deployments pin skills to specific versions, and that each update be treated as a new deployment requiring full security review. For MCP, the MCP Server Trust Assessment and the MCP Registry and Server Publishing Security Guide cover intake.

When to use each

• Use a skill when the need is know-how: a house style, a review procedure, a document template, or a deterministic script over files the agent already handles. Skills are lightweight and cheap in context.
• Use an MCP server when the need is access to another system: a database, SaaS API or internal service, especially one that needs its own credential, per-user authorisation or an audit trail independent of the agent.
• Use both when a procedure orchestrates system access: the skill says how and when, the MCP server does the privileged call with its own token. Review them as a pair.
• CLI wrapped in a skill or MCP server? A skill that calls a command-line tool inherits whatever credentials that tool finds on the host. An MCP server wrapping the same tool can hold a dedicated credential and expose only chosen operations. Prefer the server when the CLI touches production or holds secrets.
• Small teams: start with a short allowlist of first-party skills and a few approved MCP servers behind OAuth, with agents running under their own identity. Large organisations: run both through managed distribution (skill library, MCP gateway or registry), with separate reviewers and a single inventory.

Worked scenarios

Scenario 1: the "deploy helper". An engineer finds a public skill that automates cloud deployments. Its script reads the local cloud profile and calls the provider's CLI. Installed on a laptop with administrator credentials, the skill could do anything that profile allows. Better design: a reviewed internal skill for the procedure, plus an MCP server or pipeline that holds a deployment-scoped credential, so the skill never touches long-lived keys.

Scenario 2: the ticketing integration. A support team wants agents to read and update tickets. An MCP server with OAuth, a minimal read scope at first and step-up to write, gives per-user consent, revocation and server-side logs. A skill alone would need an API token in the agent's environment, readable by every other skill.

Scenario 3: the quiet update. A popular MCP server publishes a new version that adds a tool and changes a description. Clients that auto-update pick it up silently. Controls that would have caught it: pinned versions, a gateway that alerts on tool list changes, and review of description diffs as prompt text.

Scenario 4: the repository skill. A contributor adds a skill to a shared repository that pre-approves shell commands. Every developer who opens the project with a coding agent now runs those commands without prompts. Controls: block project-level skill pre-approvals through managed settings where the agent supports it, require code-owner review for skill directories, and scan skill folders in CI.

How to implement: a phased approach

1. Discover. Inventory skills on agent hosts and in repositories, and MCP server configurations on developer machines and in agent platforms. See How to audit MCP servers on developer laptops.
2. Scope the agent identity. Move agents off personal credentials to dedicated identities with least privilege, which limits every skill at once.
3. Establish intake. One review checklist for skills (code plus prompt text) and one for MCP servers (integration and authorisation), with separate reviewers.
4. Pilot an allowlist. Enforce it in audit mode first for one team, record what would have been blocked, then enforce. Keep a rollback path: re-enable the previous allowlist version if critical work breaks.
5. Move sensitive access behind MCP. Where a skill uses a sensitive credential, replace that path with an MCP server holding a scoped token.
6. Monitor and review quarterly. Remove unused skills and servers, rotate credentials, and re-review anything that changed.

Detection and measurement

• Skills: log skill activation, shell commands and outbound connections from agent hosts; alert on new skills appearing outside the managed library.
• MCP: log tool calls with client, user and arguments; alert on new servers, tool list changes, scope elevation and tokens presented with the wrong audience.

Common failure patterns

• Treating skills as documents. They are code and trusted instructions running as the agent.
• Treating MCP servers as libraries. They are integrations with their own credentials and supply chain; pin and review them.
• Reviewing a skill without the MCP servers it calls, so the approved skill reaches systems nobody reviewed.
• Giving agents personal credentials, which turns every skill into a path to everything the person can reach.
• Auto-updating either kind, so the version reviewed is not the version running.

Framework mapping

Practitioner checklist

• Keep one inventory covering skills and MCP servers, with owner, version and source for each.
• Run agents under dedicated, least-privilege identities, never personal credentials.
• Read every file in a skill before approval, and require a reviewer other than the author.
• Review the MCP servers a skill references as part of the skill's approval.
• Pin versions for both, verify checksums or digests, and review diffs before upgrade.
• Give each MCP server its own scoped token; enforce audience validation and no passthrough.
• Require explicit consent and sandboxing for local MCP servers.
• Keep secrets out of skills and out of agent-readable paths.
• Alert on new skills outside the library, new MCP servers and tool list changes.

Standards and references

• Agent Skills: Specification
• Model Context Protocol: Security Best Practices
• Model Context Protocol: Authorization
• Model Context Protocol: Tools
• OWASP: Top 10 for LLM Applications 2025
• MITRE ATT&CK: Compromise Software Supply Chain
• Anthropic: Agent Skills overview
• Anthropic: Agent Skills for enterprise

Related NHI Mgmt Group resources: MCP vs Native Function Calling, AI Agent Tool and Plugin Security Guide, MCP Gateway and MCP Server Governance Guide, Top 10 MCP Security Risks.