Why do skills create a bigger risk than prompt injection alone?

Because the risk extends beyond what the agent reads and into what the repository tools execute automatically. A skill can carry hidden payloads that never touch the prompt path, then trigger through test runners, linters, or config loaders. That means scanning only the agent-facing instructions leaves the broader repository execution surface ungoverned.

Why This Matters for Security Teams

Prompt injection is only one path into an agent. Skills expand the attack surface because they can bundle instructions, scripts, manifests, and helper code that execute outside the prompt path and often outside the agent team’s review process. That makes the real risk a repository-to-runtime problem, not just a model-input problem. Guidance from the OWASP Agentic AI Top 10 and NHIMG research on the OWASP NHI Top 10 both point to the same issue: autonomous systems inherit execution risk wherever toolchains can act on untrusted content.

For security teams, the practical mistake is assuming prompt filters, system prompt hardening, or instruction sandboxes are enough. They are not. A malicious or compromised skill can sit in a code path that a build step, test runner, or config loader trusts by default, then trigger privilege-bearing actions without ever appearing in the conversational transcript. That is why this belongs in NHI governance, software supply chain controls, and agent runtime policy, not only in LLM red-team exercises. The NIST Cybersecurity Framework 2.0 is useful here because it forces attention on asset inventory, protective controls, and continuous monitoring across the full execution path.

In practice, many security teams encounter the impact only after a benign-looking skill has already triggered code execution or secret exposure, rather than through intentional review of the repository execution surface.

How It Works in Practice

A skill becomes dangerous when the agent treats it as trusted workspace content. The prompt may be clean, but the skill can still influence what gets executed by CI jobs, local tooling, package hooks, shell commands, or config parsers. The key distinction is that prompt injection changes what the model reads, while skill abuse changes what the surrounding automation does. That is why the control boundary must include file provenance, execution policy, and runtime identity.

Current guidance suggests treating skills as untrusted code-adjacent artifacts. In practice, security teams should combine repository scanning with controls that govern execution at the point of use. That includes restricting which directories can trigger automation, disabling implicit execution where possible, and requiring explicit approval for scripts, templates, and manifests that introduce side effects. The Gemini CLI Breach and Amazon Q AI Coding Agent Compromised illustrate how execution paths can be abused even when the visible prompt appears ordinary.

• Classify skills as executable supply chain inputs, not just content.
• Apply allowlists for tool invocation, file types, and directories that can trigger automation.
• Use short-lived, task-scoped credentials for agents so a compromised skill cannot reuse broad access.
• Log skill provenance, execution events, and downstream tool actions as a single trace.

Where possible, pair repository controls with workload identity and policy-as-code so the agent can only perform the action it is explicitly authorised to do in that moment. These controls tend to break down in fast-moving developer environments where plugins, hooks, and local tooling can execute automatically without central enforcement.

Common Variations and Edge Cases

Tighter skill controls often increase developer friction, requiring organisations to balance safety against speed and repository autonomy. That tradeoff becomes sharper in environments that rely on rapid iteration, shared templates, or third-party extensions, because every new convenience path can become an execution path.

One common edge case is a “safe” skill that only looks like documentation but includes loader directives, build metadata, or test fixtures that fire automatically. Another is a multi-agent workflow where one agent writes a skill and another executes it, creating an internal trust chain that no single prompt review will catch. Best practice is evolving, but current guidance suggests treating any artifact that can change runtime behaviour as security-relevant, even if it never enters the chat window. NHIMG’s Ultimate Guide to NHIs is useful for framing the broader exposure from excessive privilege and weak visibility, while the Gemini AI Breach shows how indirect paths can still produce direct data loss.

There is no universal standard for this yet, but the practical rule is simple: if a skill can influence execution, it needs the same scrutiny as code, secrets, and CI/CD inputs.

Related resources from NHI Mgmt Group

• Why do MCP servers create a bigger risk than model prompts alone?
• Why do AI agents create new risk in non-human identity management?
• When does AI agent access create more risk than it reduces?
• When do AI agent credentials create more risk than they reduce?