Skills and MCP are complementary, but governance is the gap

At a glance

What this is: This is an analysis of why Skills and MCP are complementary for AI agents, and why the governance gap sits in how context and approvals are controlled.

Why it matters: IAM and NHI teams need to govern both tool access and the instructions that shape agent behaviour, or autonomous systems can use approved access in unsafe ways.

Context

Skills and MCP both sit in the agent control stack, but they solve different governance problems. MCP governs how an agent reaches tools and data. Skills govern what context and instructions the agent loads before deciding how to use those tools.

The security issue is not whether agents can connect to systems, but whether they can compose actions from stale context, incomplete instructions, or unsafe defaults. In production, that makes tool access, instruction approval, and auditability part of the same control surface.

Obot’s article is framed around a live demo from Pedro Rodrigues at the MCP Dev Summit, where the risk was not hypothetical. The example showed how an agent could produce an insecure outcome when the context layer failed to steer it toward the safe path.

Key questions

Q: What breaks when agents have MCP access but no governed skill context?

A: The agent may use a valid tool path to produce an unsafe outcome because it lacks the instructions that tell it when to consult current policy or documentation. That creates a governance gap where capability exists, but safe use does not. In production, the failure is not access denial. It is authorised behaviour that bypasses intended controls.

Q: Why do Skills and MCP need to be governed together?

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

Q: What are the signs that an agent is relying on stale context?

A: Look for repetitive outputs that mirror known patterns even when current documentation exists, tool calls that skip available search or reference steps, and workflows that ignore environment-specific defaults. Those signals suggest the agent is defaulting to training data rather than current instructions. That is where security mistakes usually begin.

Q: How should security teams govern agent skills that can be loaded from external sources?

A: Treat externally loaded skills as privileged inputs, not ordinary content. Security teams should require provenance checks, approval gates, and runtime authorization before an agent can execute them. The key is to control what the agent may trust at the moment of use, because static review alone does not prevent malicious instructions from becoming active inside a live session.

Technical breakdown

How MCP and Skills split the control plane

MCP is the transport and authorization layer for tool access, while Skills are the instruction layer that tells an agent when and how to use those tools. The practical distinction matters because an agent can have valid protocol access and still behave unsafely if it loads the wrong context or skips the right documentation. In production, the security boundary is not just whether the agent can call a tool, but whether the instructions that shape that call are approved, current, and scoped to the task. That is a control-plane problem, not a model problem.

Practical implication: Treat protocol access and instruction governance as separate controls that must both be approved before an agent can act.

Why agents fall back to stale training data

Pedro Rodrigues’ core point is that agents are lazy about leaving their training data unless something actively pushes them to fetch current context. That means an available search or docs tool does not guarantee safe use. If the agent is not instructed to consult current guidance, it may generate familiar-looking but incorrect logic, especially around security-sensitive behaviour such as database access patterns, permission boundaries, or policy-enforced defaults. Skills are the mechanism that can encode that prompt-to-check step without bloating every tool description.

Practical implication: Build explicit context triggers into skills so the agent is told when to consult current policy or documentation.

Why skills become part of the attack surface

Once skills influence execution choices, they stop being harmless metadata and become governed artefacts. A skill can steer an agent toward a safe workflow or toward a harmful one if its instructions are stale, copied from an untrusted source, or approved without review. That makes provenance, approval, and registry control essential. The article’s broader point is that enterprises should not treat the skill layer as separate from the MCP layer, because both shape the same runtime decision path. If one layer is governed and the other is not, the control plane is incomplete.

Practical implication: Register, approve, and audit skills with the same discipline you apply to agent tools and connectors.

NHI Mgmt Group analysis

Skills governance is now part of the agent control plane, not a separate content problem. Once skills determine when an agent consults documentation and how it uses tools, they become governance artefacts with real security impact. That means approval, provenance, and visibility must extend beyond connectors and into instruction packages. The practitioner conclusion is straightforward: if skills can change runtime decisions, they must be governed like production access paths.

Agent safety fails when organisations assume tool availability equals safe tool use. MCP can make a service reachable, but it cannot guarantee that the agent will choose the right workflow or consult the right context. That assumption breaks when the model falls back to training data or skips current documentation. The implication is that governance must cover the decision to use the tool, not just the permission to reach it.

Context debt is the named governance gap in this article. The article makes clear that the real failure mode is not missing capability but stale or missing context at the moment of action. Context debt: the growing gap between what an agent is allowed to do and the current instructions needed to do it safely. The practitioner conclusion is to treat context freshness as a control objective, not an implementation detail.

Supply chain discipline must now extend to skills as runtime guidance objects. The moment a skill can steer agent behaviour, unvetted markdown becomes a control risk. That widens the attack surface from infrastructure to instruction provenance, which is exactly where many teams are least mature. The practitioner conclusion is to apply the same approval and audit expectations to skills that you already apply to privileged integrations.

Runtime governance for agents depends on separating capability from instruction authority. The article shows that a compliant protocol and a helpful skill are only safe when both are bounded by policy. That is a useful distinction for NHI governance because it mirrors a familiar pattern: access alone is not the same as authorised use. The practitioner conclusion is to govern both layers as one operating model, not as two separate projects.

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: MCP Security Guide

What this signals

Context debt: agent programmes now need a control objective for the freshness of instructions, not just the reachability of tools. If the agent can act on stale context, the organisation has effectively outsourced decision quality to whatever the model last learned, which is a poor substitute for governed runtime guidance.

Security teams should expect the skill layer to become a governance surface wherever agents are allowed to compose actions dynamically. The practical question is no longer only who can call the tool, but who can influence the instruction set that shapes the call. That is where production controls need to move next.

For practitioners

• Govern MCP and skills together Define one control plane for tool access, instruction approval, provenance, and audit so the protocol layer and the context layer are reviewed as a unit.
• Approve skills before production use Require review for any skill that changes agent decisioning, especially if it can steer database writes, data retrieval, or policy-sensitive workflows.
• Force current-context checks in skills Embed explicit prompts to read current documentation or policy before acting when the task touches permissions, data exposure, or security defaults.
• Registry-control the skill supply chain Track who authored each skill, which agents loaded it, and which environments approved it so untrusted instructions do not enter production by accident.
• Test for policy bypass in agent workflows Run scenarios where an agent has valid tool access but incomplete context, then verify whether the workflow still respects row-level security and other enforcement points.

Key takeaways

• Agents can have valid tool access and still produce unsafe outcomes if the instruction layer is not governed with the same rigor as the protocol layer.
• The article’s central lesson is that context freshness, approval, and provenance now matter as much as connectivity in production agent systems.
• Security teams should manage skills, tools, and audit as one control plane or they will leave a policy bypass path open.

Key terms

• Skills Registry: A catalog of reusable multi-tool workflows that an agent can invoke to complete a task. It extends governance from single tool access to packaged action sequences, which means evaluation, approval, and revocation need to follow the skill itself, not just the underlying tools.
• Context debt: A governance condition where security tools hold partial or stale information about data, identity, or workflow state, so decisions are made with incomplete context. The result is noisy enforcement, missed risk, and controls that cannot keep pace with distributed cloud and AI use.
• Protocol Layer Separation: The practice of treating tool access and inter-agent communication as distinct identity boundaries. For agentic systems, this prevents teams from applying one auth model everywhere and overlooking the different trust decisions each layer requires.
• Instruction Layer: The hidden layer where the agent’s intent is expressed, such as a prompt, system message, or text embedded in a document or webpage. This layer matters because the action alone may look benign, while the real decision driver sits outside the normal controls and logging that track user activity.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.