How malicious SKILL.md files can compromise AI coding agents

SKILL.md security is the practice of treating agent skills like software supply chain components, not harmless markdown snippets. A skill can contain instructions, references, downloads, and behaviors that push a coding agent to fetch files, read secrets, install packages, or send data elsewhere.

MMichael SwindellJune 26, 202618 min read

SKILL.md security is a specific but often overlooked piece of ai agent security, the practice of treating agent skills like software supply chain components, not harmless markdown snippets. A skill can contain instructions, references, downloads, and behaviors that push a coding agent to fetch files, read secrets, install packages, or send data elsewhere. That makes skills a real attack surface, especially when agents run with broad permissions. For teams using agentic workflows, the right response is not panic. It is better controls: inventory, scanning, permission boundaries, and review. Platforms such as Levr matter here because agent-first work needs shared context and verification, not blind trust in whatever a skill requests.

At a Glance

Why agent skills deserve the same ai agent security scrutiny as packages
A markdown file can become an execution path when an autonomous agent treats it as trusted guidance.

● Core risk: Skills can influence agents to install malware, leak credentials, fetch suspicious payloads, or exfiltrate private data.

● Why it happens: Most skill ecosystems still lack strong signing, lockfiles, sandboxing, and integrity controls.

● Main pattern: The most dangerous setups combine private data access, untrusted content, and outbound communication.

● Common failure: Human approval often degrades into permission fatigue, especially in high-autonomy agent sessions.

● Best defense: Continuous skill scanning, permission minimization, and verification steps built into the workflow.

Skills are no longer just prompts. In practice, they behave more like unsigned dependencies with natural language execution logic and treating that gap seriously is now a core part of ai agent security.

Why are SKILL.md files a real AI agent security risk?

SKILL.md files are risky because an agent can treat their contents as trusted instructions, then act on those instructions with your machine’s permissions. Once a skill is allowed into an agent workflow, a markdown file can shape downloads, shell actions, data access, and outbound communication.

That is the key mental model shift. A skill is not only text. It is a behavioral component inside an agent system.

In many ecosystems, a skill includes more than the visible markdown file. It can reference assets, archives, install steps, or supporting files. If you only skim the top-level file, you may miss the behavior hiding around it.

This is why the risk resembles software supply chain security. The same pattern that hit package registries can show up here, except the instructions are often written in natural language rather than code.

The concern is not theoretical. The source material cites research on nearly 4,000 skills where a large share contained malware or other weaknesses. The video description references ToxicSkills research finding 37% of tested skills contained malware or security issues.

That broader concern fits a pattern already documented across developer ecosystems. GitHub’s Octoverse reports continue to show how quickly software creation scales when new workflows spread, while rapid growth usually outpaces governance in the early phase. Skills are following that same curve.

What makes agent skills more dangerous than ordinary prompts?

Ordinary prompts are transient, but skills can become reusable, persistent instructions that agents invoke automatically across tasks. That persistence makes them more dangerous, especially when an agent has shell access, file access, memory, or network access and treats the skill as part of a trusted environment.

A normal prompt often lives in a single interaction. A skill can live in a repository, a user directory, or a shared registry. It may trigger repeatedly, including after updates.

That persistence creates several problems:

Trust gets inherited too easily. If you trust a folder, the agent may also trust the files inside it.
Behavior becomes harder to inspect. You might review the skill once, then stop paying attention on later runs or updates.
Autonomy magnifies impact. In permissive sessions, the agent can move from instruction to action with little friction.
Natural language hides intent. A malicious payload does not need obvious executable code if the agent can be persuaded to perform the action itself.

This is the part many teams underestimate. The dangerous behavior may not be “inside” the file in the classic malware sense. The file may simply tell the agent what to do, and the agent becomes the execution engine.

What does the current agent skill security model usually miss?

Most current skill ecosystems still rely too heavily on user judgment. In practice, they often lack strong signing, integrity checks, lockfiles, isolation, and sandboxing. That leaves the main security boundary at “do you trust this folder or skill,” which is too weak for autonomous tooling.

The common gaps described in the source material include:

No signing to verify a known publisher or unchanged content
No lockfile or integrity pinning to make updates auditable and repeatable
No sandbox metadata explaining what the skill is allowed to access
No permission model inside the skill itself for file reads, shell actions, or network use
No isolation between what the agent can do for one task versus another

That is remarkably similar to immature package ecosystems in their early years. The difference is that natural language instructions can dodge simple static rules.

Classic regex scanning might catch explicit commands like curl or wget. It will struggle when the harmful behavior is phrased as ordinary text, such as telling the agent to upload a configuration file to a public paste service.

For teams running multiple coding agents, this is exactly where an agent-first control plane becomes useful. One way to handle this in Levr’s feature set is to keep issues, tests, and agent actions tied to shared project context so there is a narrower path from intent to execution.

How do malicious skills actually attack a developer machine?

Malicious skills usually work by influencing an agent to take a harmful action with legitimate permissions. The skill may direct downloads, read secrets, trigger shell commands, or send sensitive data outward. The agent does the work, which makes the attack look like normal task execution.

Several attack patterns emerge from the source material.

Suspicious downloads disguised as required dependencies

A skill can claim it needs an extra component with a name that sounds legitimate. The agent then asks for approval to fetch it, or fetches it in a permissive session. If the name looks plausible, a human may approve it without real scrutiny.

This is a form of confused deputy behavior. The attacker does not need direct access to your machine. They only need the agent to ask you for something that sounds reasonable.

Prompt injection through untrusted content

If the agent reads email, issues, pull requests, or other outside content, that content can contain instructions meant for the agent rather than the human. If the agent follows them, it may gather files or secrets and send them somewhere else.

Hidden instructions in Unicode or invisible characters

A skill can look harmless to a human reviewer while containing control characters or hidden content the model still processes. The source material demonstrates an example where a hidden instruction caused an agent to run a shell command.

Credential and secret leakage into model context

Some skills ask the user to provide payment information, tokens, or environment data so the agent can complete a task. That information may then land in logs, memory, model context, or external proxies.

Malicious scanners and defensive tools

A “security” skill may itself be malicious, or it may simply be ineffective because it scans for obvious strings instead of actual behavior. That means teams must verify both the skills and the scanners they depend on.

What is the “toxic trifecta” for agent security?

The most dangerous setup combines three things: access to private data, access to untrusted content, and a way to communicate externally. When all three exist together, an agent can read sensitive material, get manipulated by outside instructions, and then exfiltrate the results.

This is the simplest practical threat model in the source material, and it is useful because it is easy to apply.

Ask these three questions about any agent workflow:

Can the agent access private data? Examples include .env files, configuration files, API keys, payment details, customer data, or memory files from prior runs.
Can the agent read untrusted content? Examples include email inboxes, GitHub issues from unknown contributors, pasted documents, public repositories, and third-party skills.
Can the agent send data out? Examples include posting issues, opening pull requests, sending emails, calling web APIs, uploading to paste services, or using shell commands that reach the network.

If the answer is yes to all three, you are in a high-risk configuration.

This matters even more when memory is persistent. Shared memory can make agents more effective, but it can also carry forward sensitive context from one task to the next. In multi-agent setups, that risk expands because more than one process may access the same context.

That is where infrastructure choices matter. When teams need shared context, routing, and memory across agents, they should be explicit about those trust boundaries. Levr, for example, treats shared memory, message routing, and cross-agent context as first-class capabilities. Those are useful features, but they also need clear policy controls, because shared context without policy becomes shared blast radius — see our broader framework for sandboxing and least-privilege agent design for how to set those boundaries in practice.

Give agents shared context without giving them a blank check

If your team is coordinating coding agents across issues, tests, and approvals, a control plane helps separate project context from unrestricted execution.

See how teams structure agent workflows →

Why does human approval often fail as a security control?

Human approval fails because it degrades into habit. Once an agent asks for enough confirmations, many users stop evaluating each request carefully. In high-autonomy sessions, that creates permission fatigue, and permission fatigue turns approval into theater rather than a real boundary.

The source material makes this point clearly. A lot of users install or update skills without reading them deeply, and even fewer review them on every change.This isn't unique to skill files — a large-scale study of multi-agent LLM systems found that 75.17% of failures are silent semantic errors that bypass traditional code review and compilation checks entirely, meaning flawed or malicious logic can look syntactically correct while still executing harmful actions.

That is understandable. Developers are trying to move quickly. If an agent says it needs a tool, file, or dependency to finish a task, approving it can feel like ordinary workflow friction.

The Stack Overflow Developer Survey 2025 shows adoption has reached 84% even as active distrust of AI output now outweighs trust (46% vs. 33%) — a gap that doesn't translate into more careful review. Daily exposure to high-volume, imperfect output breeds fatigue rather than vigilance, and teams need systematic guardrails because that fatigue, not confidence, is what drives habitual, rubber-stamp approval.

Human review still matters. It just works best at the right stage:

Review the workflow design once.
Review skill provenance before adoption.
Review policy exceptions.
Review verified results before merge or deployment.

It works poorly as a nonstop stream of low-signal permission popups.

How should you audit agent skills in a real engineering workflow?

A practical audit starts with inventory, then moves to behavioral scanning, permission review, and update tracking. The goal is to know what skills exist, what they can access, what they try to do, and what changed since the last time you trusted them.

Use this checklist.

1. Build a skill inventory

Find every skill in:

Repository folders.
User directories.
Shared agent registries.
Team templates and bootstrapping scripts.

If you cannot list them, you cannot secure them.

2. Review the full package, not just the markdown

Check associated files, archives, downloads, helper scripts, and referenced assets. Treat a skill like a dependency bundle.

3. Evaluate behavior, not only strings

Simple pattern matching is not enough. You need to ask what the skill is instructing the agent to do, including indirect actions such as uploading files, reading environment variables, or fetching external payloads.

4. Re-review on updates

Trust is not permanent. A skill that looked harmless last month can change later.

5. Limit permissions by default

A skill for documentation formatting should not have the same runtime freedom as a deployment agent.

6. Watch for natural language exfiltration patterns

Examples include instructions to:

paste configs into external sites.
send debug details over email.
open browser sessions to third-party endpoints.
share logs that may contain secrets.

7. Test scanners against known bad cases

If your scanner misses prompt-injection style behavior or flags harmless content while missing real exfiltration logic, it is not enough.

8. Tie agent actions to verification gates

One way to handle this in Levr’s workflow model is to structure work as: define intent, let agents pick up tasks, run automated verification, then require human review and approval. That sequence is useful because it keeps autonomy inside a gated delivery path.

What are the biggest mistakes teams make with AI coding agents and skills?

The biggest mistakes are over-trusting convenience, underestimating natural language attacks, and assuming a one-time review is enough. Teams often import package security habits too late, after skills are already woven into daily development and deployment work.

The most common errors include:

Assuming markdown is harmless. If the agent acts on it, it is operational logic.
Only reading the top-level skill file. Supporting assets may contain the real payload path.
Running agents in broad permission modes by default. The wider the permissions, the bigger the blast radius.
Letting agents read untrusted content and secrets in the same session. That creates the toxic trifecta.
Trusting scanners that only use regex or keyword rules. Natural language attacks will slip past.
Ignoring update drift. A trusted skill can become risky later.
Treating approval prompts as a meaningful defense at scale. Habit will eventually win.

If any of those sound familiar, the fix is usually process design rather than asking engineers to be more careful.

How do you reduce risk without giving up agent productivity?

You reduce risk by shrinking trust boundaries, separating capabilities, and adding automated verification around agent work. The point is not to ban skills. It is to make sure a skill cannot quietly move from “helpful shortcut” to “unbounded execution path” without checks.

A practical approach looks like this:

Use least privilege. Give each agent only the file, shell, and network access required for the task.
Separate reading from acting. An agent that reads external content should not automatically deploy, email, or publish.
Keep secrets out of broad context windows. Do not pass payment details, long-lived tokens, or raw environment files through ordinary skill flows.
Scan skills continuously. Run audits on install, update, and before use in sensitive workflows.
Bind agents to issue and test context. Actions should map to tracked work, acceptance criteria, and verification results.
Require a final approval point before merge or deployment. Human review works best at the end of a gated pipeline.

For teams managing more than one coding agent, coordination is part of security. Shared context is useful, but only when you can observe what each agent did, what it accessed, and what verification it passed. That is why agent-first platforms tend to matter more as teams scale beyond solo experimentation.

Technical Deep Dive FAQ

What is a SKILL.md file in an AI agent workflow?

A SKILL.md file is a structured markdown file used to give an agent reusable instructions, metadata, and task guidance. In practice, it acts like an operational component the agent can invoke while working. The security problem is that the file is not just documentation. If the agent trusts and executes its guidance, the skill can influence downloads, shell actions, network requests, file reads, and other sensitive operations depending on the environment and permissions available.

What is agent skill supply chain security?

Agent skill supply chain security means applying dependency-style security thinking to skills used by coding agents. You track where skills come from, what they contain, what they reference, what permissions they assume, and how they change over time. The idea is similar to package security in NPM or PyPI, but with an extra twist: some harmful behavior is expressed in natural language instructions rather than executable code, so simple code scanning is often not enough.

Can a markdown skill really install malware without containing obvious malware code?

Yes. A skill does not need to embed a classic executable payload to create harm. It can instruct the agent to download a suspicious archive, fetch a fake dependency, run a shell command, expose local files, or upload sensitive data. If the agent has enough permissions and the user approves the action, the agent becomes the mechanism that carries out the attack. That is why reviewing intent and behavior matters more than only hunting for malware signatures.

Why do regex-based skill scanners miss serious attacks?

Regex-based scanners usually look for obvious tokens such as curl, wget, or known suspicious strings. That catches only a narrow class of risks. A malicious skill can express harmful intent in ordinary language, hide instructions in indirect phrasing, or use invisible Unicode characters that change how a model interprets the content. Because the agent responds to meaning rather than only syntax, effective scanning has to evaluate behavior and intent, not just deterministic patterns.

What is the most dangerous permission combination for a coding agent?

The highest-risk combination is access to private data, access to untrusted content, and the ability to communicate externally. With those three capabilities, an agent can read secrets, get manipulated by outside instructions, and then exfiltrate the result. Add shell access or persistent memory and the situation gets worse. This is a useful threat model because it helps teams quickly identify which agent workflows need stricter isolation, narrower permissions, or explicit review gates.

How can prompt injection in email or GitHub issues affect a local agent session?

If your agent reads email, issues, or pull requests as part of its workflow, those inputs may contain instructions aimed at the model rather than the human. The agent might interpret them as task guidance, gather local files, or send a response externally. If the same session also has access to environment variables, config files, or network tools, a poisoned message can become a path to secret leakage. Untrusted content should never share a wide-open execution context with sensitive local data.

How should engineering managers govern shared memory in multi-agent systems?

Shared memory should be treated as a governed data plane, not a convenience feature. Teams need to know what gets stored, which agents can read it, how long it persists, and whether sensitive content from one task can influence another. This becomes especially important in multi-agent systems where routing and coordination depend on shared context. Good governance means explicit retention rules, access boundaries, observability, and reviewable traces of which agent wrote or consumed specific memory items.

How often should teams rescan skills after the initial review?

Teams should rescan skills on installation, on every update, and before use in sensitive workflows such as deployment, email handling, or access to secrets. One-time review is not enough because skills can drift, registries change, and surrounding files may be updated separately from the visible markdown. The right cadence depends on risk, but the principle is constant: trust expires when content changes. If a skill can affect code, infrastructure, or data, it belongs in your continuous security process.

What is a practical way to give coding agents context without exposing everything?

A practical approach is to separate project context from unrestricted machine access. Give agents the issue, acceptance criteria, tests, and prior task history they need, but scope file access, shell access, and outbound communication to the minimum required for the current task. Agent-first control planes are useful here because they tie work to a governed workflow instead of an open-ended prompt. That makes it easier to observe actions, enforce gates, and keep dangerous permissions out of ordinary planning or analysis tasks.

Key Takeaways

Secure the skill layer before it becomes invisible infrastructure

Agent productivity is worth keeping, but only with stronger trust boundaries.

● Treat skills like dependencies: Inventory them, review provenance, and rescan on every meaningful change.

● Model the toxic trifecta: Private data plus untrusted content plus outbound communication is the danger zone.

● Do not rely on approval prompts: Permission fatigue turns repeated confirmations into a weak control.

● Scan for behavior, not only syntax: Natural language attacks and hidden instructions can bypass regex-only tools.

● Use gated workflows: Separate intent, execution, verification, and human approval so agents do not operate in a trust vacuum.

The biggest shift is conceptual: a skill is not “just markdown” once a capable agent decides to obey it.