Join our Newsletter — 33% off our NHI Course
Home FAQ Agentic AI & Autonomous Identity How should teams govern skills and MCP together…
Agentic AI & Autonomous Identity

How should teams govern skills and MCP together in production?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated August 18, 2026 Domain: Agentic AI & Autonomous Identity

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.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10A2Skills can steer agents into unsafe actions even when tools look allowed.
CSA MAESTROGOVGovernance must cover agent behaviour, tool access, and release accountability.
NIST AI RMFGOVERNDual-layer control needs accountability, traceability, and human oversight.
OWASP Non-Human Identity Top 10NHI-06MCP servers and skills both need lifecycle and provenance controls.
NIST CSF 2.0PR.AC-4Least privilege must apply to both instruction assets and tool permissions.

Establish governance for agent instructions and tool boundaries with clear accountability.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on August 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org