What breaks when MCPs and Skills are not tightly controlled on AI-enabled endpoints?

Why This Matters for Security Teams

On AI-enabled endpoints, MCPs and Skills are not just convenience layers. They are execution paths that can read data, call tools, and influence downstream actions. When those components are loosely governed, a normal assistant becomes a software supply chain problem, a data handling problem, and a privilege problem at the same time. OWASP’s OWASP Agentic AI Top 10 treats tool abuse and prompt injection as first-order risks because the agent often acts faster than a human can review.

NHIMG research on AI Agents: The New Attack Surface report shows why this is not theoretical: 80% of organisations say their AI agents have already acted beyond intended scope. That matters on endpoints because local tools and skills frequently inherit the endpoint user’s trust, filesystem reach, and network access. Once a malicious or overbroad component is loaded, it can turn ordinary user actions into unauthorised system access or sensitive data movement. In practice, many security teams encounter this only after an endpoint tool has already been used to exfiltrate data or chain into a broader compromise.

How It Works in Practice

The control objective is simple: every MCP server, connector, skill, plugin, or helper script on the endpoint should be treated as an executable trust decision, not as a harmless productivity add-on. That means allowing only approved components, binding them to explicit policy, and monitoring their use at the tool level rather than only at the process or application layer.

Current guidance suggests three enforcement layers. First, establish software allowlisting for approved MCPs and Skills so unvetted packages never execute. Second, use context-aware authorisation so a component can only invoke the specific resources it needs for the task at hand. Third, log tool invocation, input, output, and destination to support detection and forensic review. The OWASP Top 10 for Agentic Applications 2026 is useful here because it frames tool misuse, prompt injection, and excessive agency as application risks, not just endpoint hygiene.

For endpoint programs, this also means verifying the provenance of any skill bundle or MCP package before deployment, ideally with signing, hash validation, and controlled update channels. NHIMG’s Analysis of Claude Code Security is a good reminder that code-facing assistants can amplify risk when guardrails are weak. If the endpoint uses autonomous agents, policy should be evaluated at request time with full context, because pre-approved static permissions quickly become too broad once the agent starts chaining tools. These controls tend to break down in developer workstations and BYOD environments because users can install unsanctioned extensions faster than security teams can inspect them.

Common Variations and Edge Cases

Tighter control of MCPs and Skills often increases friction, so organisations have to balance user autonomy against the risk of hidden execution paths. That tradeoff is most visible in engineering, data science, and support teams where fast iteration is part of the job. Best practice is evolving, but there is no universal standard yet for how much tool autonomy is acceptable on a managed endpoint.

One common edge case is a trusted Skill that later gains new permissions through an update. Another is an MCP connector that is safe in test but becomes dangerous when pointed at production systems or sensitive repositories. A third is shadow AI use, where users sideload tools outside the approved catalogue. The Ultimate Guide to NHIs — Standards is useful for aligning endpoint controls with identity and lifecycle expectations, while the NHIMG AI agents report underscores how quickly scope drift becomes real-world exposure.

Security teams should also assume that local components may interact with secrets, clipboard data, and cached credentials in ways that are hard to observe. In environments with high plugin churn, frequent exception requests, or unmanaged endpoint fleets, governance often fails because approval workflows cannot keep pace with the rate of change.

Related resources from NHI Mgmt Group

• What breaks when AI project visibility and sharing are not tightly controlled?
• What breaks when organisations cannot see which AI skills and agent tools are running on developer endpoints?
• What breaks when an AI agent can auto-connect to attacker-controlled endpoints from a crafted link?
• What breaks when CloudTrail data events are not enabled for AI services?