Agent skills provide the procedure, meaning how an agent should do a task. MCP provides the connection to tools and data, meaning what the agent can reach. They work together, but they solve different problems. Skills govern behaviour, while MCP governs access to external capabilities and should be controlled separately.
Why This Matters for Security Teams
Agent skills and MCP are often confused because both affect what an AI agent can do, but they control different layers of risk. Skills define procedure and decision flow, while MCP defines access to external tools, systems, and data. That distinction matters because a safe prompt does not make unsafe reach disappear. Current guidance from the OWASP Top 10 for Agentic Applications 2026 and NHI research from AI Agents: The New Attack Surface report both point to the same issue: autonomous behaviour expands attack surface faster than most governance models can track.
This is where teams get caught out. A well-written skill can still drive an agent toward a harmful action if the MCP layer exposes sensitive tools, high-value data, or broad write privileges. In practice, many security teams encounter misuse only after an agent has already accessed data or executed a tool chain that no one intended during design.
How It Works in Practice
Think of skills as the operational playbook and MCP as the broker to capability. A skill may tell the agent how to classify a support ticket, draft a response, or trigger a workflow. MCP decides whether the agent can reach the CRM, issue a calendar update, query a database, or call an internal API. Because those layers are separate, they should also be governed separately.
For security teams, the practical question is not “Can the agent do the task?” but “What does the agent need to touch to do it safely?” That usually means limiting MCP servers to narrowly scoped tools, enforcing short-lived credentials, and reviewing every connector as if it were a privileged integration. The The State of MCP Server Security 2025 report from Astrix is a useful warning signal here: weak access scoping and hard-coded secrets in MCP deployments turn tool access into a persistence problem.
Modern guidance increasingly favors runtime policy decisions over static allowlists. That means policy-as-code, contextual authorization, and workload identity controls that can evaluate what the agent is trying to do at request time. Standards and research such as NIST AI Risk Management Framework and CSA MAESTRO agentic AI threat modeling framework both reinforce the same operational point: the agent’s procedure and its authority must be isolated. The NHIMG analysis of Moltbook AI agent keys breach shows how quickly exposed credentials become a control failure when tool access is broad and persistent.
These controls tend to break down when MCP connectors are treated like low-risk plugins in environments with production data, cross-domain writes, or chained tool execution because one compromised connector can become a path to lateral movement.
Common Variations and Edge Cases
Tighter MCP scoping often increases integration overhead, requiring organisations to balance development speed against the cost of maintaining more granular access policies. That tradeoff is real, especially when teams want skills to remain reusable across many workflows.
Best practice is evolving, but current guidance suggests three common patterns. First, some organisations centralize skills in a trusted orchestration layer and keep MCP highly restricted. Second, others allow broader MCP reach but enforce runtime approval for sensitive actions. Third, advanced implementations bind each agent to a workload identity so the platform can authorize tool use by task, context, and risk level rather than by a static role. The AI Agents: The New Attack Surface report is a reminder that many deployments already exceed their intended scope, which makes static trust assumptions fragile.
For practitioners, the key edge case is when skills are harmless in isolation but dangerous in combination with an over-permissioned MCP layer. That is why security reviews should examine both the behavior encoded in the skill and the external reach granted by MCP. The right control question is not whether the agent has a good procedure, but whether it has a justified path to every tool and dataset it can invoke. Where MCP is shared across teams or exposed to high-value systems, the model becomes much harder to govern cleanly.
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, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 | Agent skills and MCP both shape agent attack surface and tool abuse risk. |
| OWASP Non-Human Identity Top 10 | NHI-03 | MCP often relies on long-lived secrets and broad tool access, creating NHI exposure. |
| CSA MAESTRO | THR-2 | Separating orchestration logic from tool access is central to agent threat modeling. |
| NIST AI RMF | AI RMF applies to runtime governance, accountability, and risk evaluation for agents. | |
| NIST Zero Trust (SP 800-207) | PR.AC | MCP access should follow zero trust principles with continuous authorization checks. |
Map each agent skill and MCP connector to explicit abuse scenarios before enabling production access.
Related resources from NHI Mgmt Group
- What is the difference between human identity governance and AI agent governance?
- What is the difference between governing human access and governing AI agent access?
- What is the difference between managed identities and hardcoded secrets for AI agents?
- What is the difference between workload identity and API keys for AI agents?
