MCP governs how the agent reaches tools, while Skills govern how it chooses to use them. If those layers are approved separately, one can be safe while the other steers the agent into an unsafe action. Teams should treat them as one operating model so access, context, and audit all line up.
How MCP and Skills split the control plane
MCP and Skills are not duplicates. MCP is the transport and authorization layer that determines which tools, servers, or resources the agent can reach. Skills sit one layer above that and shape the action the agent decides to take once a tool is available. Governance has to cover both, because a safe connection model can still be paired with an unsafe instruction path.
The practical issue is separation of power. If MCP is approved in isolation, you may allow a tool path that is technically authenticated but operationally too broad for the task. If Skills are approved in isolation, you may allow a seemingly harmless capability that later invokes sensitive tools through an already-approved connector. The operating model only works when access scope and action scope are reviewed together.
That is why teams should think in terms of one decision chain: who or what is allowed to connect, what context it receives, and what it is allowed to do with that context. The stronger the autonomy, the more important it is to treat tool reachability and skill execution as a single governance surface rather than two unrelated reviews.
Where separate approval breaks down
Separate approval creates blind spots in both directions. A restricted MCP layer can still be bypassed in practice if an overly capable skill selects a permitted tool and uses it in a harmful sequence. A narrowly scoped skill can still become risky if it is wired to a broad mcp server that exposes high-impact operations, sensitive data, or privileged workflows.
This is especially important where Skills encode behaviour, routing logic, or task decomposition. The risk is not only direct misuse of a tool, but also indirect misuse through chaining, escalation by composition, and context leakage between steps. In those cases, the right question is not only “can the agent call the tool?” but also “under what conditions can the skill cause that call, and with what side effects?”
Governance should therefore look at the combination of tool surface, permission boundary, and action pattern. That means reviewing whether the MCP endpoint exposes only the minimum needed operations, whether the skill is bounded to the same purpose, and whether the resulting behaviour remains explainable enough for audit and incident response. A combined review is the only way to see the full blast radius.
What good governance looks like in practice
Good practice is to approve MCP and Skills against one common policy model, not two separate checklists. The policy should define which tools are in scope, which tasks are allowed, what data can flow into the skill, and what kinds of actions require extra control or explicit human approval. That keeps access, context, and audit aligned.
Teams should also verify that each skill has a clear purpose boundary and that each MCP connector has a clear trust boundary. If a skill can choose among multiple tools, the selection logic needs the same level of scrutiny as the tool permission itself. If an MCP server can reach sensitive systems, the attached skills should be constrained so they cannot turn broad connectivity into broad action authority.
MCP Security Guide is useful for the transport and authorization side of that review, while OWASP Agentic Skills Top 10 helps teams reason about the behaviour and misuse patterns of the skill layer. For the broader agent-side governance model, NHIMG’s agentic AI applications guide is a strong companion reference.
Risk and Threat Considerations
When MCP and Skills are governed separately, the system can fail at the seam between access and action. That seam is attractive to attackers and unsafe automation alike, because it lets one layer look compliant while the other produces the harmful outcome. The result is a control gap that is hard to spot in isolated reviews.
Failure mechanism: An agent is granted acceptable tool access through MCP, then a skill uses that access in an unexpected or overbroad way, such as chaining permitted calls into a sensitive workflow, expanding scope through context, or selecting a tool that was not reviewed under the same operating assumptions.
Impact: The organisation can end up with unauthorised data access, unintended side effects, privilege amplification, weak auditability, or incident response that cannot reconstruct why the action was taken. In practice, that means the real security boundary is not the connector alone or the skill alone, but the combination of both.
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 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Skills and MCP together govern agent authority and tool use. |
| ASI02 — Tool Misuse | The question centers on whether a skill can misuse permitted tools. | |
| Recommendation — Bind tool access and skill execution to the same privilege policy. Constrain skills so they cannot repurpose approved tools into unsafe actions. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | MCP approval still needs function-level limits on what the agent may invoke. |
| Recommendation — Enforce function-level authorization for every callable tool or endpoint. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Combining MCP and Skills is fundamentally a least-privilege problem. |
| AU-2 — Event Logging | Joined governance needs auditable records of tool selection and action paths. | |
| Recommendation — Apply least privilege across both tool reachability and skill authority. Log tool selection, skill invocation, and resulting actions as one chain. | ||
Practitioner Guidance
What to prioritise: Review MCP and Skills as one control surface whenever a skill can influence tool choice, tool sequencing, or data passed into a tool. If you cannot explain the combined path in a single sentence, the governance model is probably too fragmented.
What to verify: Confirm that the skill’s allowed behaviours match the MCP connector’s permitted operations, including data scope, side effects, and escalation conditions. If the connector is broad but the skill is vague, treat that as a governance defect rather than a design detail.
Decision rule: If either layer can materially change the agent’s outcome, approve them together and document the combined blast radius. If a team cannot produce a joined access-and-action record, it should not rely on separate approvals as evidence of safety.
Practitioner takeaway: The control objective is not just to secure tool access or to constrain behaviour, but to ensure that the access the agent has and the action it takes are governed by the same policy intent.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org