When a Skill Becomes a Shadow Agent

Agent skills are becoming one of the most useful patterns in the agent ecosystem. They are lightweight, portable, easy to author, and intuitive for developers who already live inside AI-assisted workflows. They are also a potential vector for shadow agents.

What are skills? Skills are composable knowledge artifacts that tell agents how to do something, not what to do. A good skill can teach an agent how your organization writes. It can explain your project taxonomy, define what “high-quality content” means for your team, describe a database schema, a release checklist, a review rubric, or the tone a customer-facing answer should use. 

Skills sit alongside two other building blocks of an agent system. Tools are the concrete actions an agent can take: API calls, database writes, sending a message. Agents are the execution layer that runs work using those tools under a defined identity and set of permissions. Where the lines between these three get drawn is what determines whether the system can be governed.

In theory, these layers are distinct. In practice, the boundary blurs, which raises an architectural question:

Should skills only give agents knowledge, or should they also grant new capabilities?

Skills work best as the knowledge layer. Capabilities belong with agents, where they can be governed.

The reason shows up in how skills actually get used. A solo developer running an agent on their own machine can reasonably keep everything in one place: instructions, scripts, references, tool hints, all in a single directory. The blast radius is personal.

Production is different. Once a skill brings tools, code, credentials, scheduling behavior, or operational state, it behaves like an agent. The more a skill behaves like an agent, the more it needs to be operated like one.

For security leaders watching their teams adopt these tools, this has the same shape as the shadow IT problem, just moved up the stack.

A knowledge-only skill changes what an agent knows. A capability-heavy skill changes what an agent can do.

Consider a skill that says:

“When writing public project updates use a neutral, technically precise tone. Avoid hype. Explain concrete outcomes.”

The parent agent’s tools, credentials, logs, and permissions are unchanged. The skill has shaped behavior, nothing more.

Now consider a skill that says:

“Look up a LinkedIn profile, find the associated company, and pull its ZoomInfo record.”

That is an operational workflow. It comes with a different set of questions:

• What tools can it call?
• What credentials can it access?
• What external systems can it mutate?
• Where do its logs go?
• What version ran?
• Who owns it?
• How do we test it?
• How do we disable it?
• How do we know what happened when something goes wrong?

Those are agent-runtime questions. A SKILL.md file cannot answer them.

The core distinction is this: skills are knowledge, tools are action. Keeping them separate is what makes governance tractable. It is also what Guild.ai’s control plane is built around. Identity, scoped credentials, policy enforcement, and audit are applied at the tool layer, where actions and consequences live. The skill layer stays open for teams to author and share knowledge freely, without needing to negotiate with a security review for every prompt update.

Public skill catalogs already show the spectrum. SkillsMP aggregates more than 1.6 million SKILL.md files from public GitHub repositories. Some are pure guidance: writing rubrics, framework conventions, schema definitions. Others bundle multi-agent workflows, CLI dependencies, web scraping, scheduling, and secrets handling. Both ship under the same file format. Both install with the same one-line command. The boundary between them exists only in the author’s intent, which the runtime cannot see.

Shadow IT happened because employees adopted SaaS tools faster than security could review them. The result was an enterprise running on systems IT did not provision, with data flowing through accounts IT did not own.

Shadow agents are the agent-era version of the same dynamic. A capability-heavy skill, installed by a developer with a one-line command, can grant tools and credentials no one approved. It runs without an identity tied to the organization. It writes to systems without audit. It is still presented as just a skill.

A shadow agent is an execution unit without the lifecycle controls every other execution unit in the stack has. Instructions, scripts, tools, credentials, side effects, all bundled into a portable file. The parent agent that loads it becomes harder to reason about. Its effective behavior depends on which skills were loaded, what those skills quietly enabled, and how the parent agent interpreted them. Scope expands. Attack surface expands. Debugging surface expands.

Because the boundary is implicit, teams lose the operational handles they need in production.

A fair counterargument: if a parent agent can call a subagent with tools, isn’t that the same risk as a skill granting tools?

The raw capability may be similar but the control surface is different. A subagent gives the platform a concrete boundary:

• Explicit identity
• Explicit toolset
• Can run in a separate runtime or container
• Can use separate credentials
• Produces its own logs and traces
• Can be evaluated independently
• Can be versioned, reviewed, disabled, and permissioned independently
• Its invocation is a visible delegation event

A capability-heavy skill collapses that boundary into the parent agent. The parent agent becomes larger and less legible.

Subagents make risk explicit, observable, and governable. That is the point of the boundary, even when the underlying risk is similar.

When designing an agent workflow, this test is useful:

The goal is architectural legibility as systems move from personal experimentation into shared, production use.

A skill should help an agent reason better. An agent or subagent should be responsible for doing work that has permissions, tools, and operational consequences.

That boundary gives teams the best of both worlds:

• Skills stay easy to write, share, search, and load.
• Tools stay explicit and permissioned.
• Agents stay observable and debuggable.
• Subagents give complex workflows their own runtime boundary.

There are two truths to remember:

• Knowledge should be easy to share. 
• Capability should be explicit to govern.