Why does serving skills over MCP create governance and security risk if clients do not support the full draft?

How MCP draft gaps turn a skills layer into a governance problem

Serving skills over MCP becomes risky when the client does not implement the draft consistently, because the skill layer starts to behave like part of the operational control plane rather than a simple content source. In that state, the same skill can be loaded, refreshed, or enforced differently depending on the harness, which changes what reviewers think is being approved and what operators think is being executed.

That matters because governance depends on stable assumptions about versioning, provenance, and enforcement. If one client treats a skill as a live resource and another snapshots it at import time, the organisation may believe it has one reviewed instruction set while users are actually operating across several behavioural variants.

Even the protocol boundary becomes part of the security model, so the practical question is not only whether MCP can transport skills, but whether the client and server agree on how those skills are discovered, cached, refreshed, and constrained. For protocol-level authorisation and token handling, the current MCP authorization specification shows why implementation detail matters: security assumptions change when clients differ on what they enforce locally versus what they delegate.

Why inconsistent client support changes the security boundary

A full draft implementation can create a false sense of interoperability. If the skill is effectively live in one environment but static in another, teams may base change control, review, and rollback decisions on the wrong operating model. That is not just inconvenient, it can cause a controlled rollout to behave like an uncontrolled fork.

From a security perspective, the biggest issue is that the client becomes part of the trust boundary. A skill that looks harmless in one harness may carry different permissions, tool bindings, or instruction precedence in another, especially when the client interprets metadata, update timing, or execution context differently. The result is inconsistent enforcement of the same logical capability.

This is why practitioner teams should treat MCP skill delivery as an interface with version-sensitive semantics, not as a neutral transport. NHIMG’s MCP Security Guide is useful here because it centres the control question on authorisation, token handling, and tool exposure rather than assuming the transport alone is safe.

What breaks in review, support, and change control

When clients do not support the full draft, the same skill can present different operational states to different users. That undermines approval workflows because the reviewer may sign off on one version of the skill while the runtime environment serves another. It also makes support harder, because incident triage must now account for client-specific behaviour instead of one shared contract.

The downstream problem is drift. One harness may pin a skill version, another may refresh on demand, and a third may partially understand the extension but ignore fields that matter to policy enforcement. Over time, those differences create a fragmented control surface where audit evidence, exception handling, and rollback procedures no longer line up cleanly.

For agentic systems, that fragmentation is especially visible when skill composition affects tool use or decision rights. The broader agentic risk model described in the agentic AI applications guide helps frame the issue: once runtime behaviour depends on multiple partially aligned clients, governance has to cover the harness as well as the skill content.

Practitioner Guidance

What to verify: Treat “supports MCP skills” as a compatibility claim that must be proven per client, not assumed from a product label. Verify whether the client snapshots, refreshes, or rehydrates skills, and whether it preserves the same enforcement points across those modes.

Decision rule: If the client cannot demonstrate deterministic handling of skill versioning, provenance, and update timing, treat the deployment as a governed exception rather than a standard pattern. That is the point where review, rollout, and rollback controls need to be tightened before broad use.

What good looks like: The same skill produces the same approved behaviour across harnesses, or the organisation has explicitly documented where behaviour is allowed to differ. The safest operating model is one where client variability is visible, bounded, and accounted for in change management.

Practitioner takeaway: The main risk is not MCP itself, but treating an incomplete client as if it were a full implementation. Once skill behaviour can diverge by harness, governance has to manage semantic drift, not just content.

Related resources from NHI Mgmt Group

• Why do MCP deployments create security risk when they are adopted faster than governance controls?
• Why does exposing APIs and control plane data through MCP create security and governance risk?
• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?