How to Secure AI Agents and Skills Files

You secure AI agents and skills files the same way you secure any software supply chain: inventory everything, scan before deploy, enforce least privilege, pin versions, and monitor after install. The difference is speed. Employees are building these workflows faster than most security teams can even see them.

Shadow AI isn't chatbots anymore

For the last two years, "shadow AI" mostly meant someone pasting a customer list into ChatGPT. That risk hasn't gone away, but it's been overtaken by something bigger. Employees are now building autonomous agents that read files, run shell commands, call APIs, and remember context across sessions. GPT-6 Astra pushes this further by handling full computer use: filling forms, managing CRMs, installing and testing software on its own.¹ Claude's Agent Skills do something similar through a simple text file called SKILL.md, which tells an agent what a task is, how to do it, and what tools to reach for.

That file is small. What it can do is not. A skill installs with the agent's full runtime permissions by default: shell access, file read and write, credential access, persistent memory.²³ There's usually no per-skill permission boundary. One security team put it bluntly: "The SKILL.md file is the new package.json. And it's already compromised."³

This is the same pattern we've covered with employees quietly running terminals and shipping working software without IT ever seeing a ticket. Skills files are the next layer of that problem, just with higher privileges and a public marketplace behind them.

Why a skills file is riskier than a rogue SaaS signup

Traditional shadow IT meant someone expensed a tool without approval. Annoying, but bounded. A skills file is different because it doesn't just store data, it executes. Once installed, it can read your filesystem, touch your credentials, and act persistently across sessions without a human re-approving each step.

Think about what that means practically. A traditional unapproved SaaS tool leaks whatever data you feed it. A malicious skill can go get the data itself, because it inherits the same shell and file access as the agent it's attached to.²³ It's the difference between a nosy vendor and a burglar with your house key.

What did security researchers actually find?

This isn't a hypothetical. Snyk ran the first comprehensive audit of the Agent Skills ecosystem, scanning 3,984 skills pulled from ClawHub and skills.sh.² The results:

• 13.4% (534 skills) contained at least one critical-severity security issue.²
• 36.82% (1,467 skills) had at least one flaw of any severity, including malware, credential exposure, and prompt injection.²
• Human-in-the-loop review confirmed 76 skills carried genuinely malicious payloads built for credential theft, backdoors, and data exfiltration.²
• 8 of those 76 were still live on the marketplace at the time of publication.²

A separate, independent analysis of 42,447 agent skills found 26.1% carried at least one vulnerability, corroborating Snyk's numbers from a completely different dataset.³ The industry took this seriously enough that OWASP formalized the risks into an Agentic Skills Top 10 taxonomy in March 2026, covering malicious skills, upstream config compromise, over-privileged execution, invisible markdown payloads, and cross-platform propagation.³

Security researchers at Reversec went further and built working exploit chains against Claude Code, using malicious SKILL.md files to achieve code execution, exfiltrate SSH keys and AWS credentials through obfuscated bash and base64 commands, and backdoor code repositories, all without ever tripping the model's own refusal behavior.⁴

How do the attacks actually work?

The most striking finding from Snyk's confirmed-malicious sample: 100% contained malicious code patterns, and 91% of those also used prompt injection.² That convergence is the real threat. Injected instructions can talk an agent out of its own safety guardrails, then hand off to code that does the damage.

Common patterns researchers found:

1. Obfuscated exfiltration. Base64-encoded or otherwise disguised commands that quietly pull credentials, keys, or source code out through a shell step the user never reviews.⁴
2. External malware distribution. Skills that reference or fetch payloads from outside sources at runtime, so the file on disk looks clean during a static review but pulls something dirty later.²
3. Dynamic context manipulation. Prompt injection embedded in the skill's own instructions, designed to override the agent's safety behavior before the malicious code executes.²
4. Invisible markdown payloads. Content hidden in formatting that a human skimming the file won't notice but the agent still parses and acts on.³

None of this requires a sophisticated attacker. It requires an unreviewed file and an agent with too much standing access. This is the same escalation we flagged in our look at how copilot-era tools write fast but not safe: speed without review always finds the gap.

How to secure AI agents and skills files: the governance framework

Anthropic's own enterprise documentation is unusually direct about this: "Never deploy Skills from untrusted sources without a full audit... Treat Skill installation with the same rigor as installing software on production systems."⁵ That's the right instinct. Here's how to operationalize it.

1. Build an AI-BOM. You cannot govern what you cannot see. Inventory every skill, agent, and workflow in use across the org, who owns it, and what data or systems it touches. This is the same discipline we've argued for with managing AI agents before they manage you.
2. Run a risk-tier review on every skill before deployment. Anthropic recommends checking for code execution capability, instruction manipulation, network access, and hardcoded credentials before anything goes live at scale.⁵ Score each skill and gate deployment by tier rather than treating them all the same.
3. Scan skill content, not just skill descriptions. Static review of the visible instructions isn't enough given how many exploits hide in obfuscated code or dynamically fetched payloads.²⁴ Use organizational skill-scanning tooling, and treat any skill pulled from a public marketplace as untrusted by default.
4. Enforce least privilege at the agent level. Skills shouldn't inherit full shell, file, and credential access just because that's the default.²³ Scope what each agent can touch, and separate credentials for agentic workflows from the ones a human uses directly.
5. Pin versions and control updates. A skill that passed review yesterday can be silently changed today. Version pinning stops an approved skill from quietly turning malicious after the fact.⁵
6. Manage the full lifecycle, not just the install. Plan, review, test, deploy, monitor, deprecate. Anthropic's own guidance frames this as a continuous cycle, not a one-time gate.
7. Know the coverage gap. Claude's enterprise skill scanning only covers claude.ai and Cowork uploads, not the API.⁵ If your teams deploy skills programmatically, you need your own scanning and review process. Vendor tooling won't catch it for you.

Treat employee-built agents as owned assets, not liabilities

The instinct to ban all of this is understandable and it doesn't work. Employees will keep building because the tools are useful and fast. The better move is to bring these workflows into a real registry: catalog every skill and agent, assign an owner, apply the risk tiers above, and review on a schedule. That's the same shift we've written about with governing the apps employees build with AI coding tools — the goal isn't to shut the door, it's to know what's behind it.

That registry mindset is also where software ownership and AI governance meet. An agent your team built and can inspect, sandbox, and retire on your own terms is an asset. An agent nobody can name, running on a marketplace skill nobody reviewed, is a liability with a runtime. Tools like Remy exist for exactly this gap: giving teams a way to build and own internal software, including agentic workflows, instead of quietly renting risk from an unvetted marketplace.

What does leadership keep getting wrong?

The governance gap here isn't a knowledge problem. Okta's 2026 CISO survey found 81% of CISOs worry their AI systems aren't properly governed, but only 47% of companies know all the AI agents running on their network, and only 46% control those agents' access to corporate data.⁶ 68% of CISOs report seeing unauthorized AI use already.⁶ Only about a quarter of organizations manage agents through a dedicated access framework, and roughly a fifth let agents run on shared or over-permissioned credentials.⁶

It's tempting to blame this on employees not knowing better. The evidence says otherwise. UpGuard's global survey found more than 80% of workers, and nearly 90% of security professionals, use unapproved AI tools at work, and employees who feel confident they understand the risks are more likely to use unapproved tools, not less.⁷ Awareness training alone doesn't fix this. Structure does.

The organizations that get ahead of this aren't the ones with the strictest policy memo. They're the ones that built the inventory, set the risk tiers, and gave employees an approved, sandboxed way to build agents fast. That's a harder project than sending an email banning skill marketplaces, but it's the only one that actually works.