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 solve different problems, with a live demo showing that tool access alone can bypass PostgreSQL row-level security if agents act on outdated assumptions.

Why it matters: It matters because identity and access teams now have to govern both the agent’s tool authority and the instruction layer that shapes how those tools are used.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.

👉 Read Obot's analysis of why Skills and MCP belong together

Context

Skills and MCP are often discussed as if one should replace the other, but they solve different identity and control problems. MCP governs how an agent reaches tools and data sources, while skills govern what context and instructions the agent brings to the task. For teams running agentic workflows, that distinction matters because tool access without governed instructions can still produce unsafe outcomes.

The security concern is not just capability exposure, but decision quality at runtime. In the demo described by Obot, the agent had write access and produced a view that bypassed row-level security because it relied on an assumption it did not verify. That is a governance problem for autonomous system access, not a simple tooling preference. The starting position is increasingly typical in enterprises experimenting with agentic AI.

For identity teams, the real question is how to govern the full agent context layer: authorization to tools, provenance of instructions, approval of reusable skills, and auditability of what was loaded during execution. That places this topic squarely in NHI governance, with emerging overlap into agentic AI control patterns and privilege containment.

Key questions

Q: How should teams govern skills and MCP together in production?

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

Q: Why do AI agents create risk even when they stay within approved permissions?

A: AI agents can be authorised correctly and still produce harmful outcomes because permission is not the same as intent or behavioural appropriateness. If an attacker manipulates the session mid-flight, the agent may keep acting inside scope while exfiltrating data, taking destructive steps, or chaining actions that no human would have approved.

Q: What breaks when an agent can call tools without user context?

A: Per-user filtering, scoped authorisation, and clean audit attribution all become unreliable. The system may return too much data, apply one shared permission set to everyone, or record only that an agent executed a task. In practice, that creates hidden overprovisioning and makes incident review much harder.

Q: How do security teams decide whether skills should be approved like code?

A: If a skill can change what an agent loads, how it interprets a task, or which systems it touches, it should be approved like a governed artefact. Teams should require ownership, review, version control, and rollback so the skill lifecycle is visible and enforceable.

Technical breakdown

Why MCP access can still bypass application controls

MCP is an integration protocol, so it gives an agent authenticated access to tools, resources, and actions, but it does not guarantee the agent will use those tools correctly. In the example described, the agent created a PostgreSQL view and assumed the database policies below it would still enforce row-level security. PostgreSQL views can bypass RLS unless security_invoker is set, which means the issue is not access to the database, but how the agent composes SQL from context it did not verify. Practical implication: treat tool access and safe use of the tool as separate control problems.

Practical implication: govern database-write tools with explicit execution constraints, not just with authentication and authorization to the MCP server.

How skills change the agent context layer

Skills are a context-loading mechanism, not a substitute for tool access. They let an agent pull in task-specific instructions only when needed, which reduces context bloat and can force the agent to consult the right documentation before acting. That changes security because the control question becomes whether the skill itself is approved, current, and safe to load. In production, skills become a policy-bearing artifact, which means they need ownership, review, and lifecycle controls like any other governed identity asset. Practical implication: treat skills as controlled content, not informal prompts.

Practical implication: place skills under approval, versioning, and audit controls, just as you would for privileged automation logic.

Why the pilot and co-pilot model is the right mental model

The talk’s strongest framing is that MCP is the pilot and skills are the co-pilot. MCP handles connectivity and execution, while skills provide operational guidance and task-specific judgment. That separation matters because it prevents teams from overloading tool definitions with workflow policy and security guidance that should live elsewhere. It also clarifies why neither layer is complete on its own. Without MCP, skills cannot act. Without skills, MCP can act unsafely. Practical implication: architect the two layers separately, then govern their interaction points.

Practical implication: define ownership for protocol governance and instruction governance as distinct control domains, then join them in audit and approval workflows.

NHI Mgmt Group analysis

Skills and MCP are complementary control planes, not interchangeable solutions. MCP governs tool connectivity and execution path, while skills govern contextual instruction and task interpretation. Treating one as a replacement for the other creates blind spots in both authorisation and safe-use governance. The practitioner conclusion is simple: secure the protocol layer and the instruction layer as separate identity surfaces.

The most important risk is not capability exposure but context-induced misuse. The demo shows an agent can have legitimate database access and still produce a dangerous outcome by following stale internal assumptions. That is a governance issue for autonomous and semi-autonomous systems because the control failure happens after authentication, during action composition. The practitioner conclusion is to monitor how agents decide, not only what they can reach.

Task instructions have become governed assets. Once skills determine when an agent should search, what it should load, and how it should act, they become part of the security boundary. That means approval, provenance, version control, and auditability all apply. The practitioner conclusion is that instruction assets need lifecycle management just as much as service identities do.

Context is now a security control surface. The article’s strongest field-level lesson is that agent deployments fail when teams assume the model will self-correct from available tools alone. It will not. If the surrounding control plane does not force the agent to consult the right context, old training assumptions win. The practitioner conclusion is to treat context governance as a first-class part of NHI and agentic AI programmes.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• 48% of organisations say they cannot track and audit the data their AI agents access, creating a compliance and investigation blind spot.
• For a broader framework view, see OWASP Agentic Applications Top 10 for the controls that map most directly to agentic runtime risk.

What this signals

Context governance is becoming as important as access governance. As agentic workflows move from experimentation to production, the control question shifts from “can the system authenticate?” to “can the system prove what context it used?” That is a different operating model for IAM, IGA, and PAM teams, especially where agent actions are composed from multiple tools and instruction sources.

Instruction assets now need lifecycle management. Skills, prompts, and reusable agent instructions are no longer informal implementation details. They need ownership, approval, and audit trails because they shape runtime behaviour in the same way privileged policies shape human and machine access. Security programmes that ignore this layer will struggle to explain agent actions after the fact.

The best forward response is to align agent governance with established control thinking, including zero trust and privileged access discipline, while adding explicit context provenance. The relevant question is no longer whether the agent can act, but whether the organisation can bound and reconstruct the conditions under which it acted.

For practitioners

• Separate protocol governance from instruction governance Assign distinct owners, review paths, and audit requirements for MCP servers and skills so tool access and task guidance are governed independently.
• Require approved skills for production agent runs Maintain a registry of approved skills with versioning, provenance, and change control before any agent can load them in production workflows.
• Validate tool-specific failure modes in test workflows Test whether agent actions bypass underlying controls, such as PostgreSQL row-level security, when the agent composes outputs from incomplete context.
• Instrument runtime audit for loaded context Log which skills, prompts, and tool calls were used in each agent session so security teams can reconstruct why an action occurred.

Key takeaways

• Skills do not replace MCP, but they change the governance problem by making instruction context part of the control surface.
• The live failure mode is not just tool access, but agents acting safely only when the right context is forced into the workflow.
• Security teams need separate lifecycle controls for protocol access, skill approval, and runtime audit if they want agentic systems to stay governable.

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• 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.
• Contextual layer: An intermediate governance layer that adds visibility and control across systems not fully covered by the primary IGA stack. It matters when organisations need immediate insight into drift, exceptions, and coverage gaps while they work toward a more mature governance architecture.
• Row-Level Security: Row-level security is a database control that restricts which rows a session can read or modify based on policy. For multi-tenant apps, it is valuable because it pushes tenant enforcement below application code, reducing the chance that a forgotten filter exposes another organisation's data.

What's in the full article

Obot's full post covers the operational detail this analysis intentionally leaves for the source:

• The live MCP versus Skills demo sequence, including the four test modes and the exact failure reproduced on stage.
• Pedro Rodrigues' benchmark framing for why agents choose stale context unless prompted to search or load the right skill.
• Obot's control-plane model for governing MCP servers and a skill registry together in production.
• The discussion of how enterprise teams should curate, approve, and audit reusable agent skills.

👉 The full Obot post covers the live demo, framing model, and production governance implications in more detail.

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 or NHI governance programme, it is worth exploring.