MCP and skills are complementary, not competing agent controls

At a glance

What this is: This is an analysis of why MCP and Skills are complementary for AI agents, with the central finding that runtime governance matters more than treating them as substitutes.

Why it matters: It matters because identity, access, and governance teams now have to manage how agents combine tools and instructions at runtime, not just whether a tool or skill is individually approved.

Context

The core governance problem is not whether AI agents use MCP or Skills, but whether a programme can control what they are allowed to reach, load, and do at runtime. MCP governs tool access and data connectivity, while Skills shape execution behaviour and task-specific output. The moment both are allowed to stack, the control problem shifts from static approval to runtime policy.

That shift matters for NHI and agentic AI governance because every added tool expands the reachable surface for an agent, and every added Skill expands the instruction set that can influence action. In practice, the question becomes whether the organisation can govern the assembled workflow, not just the individual parts.

Key questions

Q: What breaks when AI agents can chain tools through MCP without tight policy controls?

A: What breaks is the separation between request, authorisation, and execution. A single agent session can move from one system to another, combine partial permissions, and create a wider blast radius than any individual entitlement suggests. Traditional access reviews miss this because they rarely model chained tool behaviour in real time.

Q: Why do stacked MCP and Skill workflows increase governance risk?

A: Because each added component expands either the agent’s reachable systems or the instruction surface that shapes its actions. A workflow can remain compliant on paper while still becoming risky in execution if the assembled chain can reach data, tools, or destructive actions that were not intended for the task.

Q: How should teams govern AI agents that use tools during evaluation?

A: Treat the agent’s permissions as part of the test itself. If the system can browse, fetch, or modify external resources, reviewers should check whether those actions were necessary, bounded, and policy-compliant. The key governance question is whether the agent used delegated authority in a way you would permit outside the benchmark.

Q: What is the difference between agent skills and MCP?

A: 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.

Technical breakdown

How MCP and Skills separate tool access from task behaviour

MCP is the protocol layer that lets an agent connect to tools and data sources. Skills are the instruction layer that tells the agent how to use those tools for a specific task. That separation matters because access and behaviour are not the same control problem: one governs reachability, the other governs execution quality and task framing. When teams confuse the two, they overestimate what a single approval or a single policy can control. The architectural risk is that a well-scoped tool can still be used in an unsafe way if the instruction set is broad, stale, or poorly governed. See the [[L1|OWASP Agentic Applications Top 10]]. Read OWASP Agentic Applications Top 10.

Practical implication: Treat tool reach and task instructions as separate control planes, and review both before an agent is allowed into production.

Why stacked agent workflows expand the identity and access surface

The article’s examples show that one workflow can combine multiple MCP servers with multiple Skills in a single run. That creates more than convenience. It creates a larger operational surface, because the agent can now touch web search, browser automation, email, document parsing, and output generation in one chain. Each new connection changes the trust boundary, the permission set, and the blast radius if one component is mis-scoped. This is why agent governance cannot stop at listing approved tools. It has to model the entire delegated workflow, including the identity under which the agent acts and the systems it can reach during execution. See the AI Agent Authorisation Guide.

Practical implication: Map the full tool chain behind each agent workflow and classify the privilege expansion created by each added server or Skill.

What runtime governance changes in agent identity control

Runtime governance turns agent assembly into a controlled contract rather than an informal configuration choice. The article describes Blueprints, scoped identity, revocation when the contract changes, and tool-level filtering as the mechanism for keeping agent behaviour within policy. That is important because agentic risk is not only about whether a tool exists. It is about whether the agent can activate it under the right identity at the right time. In practice, governance needs to move from static allowlists to policy-bound execution, where the assembled workflow is what gets authorised, observed, and revoked when the task changes. Read Zero Trust for AI Agents.

Practical implication: Tie identity, tool reach, and revocation to the runtime contract for each agent workflow, not to a one-time onboarding approval.

Threat narrative

Attacker objective: To obtain broader agent capability than intended and use that expanded access to reach data, generate outputs, or trigger actions outside the original governance boundary.

1. Legitimate agent access is assembled from approved tools and Skills, then expanded as the workflow loads additional capabilities at runtime.
2. Scope drift occurs when the agent combines multiple tools and instruction sets in one task, widening the effective permission boundary beyond the original intent.
3. Misuse or unsafe action follows when destructive or sensitive tools remain reachable inside the workflow even though the task never needed them.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Stacked AI workflows create a governance problem, not a product choice problem. The article is right that MCP and Skills are complementary, because the real issue is not which one wins but how the assembled workflow is governed. Once an agent can combine tools and instructions at runtime, the control boundary moves from component approval to orchestration control. Practitioners should stop evaluating these as substitutes and start governing them as one delegated execution chain.

Runtime stacking changes the blast radius of every agent decision. Each additional MCP server adds reachable systems, and each additional Skill adds more instruction surface that can shape how those systems are used. That means risk compounds even when every individual component looks reasonable in isolation. The relevant governance unit is the complete agent session, not the tool catalog or the Skill library on its own.

MCP gives agents reach, but Skills determine how that reach is used. That distinction creates a new kind of policy problem: access control alone cannot tell you whether the agent will use a tool safely, and instructions alone cannot limit which systems the agent can touch. The most useful governance model is one that binds tool reach, task instructions, and identity into a single runtime contract.

Shadow AI is increasingly a composition problem. The article’s emphasis on discovery is important because unmanaged risk often emerges when approved building blocks are combined outside central oversight. If a team can add a new MCP server or Skill without visible ownership, the organisation may not even know which workflows now exist. Shadow AI and AI Agent Discovery Guide is the next step for teams trying to surface those hidden assemblies before they become durable operating paths.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: Zero Trust for AI Agents

What this signals

Identity governance for agents is moving from static entitlement review to runtime assembly control. The important question is no longer whether a tool or instruction set is approved in isolation. It is whether the organisation can see and govern the exact combination of agent, MCP server, and Skill that is active in a given session.

Runtime stacking will become the dominant control failure mode in agent programmes. A workflow that looks harmless at onboarding can become risky once teams add another data source, another instruction layer, or another delegated action path. Programmes that cannot track those changes will struggle to prove that policy still matches execution.

Credential scope is only half the issue; workflow scope matters just as much. When an agent’s ability to act changes as it loads different tools and Skills, access reviews alone will miss the real exposure. Teams need lifecycle governance for the assembled agent path, not just the underlying account.

For practitioners

• Define the agent runtime contract Document which MCP servers, Skills, and identities are permitted for each workflow before it moves beyond pilot use. See the AI Agent Authorisation Guide.
• Separate tool approval from instruction approval Review MCP connectivity and Skill content as distinct governance decisions, because each changes risk in a different way.
• Scope destructive tools out of routine workflows Block actions such as delete, write, or submit unless the task explicitly needs them and the workflow owner can justify them.
• Track the full agent chain for auditability Record which tools, Skills, and data sources were actually used in a session so investigators can reconstruct what happened.

Key takeaways

• MCP and Skills solve different problems, but the governance failure appears when teams treat them as competing substitutes instead of complementary controls.
• The real risk is not the existence of either component in isolation. It is the way agent workflows can stack tools, instructions, and identities into a larger operational surface.
• Practitioners should govern the assembled runtime path, because that is where privilege, reach, and accountability actually combine.

Related NHI Mgmt Group resources: OWASP Agentic Applications Top 10 · AI Agent Authorisation Guide · Shadow AI and AI Agent Discovery Guide · AI Agent Observability, Audit and Incident Response Guide

Key terms

• MCP: Model Context Protocol, an open way for AI agents to connect to tools and data sources. It improves interoperability, but it also introduces a shared integration layer that must be governed carefully because the protocol can widen access across many systems at once.
• Skill: A skill is a modular instruction package that teaches an agent how to perform a task at runtime. It can include a markdown instruction file, metadata, scripts, and supporting documents. In agentic environments, a skill is not passive documentation. It is an active control input that can shape behaviour, tool use, and execution.
• Runtime Governance: Runtime governance is the set of controls that verify what a system or agent is actually doing after deployment. It combines monitoring, authorization checks, and access validation so teams can detect drift, misuse, or excessive privilege in motion rather than assuming build-time policy still holds.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.