Topic starter
25/10/2026 11:06 am
TL;DR: Artifact drift from folder copies and chat-shared zips makes review and rollback unreliable for MCP servers and agent skills, according to Jozu. A registry install path gives security teams a control point for provenance, approval, signing, and enforcement before execution.
Editorial analysis by NHI Mgmt Group, based on content published by Jozu: “Why MCP servers and agent skills need an enterprise registry”.
Key questions
Q: Why does packaging matter for MCP servers and agent skills?
A: Packaging matters because it turns scattered files into a versioned release unit.
Q: How should security teams govern installs of agent components?
A: They should treat installation as a policy decision, not a convenience step.
Q: What breaks when agent skills are shared as folders instead of governed artifacts?
A: You lose provenance, version consistency, and rollback clarity.
Practitioner guidance
- Establish an approved artifact path Require every MCP server and skill to move through a versioned registry before installation, and block direct installs from ad hoc folders or chat-shared archives.
- Bind review to the installable artifact Make signing, scanning, and approval happen on the packaged ModelKit that will be deployed, not on source files that can drift before use.
- Separate clean and unsafe versions Publish distinct tags for safe and unapproved variants so policy can make a decision against the exact artifact the agent would consume.
Bottom line: MCP servers and agent skills should be governed as executable artifacts because they can change runtime behavior, not just store instructions.
Glossary terms: Agent Skill, ModelKit, Artifact Provenance, Admission control
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
27/10/2026 7:17 pm
Artifact drift is the real control failure here: when skills move as folders or chat-shared zips, the approved version and the installed version stop being the same object. That breaks provenance, makes review non-deterministic, and leaves security teams unable to prove what was actually in use. The practitioner takeaway is that change control for agent behavior has to be attached to the artifact, not the human who copied it.
A few things that frame the scale:
- 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.
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: When do copied skills become an identity governance problem?
A: They become a governance problem as soon as the component can alter agent behavior in support, incident, or workflow decisions. At that point, the package is part of the access boundary for the agent, so uncontrolled distribution creates an unmanaged change path into runtime behavior.
👉 Read our full editorial: Governed packaging for MCP servers and agent skills
This post was modified 7 days ago by NHI Mgmt Group