What breaks when AI assistants can read unreviewed skill files or MCP configs?

When AI assistants can read unreviewed skill files or MCP configs, what actually fails?

The failure is not just “bad input,” it is a broken authority boundary. A skill file or MCP config can behave like executable policy if the assistant is allowed to ingest it without review, so the model may follow instructions that were never intended to be trusted, then act on tools, endpoints, or data with real side effects.

That shifts control from explicit software logic to ambient text the assistant can parse at runtime. Once that happens, governance depends on what the assistant sees, not only on what engineers shipped.

Why unreviewed artefacts become a control-plane problem

Unreviewed skill files and MCP configs matter because they are often loaded as if they were harmless metadata, when in practice they can define behaviour, permissions, routing, or tool access. If the assistant treats those files as authoritative, a reviewer loses the chance to separate trusted policy from attacker-controlled instructions, and the trust model becomes data-dependent.

That is especially important where the artefact can change what the assistant is allowed to call, what context it can use, or where it sends output. A configuration boundary that is supposed to be static becomes a runtime decision surface.

This is the same kind of problem that shows up in agent governance and tool orchestration guidance, where prompt content, tool descriptors, and local config can all influence execution. NHIMG’s MCP Security Guide and the agentic AI applications guide both treat that boundary as something that must be designed, not assumed.

What kinds of failures this creates in practice

The most common failure mode is instruction smuggling, where a file that should only describe skills or connectivity also contains hidden operational directives. If the assistant accepts those directives, the result can be tool misuse, overbroad data access, or calls to endpoints that no approver intended.

A second failure mode is misattributed trust. The assistant may treat the file as if it came from the platform owner, when in reality it may have been copied from a repository, synced from a workspace, or modified by a third party. In that case, the runtime agent is effectively obeying unvetted policy from an untrusted source.

A third failure mode is blast-radius expansion. A single compromised config can alter many sessions or many assistants if it is reused across environments, which makes the issue much larger than one prompt injection event. That is why MCP security guidance focuses so heavily on authorization design, token handling, and local server trust boundaries, not just on the assistant itself. The MCP authorization specification is relevant here because it formalises the token and resource-server side of that boundary.

Why review, provenance, and least privilege have to come first

The practical lesson is that assistants should not be allowed to consume arbitrary skill or config files as though every local artefact were trusted policy. Review must establish provenance, expected scope, and the exact actions a file is allowed to influence before runtime ingestion is permitted.

Where MCP is involved, the safest pattern is to separate descriptive configuration from authorisation decisions, and to ensure that a config file cannot silently widen access. NHIMG’s AI Agent Identity Security deployment guide is useful here because it frames short-lived, task-scoped authority as the default rather than long-lived ambient access.

For teams building or operating assistants, the question to ask is simple: if this file were altered by an attacker, what real action could the assistant now take? If the answer includes tool invocation, external API calls, or access to sensitive data, the file needs the same change control discipline you would apply to executable code.

Risk and Threat Considerations

Unreviewed skill files and MCP configs create a realistic path for prompt-instruction injection, tool abuse, and unintended data disclosure. The core risk is that the assistant will execute trusted-looking text as operational guidance, which lets an attacker or careless contributor move from content tampering to real system action.

Failure mechanism: The assistant ingests local text as authority, then uses that text to select tools, endpoints, scopes, or data sources that were never approved by a human reviewer.

Impact: The result can be unauthorized access, hidden exfiltration, privilege expansion, or persistent governance drift across repeated assistant runs and shared workspaces.

Practitioner Guidance

What to verify: Treat every skill file, agent instruction file, and MCP config as a governed artefact. Verify who can modify it, where it is sourced from, and whether the assistant is capable of acting on it without an explicit approval step.

Decision rule: If the artefact can change tool selection, endpoint selection, or access scope, put it behind review and restrict the assistant to the smallest possible authority needed for the task. If the file can only describe behaviour but cannot alter runtime permissions, the risk is lower, but provenance still matters.

Practitioner takeaway: The important control is not “can the assistant read the file,” it is “can the file change what the assistant is trusted to do.” Once that answer is yes, the file belongs in the same governance model as any other policy-bearing input.

Related resources from NHI Mgmt Group

• What is MCP in the context of AI security?
• How should teams govern AI agents that use MCP?
• When is it appropriate to implement MCP in the context of AI systems?
• What breaks when an AI browser can read local files inside a user session?