What breaks when skills, rules files, or MCP configs are not reviewed like privileged controls?

Why This Matters for Security Teams

Skills files, rules files, and MCP configs are not ordinary application content when an agent can execute them as instruction sources. They can alter tool reach, data scope, approval logic, and even the sequence of actions an agent will take. That makes them privilege-bearing artifacts, not documentation. Security teams that review them like code often miss the real control boundary: the agent’s operational authority.

This is why the issue maps directly to guidance in the OWASP Top 10 for Agentic Applications 2026 and the OWASP Non-Human Identity Top 10: untrusted instructions and weak control over non-human identities create a direct privilege escalation path. The same pattern shows up in NHIMG research on the Analysis of Claude Code Security, where the operational risk is not just bad output but bad execution authority.

In practice, many security teams encounter the failure only after an agent has already called the wrong tool, accessed the wrong repository, or exposed secrets through a trusted config path.

How It Works in Practice

These files should be treated like privileged controls because they define what the agent is allowed to do at runtime. A skills file can redirect the agent toward a different workflow. A rules file can suppress guardrails or expand acceptable actions. An MCP config can point the agent to a server that exposes higher-value tools or broader data than intended. When those files are updated without review, the change is functionally similar to changing an IAM policy or a PAM entitlement.

Current guidance suggests three practical controls. First, place these files under the same review path as other privilege changes, with explicit approval from security or platform owners. Second, use immutable or signed configuration where possible so the agent consumes a trusted version rather than whatever appears in a repository at runtime. Third, separate instruction content from code execution paths so a content change cannot silently change authority. NHIMG research on the OWASP Agentic Applications Top 10 and the Ultimate Guide to NHIs reinforces the same operational point: the control plane matters as much as the application code.

• Review changes to skills, rules, and MCP configs as privileged access changes.
• Require runtime policy checks, not just pre-merge code review.
• Limit tool scope and secret access to the smallest task-specific boundary.
• Log who changed the file, what changed, and which agent consumed it.

Where this guidance breaks down is in highly dynamic agent pipelines that load instructions from multiple repositories or remote MCP endpoints because provenance becomes hard to verify before execution.

Common Variations and Edge Cases

Tighter review of these controls often increases release friction, requiring organisations to balance faster agent iteration against stronger privilege governance. That tradeoff becomes sharper when engineering teams treat prompt assets as low-risk content while security teams need them handled like policy.

There is no universal standard for this yet, but current practice is moving toward intent-aware authorization and short-lived trust for agent workflows. That matters most when an MCP config can connect to a sensitive system, or when a rules file changes the agent’s ability to summarize, act, or delegate. In those cases, static review is not enough because the real risk is the runtime effect, not the file format.

One useful test is simple: if changing the file can expand tool access, data access, or execution autonomy, it should be reviewed like a privileged control. This also applies to third-party agent frameworks that ingest config from CI pipelines or shared workspaces, where a harmless-looking edit can alter the agent’s effective identity and authority. In that environment, the safer baseline is to assume config drift can become privilege drift unless the change path is explicitly controlled.

Related resources from NHI Mgmt Group

• What breaks when third-party agent skills are not governed like privileged inputs?
• What breaks when MCP servers are approved once but allowed to change later?
• What breaks when ML pipelines load cache files from untrusted sources?
• What breaks when MCP tool descriptions can be modified by an attacker?