Notifications
Clear all
Topic starter
18/08/2026 2:56 pm
TL;DR: Skills do not replace MCP, but they change how agents decide when to use tools, according to Obot’s coverage of Pedro Rodrigues’ MCP Dev Summit talk. The practical issue is governance: if agents can compose actions from stale context or unvetted instructions, the control plane must cover both protocol access and skill approval.
NHIMG editorial — based on content published by Obot: Skills Are Not the MCP Killer
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should teams govern skills and MCP together in production?
A: Treat MCP as the protocol boundary and skills as governed instruction assets.
Q: Why do AI agents create risk even when they stay within approved permissions?
A: AI agents can be authorised correctly and still produce harmful outcomes because permission is not the same as intent or behavioural appropriateness.
Q: What breaks when an agent can call tools without user context?
A: Per-user filtering, scoped authorisation, and clean audit attribution all become unreliable.
Practitioner guidance
- Separate protocol governance from instruction governance Assign distinct owners, review paths, and audit requirements for MCP servers and skills so tool access and task guidance are governed independently.
- Require approved skills for production agent runs Maintain a registry of approved skills with versioning, provenance, and change control before any agent can load them in production workflows.
- Validate tool-specific failure modes in test workflows Test whether agent actions bypass underlying controls, such as PostgreSQL row-level security, when the agent composes outputs from incomplete context.
What's in the full article
Obot's full post covers the operational detail this analysis intentionally leaves for the source:
- The live MCP versus Skills demo sequence, including the four test modes and the exact failure reproduced on stage.
- Pedro Rodrigues' benchmark framing for why agents choose stale context unless prompted to search or load the right skill.
- Obot's control-plane model for governing MCP servers and a skill registry together in production.
- The discussion of how enterprise teams should curate, approve, and audit reusable agent skills.
👉 Read Obot's analysis of why Skills and MCP belong together →
Skills and MCP: what security teams need to govern in production?
Explore further
18/08/2026 3:38 pm
Skills and MCP are complementary control planes, not interchangeable solutions. MCP governs tool connectivity and execution path, while skills govern contextual instruction and task interpretation. Treating one as a replacement for the other creates blind spots in both authorisation and safe-use governance. The practitioner conclusion is simple: secure the protocol layer and the instruction layer as separate identity surfaces.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
- 48% of organisations say they cannot track and audit the data their AI agents access, creating a compliance and investigation blind spot.
A question worth separating out:
Q: How do security teams decide whether skills should be approved like code?
A: If a skill can change what an agent loads, how it interprets a task, or which systems it touches, it should be approved like a governed artefact. Teams should require ownership, review, version control, and rollback so the skill lifecycle is visible and enforceable.
👉 Read our full editorial: Skills and MCP are complementary, but governance is the gap
