What breaks when an AI agent can trust skills written by unvetted code?

How unvetted skills turn a trust boundary into a control bypass

The core break is not just “bad code exists,” but that the agent can no longer distinguish policy from payload. When skill definitions, instructions, or tool descriptors are accepted from untrusted sources, the agent may execute attacker-authored intent as if it were part of the approved workflow. That changes the trust boundary from “validated control plane” to “anything the agent can load.”

This is why unvetted skills are dangerous even when they look harmless. A skill can smuggle instructions through configuration, metadata, or helper logic, then wait until the agent reaches the right context to act. The result is not a one-time prompt trick; it is durable steering that survives across tasks, sessions, and sometimes environments.

In practice, the failure mode is closest to untrusted code execution with a social engineering wrapper. The agent is not just reading content, it is treating content as authority. Once that happens, the attacker does not need repeated access to the model. They only need a trusted load path for the malicious skill.

What persistent compromise looks like in an agentic workflow

Persistent compromise appears when the malicious skill can keep influencing future decisions after the initial foothold is gone. That can happen through cached instructions, stored skills, imported templates, shared repositories, or synced tooling that the agent trusts by default. The compromise becomes structural because the agent reuses the poisoned instruction source as if it were part of its operating model.

That persistence matters because the agent may now route ordinary work through the attacker’s logic. It can leak secrets into logs, broaden tool use, choose unsafe actions, or silently alter outputs in ways that look like normal automation. The attack no longer depends on winning every individual interaction, which makes detection and recovery much harder.

For practitioners, the key signal is whether the agent has any path that converts external content into executable guidance. If the answer is yes, then the important security question is not only “is the skill malicious?” but also “who is allowed to make the agent trust it?”

Why approval, provenance, and isolation have to sit in front of execution

Skills need a provenance model, not just a review process. If the agent cannot verify where a skill came from, who authored it, and whether it was changed after review, then trust becomes a guess. The safest pattern is to treat skills as supply-chain inputs: constrain where they come from, record what was approved, and separate trusted runtime artefacts from user-supplied or community-supplied ones.

That also means the execution environment should not inherit broad standing privilege from the agent itself. A vetted skill should still run with only the permissions it needs, for the specific task it needs, in the environment it needs. Without that separation, a single poisoned skill can escalate from “bad instruction” to “broad delegated authority.”

When loading skills from external or shared sources, AI Coding Agents Security Guide is useful for the same reason: it explains how agent instruction files, local context, and over-scoped access create a durable attack surface.

Risk and Threat Considerations

Unvetted skills create a trust-poisoning problem: once the agent accepts attacker-shaped instructions as a legitimate workflow artefact, every later action can inherit that compromise. The risk is amplified when skills are shared across teams or automatically reloaded, because one malicious insert can influence many sessions and many users.

Failure mechanism: The attacker places or modifies a skill in a location the agent already trusts, then relies on normal loading behaviour to execute the attacker’s logic during future tasks. Because the instruction source looks legitimate to the agent, the compromise can persist without obvious interactive prompting.

Impact: The agent may misroute actions, expose secrets, widen tool access, corrupt outputs, or perform destructive operations under apparently normal workflow conditions. Recovery is harder because the malicious influence can survive after the original compromise event has been removed.

Practitioner Guidance

What to verify: Confirm that skills are signed, versioned, and loaded only from approved locations. If the agent can ingest skills from repositories, extensions, or shared folders, verify that those sources are treated as untrusted until explicitly promoted.

Decision rule: If a skill can affect tool choice, privilege use, or data handling, do not let it execute merely because it was “installed.” Require provenance, review, and scope limits before the agent is allowed to treat it as authoritative.

Common mistake: Teams often secure the model prompt but leave the skill layer open. That misses the real issue, which is that the agent’s behaviour can be steered by any trusted instruction source, not just by the visible prompt.

Practitioner takeaway: The control objective is to make trust explicit and revocable at the skill boundary, so that loading a skill never automatically means granting it authority.

Related resources from NHI Mgmt Group

• What are Agent Skills and how do they enhance AI performance?
• What is the difference between human identity governance and AI agent governance?
• When does AI agent access create more risk than it reduces?
• What is the difference between governing human access and governing AI agent access?