Agent Skills vs MCP: Two Standards, Two Security Models

In late 2024 and 2025, Anthropic introduced (and later open-governed) two influential approaches to extending AI agents: the Model Context Protocol (MCP) and the Agent Skills specification. While both aim to make agents more capable, they represent fundamentally different architectural philosophies—with profound implications for security.

MCP was open-sourced in November 2024 as a protocol for connecting agents to external tools and data sources via well-defined server boundaries. Agent Skills, by contrast, became an open standard in December 2025: a simple folder-based packaging format (SKILL.md + optional resources/scripts) that tools like Claude Code and OpenAI Codex can load and follow.

Remarkably, both standards originated from Anthropic, yet they take opposite approaches to isolation, credential management, and code execution. Agent Skills prioritizes flexibility and dynamic capability expansion, while MCP emphasizes security boundaries and process isolation. In December 2025, Anthropic donated MCP to the newly formed Agentic AI Foundation (AAIF) under the Linux Foundation, signaling MCP's evolution toward vendor-neutral governance alongside OpenAI's AGENTS.md and Block's goose framework.

To understand the practical security implications of these different approaches, we'll examine how they're implemented in real-world systems. OpenClaw — a popular open-source AI assistant by Peter Steinberger — provides an excellent case study, as it implements Agent Skills and has spawned a thriving skill marketplace on ClawHub.

This post provides a technical comparison of both approaches, focusing on their security implications for developers and organizations considering either platform.

Architecture Overview: Agent Skills vs MCP Servers

The Agent Skills Specification

The Agent Skills specification defines a simple, folder-based format for extending AI agents with specialized capabilities. It was published as an open standard in late 2025 and is intentionally minimal: it standardizes packaging and metadata, but leaves execution semantics to implementers.

• A SKILL.md file with YAML frontmatter and natural language instructions
• Optional scripts and resources (templates, assets, helper files)
• Templates and assets the agent can use

The specification itself is intentionally minimal—it defines the format and metadata structure but leaves execution details to implementers. This flexibility has led to adoption by Claude Code, OpenAI's Codex CLI, Cursor, and other AI coding assistants.

For example, OpenAI documents "Codex skills" as folders with a SKILL.md (name + description + instructions) that "build on the agent skills specification." See: https://developers.openai.com/codex/skills/

Agent Skills Implementation: OpenClaw

OpenClaw is a useful case study because it combines Agent Skills with an in-process plugin model.

Skills are primarily a discovery + instruction mechanism: a folder containing SKILL.md and optional resources/scripts. Skills can be installed from ClawHub and then discovered/loaded by the agent at runtime.

Plugins, on the other hand, are executable TypeScript modules loaded at runtime (via jiti) and run in the same Node.js process as the OpenClaw Gateway. Plugins can register tools, commands, RPC methods, HTTP handlers, background services—and they can also reference skill directories via the plugin manifest.

OpenClaw’s own documentation is explicit about the trust boundary: plugins run in-process, so they must be treated as trusted code. See:

• Plugins: https://docs.openclaw.ai/plugin
• Gateway security notes: https://docs.openclaw.ai/gateway/security

MCP's Server Architecture

MCP takes a fundamentally different approach. Each MCP server runs as a separate process with its own runtime, filesystem access, and credential scope. The host (client) communicates with servers using JSON-RPC over a supported transport:

• Streamable HTTP
• stdio
• SSE (deprecated)

This separation creates a clearer isolation boundary: each server can be sandboxed, containerized, or run under a dedicated OS user, and it only receives the secrets and permissions it needs for its specific integration.

Credential Management: Specification vs Implementation

Agent Skills Specification

The Agent Skills specification itself is silent on credential management. It defines how to structure skills but doesn't prescribe:

• Where credentials should be stored
• How skills should access secrets
• Whether skills should be isolated from each other
• Authentication/authorization mechanisms

This design choice makes the spec flexible but delegates security decisions to implementers. Different implementations can make vastly different choices.

OpenClaw's Implementation Approach

OpenClaw persists sensitive configuration and credentials in a local state directory (often under ~/.openclaw/, or $OPENCLAW_STATE_DIR/). Depending on how you configure the system, this can include API keys, OAuth tokens, model "auth profiles," and channel credentials. OpenClaw’s security documentation lists these locations explicitly.

~/.openclaw/ (or $OPENCLAW_STATE_DIR/)
├── credentials/                 # channel creds, oauth imports, allowlists, ...
│   ├── oauth.json
│   └── whatsapp/<accountId>/creds.json
├── agents/<agentId>/agent/
│   └── auth-profiles.json       # model auth profiles (API keys / OAuth tokens)
└── sessions/                    # logs / transcripts (can contain sensitive data)

Key characteristics:

1. Shared local blast radius: if untrusted code runs on the host (e.g., via plugins, or via user-followed "setup" commands), it can read files from the state directory and environment variables.
2. Cross-integration exposure: secrets for different integrations can coexist on the same machine and become reachable to any code that has local read access.
3. Transcript/log leakage: depending on configuration, logs or conversation artifacts may unintentionally contain sensitive values.

This reduces blast radius, but it does not make MCP "automatically safe." A malicious or compromised MCP server can still exfiltrate the credentials it is given, and prompt injection can still trick a host into calling tools in unsafe ways. MCP helps by making boundaries explicit and enforceable—but operational hardening (least-privilege credentials, network egress controls, review of servers, and user-consent UX) still matters.

The security issue is not a single "bug" - it’s that local persistence + broad local execution makes credential theft a realistic failure mode when supply-chain or social-engineering attacks succeed.

MCP's Isolation Model

MCP servers receive credentials through their configuration, isolated per server:

{
  "mcpServers": {
    "trello": {
      "command": "npx",
      "args": ["-y", "@trello/mcp-server"],
      "env": {
        "TRELLO_API_KEY": "...",
        "TRELLO_TOKEN": "..."
      }
    },
    "gmail": {
      "command": "npx",
      "args": ["-y", "@gmail/mcp-server"],
      "env": {
        "GMAIL_CREDENTIALS": "..."
      }
    }
  }
}

Key characteristics:

1. Process isolation: Each server runs in its own process with its own environment
2. Scoped credentials: The Trello server cannot access Gmail credentials
3. No shared memory: Servers cannot inspect each other's memory or state
4. Host-controlled: The MCP host (like Claude Desktop) mediates all tool invocations

Code Execution & Trust Boundaries

The Skills Trust Model

Agent Skills themselves are a packaging format, but in real ecosystems they frequently become an execution path:

1. Skills can include scripts/resources and "setup" instructions.
2. Users (or agents acting on behalf of users) may follow these instructions.
3. OpenClaw plugins run in-process and can reference skill directories—so installing extensions can effectively grant code execution within the Gateway process.
4. The official docs emphasize that extensions/plugins should be treated as trusted code and ideally allowlisted.

This creates several security considerations:

Social-engineering execution paths (ClickFix-style): malicious skills can present "prerequisites" or "one-line setup steps" that trick users into executing attacker-controlled commands.

High privilege on the host: once code runs locally (or in-process via plugins), it can read local secrets, access the filesystem, and make outbound network requests - often enough to exfiltrate tokens and API keys.

No capability system: There's no way to grant a skill limited permissions (e.g., "read-only filesystem" or "network access only to api.trello.com")

MCP's Permission Model

MCP servers operate under different constraints:

1. Process boundaries: OS-level isolation prevents memory access between servers
2. Explicit tool invocation: The host must explicitly call each tool; servers cannot execute code arbitrarily
3. Transport layer: stdio communication means servers cannot open network sockets without host involvement
4. No filesystem access by default: Servers only access what their implementation explicitly includes

While MCP servers still execute code, the attack surface is constrained:

• A malicious server cannot read credentials from other servers
• The host can terminate misbehaving servers
• Network access is controlled by the server implementation itself, not granted by the protocol

Recent Security Incidents

ClawHub Malicious Skills

In late January 2026, security researchers from KOI identified 341 malicious skills on ClawHub exhibiting:

• Credential exfiltration: Sending API keys to external servers
• Session/token theft: Stealing OAuth tokens for later use
• Keylogging / infostealer behavior: Targeting browser and system secrets
• Remote access / reverse-shell patterns: Establishing interactive control after execution

Across multiple campaigns, a common tactic was to abuse "installation" or "prerequisite" instructions (fake setup steps) to trigger execution on the victim host.

These skills were published by creating accounts with names similar to legitimate developers (typosquatting) and offering enhanced versions of popular skills.

Exposed OpenClaw Instances

Independent researchers also reported large numbers of OpenClaw gateways discoverable via Shodan on the default port (18789). The exact impact depends on configuration, but the risk pattern is consistent:

• Internet exposure of a control surface that was designed for localhost / trusted networks
• Misconfiguration or unsafe "break-glass" auth settings
• Increased likelihood that attackers can interact with the Gateway and/or target local state for credential theft

OpenClaw’s docs explicitly recommend secure contexts (HTTPS/localhost) and warn about insecure auth downgrade options. Treat "expose the gateway to the public internet" as a high-risk posture.

Mitigation Strategies

For OpenClaw Users

If you're using OpenClaw, consider these security measures:

1. Vet skills carefully: Review source code before installation, especially for skills requiring credentials
2. Use credential brokers: Services like Composio can proxy OAuth-based API calls (though this doesn't help with API keys)
3. Network isolation: Run OpenClaw in a restricted network environment
4. Regular audits: Monitor logs and session transcripts for unexpected credential exposure
5. Limit exposed ports: Never expose gateway ports (18789) to the public internet
6. Consider containerization: Run OpenClaw in Docker with limited capabilities

For MCP Developers

MCP's architecture provides stronger isolation, but best practices still apply:

1. Review server implementations: Even isolated servers can have vulnerabilities
2. Use official servers when available: Prefer verified implementations from tool vendors
3. Audit configuration files: Ensure claude_desktop_config.json uses appropriate credential scoping
4. Monitor server behavior: Watch for unexpected network activity or resource usage
5. Keep servers updated: Security patches are important even in isolated environments

The MCP Registry Ecosystem and AAIF Governance

One structural advantage of MCP is its open governance under the AAIF and the official MCP Registry, launched in September 2025. The registry provides:

• Namespace verification: Publishers must prove ownership via GitHub OAuth, DNS challenge, or OIDC tokens
• Metadata validation: Server declarations are validated against schemas
• Community moderation: Users can flag malicious or impersonating servers
• Sub-registry federation: Organizations can build private registries while maintaining compatibility

With MCP now under the Agentic AI Foundation alongside OpenAI's AGENTS.md and Block's goose, the governance model ensures:

• Neutral stewardship: No single vendor controls the protocol's direction
• Transparent evolution: Technical decisions made through community SEP process
• Enterprise backing: Platinum members (AWS, Google, Microsoft, Bloomberg, Cloudflare) signal production readiness
• Long-term stability: Linux Foundation's proven track record with Kubernetes, Node.js, PyTorch

This creates a more trustworthy discovery and governance mechanism compared to marketplaces without comparable verification systems.

To make MCP adoption safer at enterprise scale, I built LightNow - a trust and governance layer with verified publishers, policy-based allowlisting, and version-level trust signals to support rollout and compliance decisions.

Architectural Trade-offs

Both approaches involve trade-offs:

Agent Skills (OpenClaw Implementation)

Advantages:

• Flexibility: Direct code execution enables complex integrations without protocol overhead
• Performance: In-process execution avoids IPC latency
• Development velocity: Skills can be written quickly without SDK boilerplate
• Self-modification: The AI can write and deploy skills on-the-fly
• Simplicity: SKILL.md format is minimal and easy to understand

Challenges:

• Security boundaries: No isolation between skills or from core process (in OpenClaw's implementation)
• Credential exposure: Shared environment makes secrets accessible to all code
• Supply chain risk: Arbitrary code execution during installation
• Difficult auditing: Dynamic code loading complicates security review
• Implementation variance: The spec doesn't mandate security properties

MCP

Advantages:

• Process isolation: Strong security boundaries between servers
• Credential scoping: Each server only accesses its own secrets
• Auditable communication: JSON-RPC messages can be logged and inspected
• Vendor neutrality: Official registry with governance under the AAIF
• Enterprise ready: Designed with security and compliance in mind
• Neutral governance: Linux Foundation stewardship ensures long-term independence

Challenges:

• Complexity: Server development requires understanding SDK and protocol
• IPC overhead: Cross-process communication adds latency
• Less dynamic: Servers must be pre-configured; no runtime self-modification
• Configuration burden: Each server needs explicit setup in host config
• Learning curve: More concepts to understand than a simple SKILL.md file

Conclusion

Agent Skills and MCP represent two distinct philosophies for extending AI agents - both originating from Anthropic, yet with fundamentally different security models:

Agent Skills provides a flexible, minimal specification that allows implementers to choose their execution model. OpenClaw's implementation prioritizes developer velocity and AI self-modification, running skills directly in-process. This creates powerful capabilities but requires careful security consideration around credential management and code trust.

MCP was designed from the ground up with security boundaries in mind, running each integration in a separate process with scoped credentials. Anthropic's donation of MCP to the AAIF under the Linux Foundation (December 2025) signals its maturation from an internal tool to critical open infrastructure, with neutral governance alongside OpenAI's AGENTS.md and Block's goose.

The fact that Anthropic developed both standards is particularly noteworthy - it demonstrates that even within a single organization, different use cases demand different security-flexibility trade-offs:

• Agent Skills: Optimized for rapid capability expansion and AI-assisted development
• MCP: Optimized for production deployments with strict security requirements

Neither approach is inherently "better" - the right choice depends on your use case:

• For personal experimentation and AI-assisted coding where you control all skills: Agent Skills implementations like OpenClaw or Claude Code may be ideal
• For production deployments with third-party integrations: MCP's process isolation provides better security guarantees
• For organizational use with compliance requirements: MCP's governance under the AAIF and explicit permission model may be necessary
• For enterprise environments: Consider MCP with proper gateway infrastructure (as discussed in the AAIF announcement)

As the agentic AI ecosystem matures under the stewardship of the AAIF, we may see convergence between these approaches. The Agent Skills specification could evolve to include security recommendations, while MCP could develop more dynamic configuration mechanisms. We might even see hybrid implementations that use Agent Skills for defining capabilities but MCP for executing them securely.

For now, understanding these architectural differences - and recognizing that both came from the same innovative thinking at Anthropic - helps developers and organizations make informed decisions about which platform fits their security posture and use case requirements.

The AAIF's formation with platinum members including AWS, Google, Microsoft, Bloomberg, and Cloudflare signals that the industry recognizes the need for open, neutral governance of these critical standards. Whether you choose Agent Skills or MCP, the future of agentic AI is being built on open foundations.