What Are AI Agent Skills? A Security Primer on the New Shadow-IT Layer
- An agent skill is a reusable capability package - markdown instructions plus code - that loads into an AI agent and runs with the agent's full permissions on the endpoint.
- The same skill format works across OpenClaw, Claude Code, Cursor, and VS Code, so one skill can spread capability, or a payload, across every agent your people run.
- Skills carry a dual attack surface: the code layer (shell or Python the skill can execute) and the natural-language instruction layer (markdown the agent reads and obeys).
- Hidden instructions in a skill's documentation are indirect prompt injection through a trusted-looking package, and traditional code scanners never read them.
- Skills can persist by writing to agent identity files like SOUL.md and MEMORY.md, so a payload can outlive the session that installed it.
- Skills are a bottom-up shadow-IT surface - installed without review - so seeing them is the first control; skills are one of the eight artifact types Anomity inventories.
Ask a developer what an AI agent skill is and you will usually get a practical answer: it is a thing you drop into your agent to make it better at something. Format a changelog, scaffold a service, run a deploy, query a database - there is a skill for it, and installing one is as easy as copying a folder. That ease is exactly why skills have quietly become one of the most consequential surfaces in agentic security. A skill is not a document, even though it looks like one. It is a capability that runs with your agent's full permissions, and most organizations have no idea how many are installed or what they can do.
This primer defines agent skills precisely, explains how they load and why they behave like installable software, and lays out the security surface they create - including the part most teams miss. It is the foundational entry point for our skills-security cluster; once the concepts here are clear, the OWASP Agentic Skills Top 10 guide walks the specific risks and controls in detail.
What an agent skill actually is
An agent skill is a reusable capability package that loads into an AI agent and runs with the agent's full permissions. In practice it is a folder containing two things: markdown instructions the agent reads and follows, and code - typically shell or Python - the agent can invoke. Some skills are almost entirely instructions (a detailed recipe for how to do a task); others bundle substantial code (scripts, helpers, tools). Either way, once loaded, the skill is part of the agent's behavior for that session.
The critical property is what happens at the boundary. Installing a browser extension prompts you to grant permissions. Loading a skill usually does not. The skill simply inherits whatever the agent can already do on that endpoint - its filesystem access, its network reach, its mounted credentials, its ability to call MCP servers and shell out. There is no separate skill identity and no separate scope. The skill is the agent, for as long as it is loaded. That inheritance is the root of nearly every risk that follows, which is why we treat it as an architectural problem in least privilege for agent skills.
How a skill loads
Loading is straightforward, which is part of the problem. The agent discovers the skill from a local directory or fetches it from a repository, reads its markdown into context as instructions it should follow, and registers any bundled code as something it can run. From that point the agent treats the skill's guidance the way it treats a user's instructions - as intent to act on. No review gate, no sandbox by default, no attestation of where the skill came from. The same folder that teaches an agent to format a report can teach it to read every environment variable and post it to a URL, and the loading mechanism does not distinguish between the two.
Why skills work across every agent - and why that matters
The skill format is largely portable. The same package can load into OpenClaw, Claude Code, Cursor, and VS Code, which is a genuine convenience for developers and a genuine multiplier for risk. A skill written once spreads across every agent your people run, so a useful capability propagates fast - and so does a payload. One compromised skill shared in a team channel can land on dozens of machines that each hold cloud credentials and source access. Cross-platform reuse means a skills policy that covers only one agent covers almost nothing; the surface is every agent on every endpoint. The mass-exposure dynamic is not hypothetical, as the OpenClaw security crisis showed.
The dual attack surface: code and instructions
The single most important idea in this primer is that a skill attacks through two channels at once, and they demand different defenses.
| Skill component | What it can do | Why it is risky |
|---|---|---|
| Bundled code (shell/Python) | Runs with the agent's full permissions - read files, make network calls, invoke tools and MCP servers. | A malicious or compromised script executes with everything the agent has; classic supply-chain and malware target. |
| Markdown instructions | The agent reads and follows the prose as guidance, like a user's instructions. | Hidden or obfuscated directives are indirect prompt injection in a trusted-looking package; code scanners never read prose. |
| Metadata / manifest | Declares the skill's name, author, version, and capabilities used for vetting and inventory. | If spoofable or unverified, a skill can misrepresent what it is and defeat trust decisions from the start. |
| External fetches | Pulls templates, configs, or data from URLs or repos at runtime. | Untrusted external content can carry instructions the agent then follows mid-task. |
| Identity / memory writes | Writes to agent files like SOUL.md and MEMORY.md that persist across sessions. | Lets a payload reload on every start and outlive the skill's removal - a durable foothold. |
The code layer
The code a skill carries executes with the agent's privileges. This is the surface people expect: a script that reads credentials, opens a reverse shell, tampers with a build, or exfiltrates data. It is the target of supply-chain compromise, where a trusted skill or one of its dependencies is poisoned upstream, and of dependency takeover, where an attacker seizes an abandoned skill and pushes malicious updates to everyone who installs it. We cover those patterns in skilljacking and abandoned-skill takeover and the broader AI supply chain attacks guide.
The natural-language instruction layer
This is the surface teams miss. A skill's markdown is not inert documentation - the agent reads it and acts on it. That means a skill can carry instructions the agent will follow as if they came from the user: add an undocumented step, weaken a safety check, contact an attacker-controlled endpoint, or ignore a policy. These directives can be hidden in plausible-looking prose, tucked into examples, or obfuscated. It is indirect prompt injection delivered through a package that a code review would wave through, because the payload is English, not code. Researchers have demonstrated exactly this class of hidden payload, detailed in malicious agent skills and hidden payloads.
Persistence: how a skill outlives its session
A skill's danger does not have to end when the session does. Agents commonly keep identity and memory files - names like SOUL.md and MEMORY.md - that shape their behavior across restarts. A skill with write access to those files (which, by inheritance, it usually has) can plant instructions that reload every time the agent starts. The result is persistence: a payload that survives closing the session, and can even survive removing the skill itself, because the malicious instruction now lives in the agent's own memory rather than in the skill folder. Persistence turns a one-time run into a standing compromise, and it is why removing a suspicious skill is not the same as remediating it - you also have to inspect what it may have written.
Why traditional scanning misses the threat
Most detection tooling was built for code. Static analyzers, dependency scanners, and antivirus all reason about code paths, signatures, and known-bad binaries. None of that reads a skill's markdown as instructions, so a plain-English directive to exfiltrate data or disable a check produces zero findings - it is a comment, as far as the scanner is concerned. Even on the code layer, skills evade point-in-time scans through update drift: a skill vetted clean today can auto-update to a payload next week, so a green scan describes only the version you happened to look at. Effective coverage has to inspect both layers, treat hidden instructions as first-class findings, and re-check on every change - which is a monitoring problem, not a one-time scan.
Skills are shadow IT with execution rights
Put the pieces together and skills fit the shadow-IT pattern almost perfectly - with a sharper edge. They arrive bottom-up: a developer adds one because it saves time, shares it because it helps the team, and no one in security is in the loop. Unlike a rogue SaaS signup, though, a skill runs code and steers an autonomous agent that already holds real credentials and real access. It is shadow IT with execution rights and no permission prompt. That is why the first control for skills is not a scanner or a policy engine - it is visibility. You cannot vet, scope, isolate, or govern skills you have never seen, which is the same lesson we draw for the whole artifact layer in AI agents are the new shadow IT.
Where Anomity fits
Anomity's category is agentic endpoint security, and its principle is the one this primer keeps arriving at: you can't govern what you can't see. A lightweight, unprivileged Endpoint Sensor runs on every managed endpoint - Windows, macOS, and Linux - and discovers eight AI artifact types: AI agents, MCP servers, extensions, plugins, skills, secrets, hooks, and CLIs. Skills are one of the eight. For each installed skill, Anomity records where it came from, who installed it, its version, and what it can reach, giving security the inventory that skills governance has to start from.
The sensor sends metadata only over HTTPS to the Anomity Cloud - never source code, never prompts - and redacts secrets on the endpoint. On agents that expose a hook, Anomity evaluates each tool call a skill triggers and returns allow, deny, or log before it runs, so an unexpected shell command or network call from a manipulated or over-privileged skill is checked against policy first. Continuous evaluation surfaces update drift as a change event, violations route to your SIEM, Slack, email, and Jira, and every skill added, removed, or modified lands in a queryable 90-day audit trail - which is exactly what you need to answer whether a suspicious skill wrote to a memory file before you removed it. Anomity is SOC 2 Type II and complements your existing EDR/XDR, DLP, network controls, and GRC rather than replacing them.
You can't govern what you can't see.The Anomity principle
The bottom line
An agent skill looks like documentation and behaves like installed software with your agent's full permissions. It attacks through two channels - executable code and natural-language instructions - it can persist by writing to the agent's own memory, and it spreads across every platform that loads the shared format. Traditional code scanning reads only half of it, and most organizations cannot see any of it. The path forward is the one that holds for the whole artifact layer: inventory every skill first, then vet before install and scope tightly at runtime. To go deeper, read the OWASP Agentic Skills Top 10 guide; to see your own skills posture, book a 30-minute demo.
Frequently asked questions
What is an AI agent skill in plain terms?
A skill is a small package - usually a folder containing markdown instructions and some supporting code - that you add to an AI agent to teach it a new capability, like running a deploy or formatting a report. When the agent loads the skill, the skill's instructions become part of how the agent behaves and its code runs with the agent's permissions. It is the agent equivalent of installing a plugin, except it ships as documentation.
How does a skill actually load into an agent?
The agent reads the skill from a local directory or a fetched repository, ingests its markdown as instructions it should follow, and makes any bundled code available to invoke. There is usually no permission prompt at the skill boundary - the skill simply inherits whatever the agent can already do on the endpoint, including its credentials, file access, and network reach.
Why are skills considered a shadow-IT surface?
Because they spread bottom-up with no review. A developer finds a useful skill, drops it in, and shares it with the team; no ticket is filed and security never sees it. That is the same dynamic we describe in AI agents are the new shadow IT, and skills are the sharpest version of it because one shared skill can propagate across an org in days.
What is the dual attack surface of a skill?
A skill can attack through two channels at once. The code layer is the shell or Python it can execute with the agent's privileges - the classic malware and supply-chain target. The instruction layer is the natural-language markdown the agent reads and follows, which can carry hidden directives that steer the agent. Defending one without the other leaves a skill effectively unguarded.
Why doesn't traditional code scanning catch malicious skills?
Code scanners inspect code, not prose. A malicious instruction written in plain English inside a skill's markdown - telling the agent to weaken a check, add a step, or contact an external endpoint - is invisible to a static analyzer because it is documentation, not a function. This is why a skill can pass every code scan and still be dangerous, and why the natural-language layer needs its own review. See indirect prompt injection explained.
How can a skill persist beyond one session?
Agents often keep identity and memory files - SOUL.md, MEMORY.md, and similar - that shape their behavior across sessions. A skill that can write to those files can plant instructions that reload every time the agent starts, so a payload outlives the session that installed it and even survives removing the skill itself. Persistence is what turns a one-time run into a durable foothold.
How does Anomity help with agent skills?
Skills are one of the eight AI artifact types Anomity's lightweight Endpoint Sensor discovers and inventories, alongside agents, MCP servers, extensions, plugins, secrets, hooks, and CLIs. For each skill it records the source, owner, version, and reach, sends metadata only (never source or prompts), and on agents that expose a hook it allows, denies, or logs each tool call before it runs. Every change lands in a queryable 90-day audit trail.
What should a security team do first about skills?
Inventory them. You cannot vet, scope, or govern skills you cannot see, so the first step is discovering every skill installed across every endpoint, who installed it, and where it came from. From there, add a vetting step before install and least privilege at runtime. Start with how to build an AI agent inventory.
