Treat MCP as the protocol boundary and skills as governed instruction assets. That means separate ownership, approval, versioning, and audit for each layer. If an agent can load a skill and then act through an MCP server, both layers need lifecycle controls, because a safe tool can still be used unsafely when the instruction layer is unmanaged.
Why This Matters for Security Teams
Skills and MCP are often treated as separate engineering conveniences, but in production they form a single control plane for agent behaviour. MCP defines what a tool can reach, while a skill defines what the agent is instructed to do with that reach. If either layer is unmanaged, a well-scoped server can still be driven into unsafe actions through prompt manipulation, stale instructions, or unapproved skill loading. That is why governance has to cover approval, ownership, and audit at both layers, not just the transport boundary. This aligns with the risk themes in the NIST Cybersecurity Framework 2.0 and NHIMG’s Top 10 NHI Issues, where lifecycle control is as important as access control. The practical failure is that teams approve tools but never govern the instruction assets that decide how those tools are used. In practice, many security teams discover that gap only after an agent has chained a permitted MCP action into an unintended workflow, rather than through intentional design review.
How It Works in Practice
Production governance should separate the mcp server lifecycle from the skill lifecycle, then join them at policy enforcement and audit. MCP servers need asset ownership, approved capability scopes, secret handling, and runtime logging. Skills need source control, versioning, review, and explicit promotion criteria because they are executable instruction assets, not informal prompts. The most reliable pattern is to treat skills like governed content with release management, while treating MCP like a bounded protocol interface with explicit tool permissions. That is consistent with the risk model described in The State of MCP Server Security 2025 and the OWASP Agentic AI Top 10, both of which show how quickly unmanaged agent pathways become security gaps.
- Assign one owner for MCP server approval and a different owner for skill approval, with shared change records.
- Require version pinning for every skill used in production so an agent cannot silently drift to a new instruction set.
- Apply request-time policy checks before the agent loads a skill or invokes a tool through MCP.
- Log which skill version triggered which MCP call, then retain that mapping for incident response and audit.
- Revoke or quarantine both the skill and the mcp integration if either layer shows unsafe behaviour.
Current guidance suggests policy-as-code should sit between the agent and both layers, rather than only at the MCP server, because the instruction layer can be the actual source of misuse. This becomes especially important when a single agent can load multiple skills dynamically. These controls tend to break down in fast-moving development environments where skills are copied informally between teams and MCP servers are shared across many agents because ownership and provenance become ambiguous.
Common Variations and Edge Cases
Tighter skill governance often increases release overhead, requiring organisations to balance faster agent iteration against stronger change control. That tradeoff is especially visible when teams want reusable skills across many MCP-backed workflows. The safest approach is to maintain a curated skill catalog with approval tiers: low-risk operational skills can move faster, while skills that can trigger write actions, data export, or privileged lookups require deeper review. Best practice is evolving here, and there is no universal standard for how much semantic review a skill should receive before promotion.
Edge cases usually appear when one MCP server serves several business units, or when skills are generated by users rather than central engineering. In those environments, provenance matters as much as permissioning. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because it frames identity controls as lifecycle controls, which is the right lens for both server and skill management. If audit teams cannot tell which skill version produced a given MCP action, the governance model is not production-ready. Where agents are allowed to self-select skills from a shared library, the risk rises further because the instruction layer can change behaviour without any change to the MCP boundary.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Skills can steer agents into unsafe actions even when tools look allowed. |
| CSA MAESTRO | GOV | Governance must cover agent behaviour, tool access, and release accountability. |
| NIST AI RMF | GOVERN | Dual-layer control needs accountability, traceability, and human oversight. |
| OWASP Non-Human Identity Top 10 | NHI-06 | MCP servers and skills both need lifecycle and provenance controls. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege must apply to both instruction assets and tool permissions. |
Establish governance for agent instructions and tool boundaries with clear accountability.
