Your AI Agent Inventory Is Missing Something: Skills Are Part of the Attack Surface

Security teams are getting better at asking which AI agents are operating in their environments. But an agent inventory only answers part of the question. To understand the risk, teams also need to know what those agents can do.

What happens when a developer installs a skill containing malicious instructions? Or when an existing skill is modified to direct an agent toward unsafe actions? Security teams may know which coding agents are being used without knowing which skills are available to them, where those skills originated, or whether their instructions introduce security risks.

Skills give agents instructions for carrying out specialized tasks. A coding agent, for example, might use a skill to work with a repository or follow a particular development workflow. The skill can shape how the agent approaches a task and how it uses tools already available to it.

That makes skills useful. But skills can also introduce risk when their instructions are malicious, compromised, or inappropriate for the environment in which they’re used. An agent’s skills can affect the actions it may take and the consequences if it behaves in an unsafe or unintended way. Skills belong in the conversation about the agentic attack surface. Understanding which skills are available, what they instruct agents to do, and the risks they introduce is an important part of securing the agentic attack surface.

An agent inventory needs to account for capabilities

Asset inventories help security teams identify the systems and resources in their environment: endpoints, applications, cloud services, identities, models, and agents. Agentic systems add another question: what capabilities are available to each agent?

Consider two developers using the same coding agent. One has a skill that helps with routine repository tasks such as reviewing pull requests. The other has a skill that guides the agent through a workflow involving code and configuration changes. The underlying agent is the same, but the skills available to each may affect how it works and which existing tools or resources it uses.

An inventory that records only the agent misses that context. The agent tells you what is present; its skills help explain how it may behave.

This creates a distinct security challenge. Skills can be installed, updated, or modified independently of the underlying agent. A developer might add a skill locally or introduce one through a skills repository without triggering an established security review. As a result, an organization’s agent inventory may remain unchanged even as the instructions influencing agent behavior evolve.

A skill does not necessarily give an agent access it did not already have. Its impact depends on the agent’s tools, permissions, and environment. But instructions can still influence how the agent uses those capabilities, so security teams need to understand both the skill and the access surrounding it.

Skills can introduce risk without changing the agent

A new application or endpoint may prompt a security review. A new skill added to an agent may receive less attention, even when it changes how that agent handles a task.

The risk isn’t limited to skills that are intentionally malicious. A legitimate skill may contain poorly designed instructions, a previously trusted skill could be compromised, or a skill obtained from an untrusted source could introduce unexpected behavior. In some cases, malicious instructions may be embedded among legitimate instructions or placed within supporting files, making them harder to recognize during a superficial review.

Consider a skill designed to automate repository maintenance. It might legitimately instruct an agent to review files, identify outdated dependencies, and suggest configuration changes. It could automatically approve pull requests when it shouldn’t, impacting production. But if the skill also contains instructions directing the agent to access sensitive files or transmit information to an external destination, it could steer the agent toward actions the developer never intended.

The presence of malicious instructions does not guarantee that an agent will follow them. The potential impact depends on the agent’s available tools, permissions, environment, and security controls. However, even instructions that appear harmless in isolation may introduce risk when combined with broader access.

That makes a few practical details important: where the skill came from, what its instructions tell the agent to do, which tools or resources the agent can use, and whether the skill is appropriate for the people and projects where it is available.

Security teams also need to consider whether a skill has changed since it was last reviewed and whether its instructions reference additional files or resources that could influence agent behavior.

A skill may be poorly designed, malicious, or compromised. If its instructions conflict with what a user or organization intended, the agent could be guided toward unsafe behavior. The potential impact will depend on the agent’s permissions and the controls around it.

The key question is not simply whether a skill exists. It is what the skill encourages the agent to do, and what the agent is able to do in response.

Capability visibility complements runtime monitoring

Runtime monitoring helps answer what an agent did: what it accessed, whether its behavior looked suspicious, and whether it violated a policy. Capability visibility answers a different question: what could the agent do, given the skills, tools, and permissions available to it?

Security teams need both views. Runtime monitoring can identify activity as it happens. Reviewing capabilities can help teams assess risk before those capabilities are used.

For example, identifying a skill that instructs an agent to interact with sensitive files gives security teams an opportunity to assess whether that behavior is appropriate before the skill is used. Runtime monitoring and enforcement provide another layer of protection by helping detect or prevent unsafe actions if the agent attempts them.

This is similar to how security teams approach identity. They monitor activity, but they also review what a person or account is authorized to access. Agent security requires the same attention to available capability.

Neither approach is sufficient on its own. Knowing which skills are available does not guarantee that an agent will behave safely, just as monitoring agent activity does not necessarily reveal every risky capability before it is used. Together, these approaches provide a more complete understanding of agentic risk.

Build skills into the review process

Organizations can begin by identifying which skills are available to their agents and understanding what each one is designed to do. That means looking beyond skill names to the instructions they contain, the tools the agent can use alongside them, and the resources those tools can reach.

A practical approach follows three steps: discover, assess, and govern.

Discover: Identify the skills available to agents. Understanding where skills originate and how they are updated helps teams identify potential gaps in visibility.

Assess: Evaluate what each skill instructs the agent to do and whether those instructions introduce security risks.This includes reviewing skills for potentially malicious instructions, unsafe workflows, and access to sensitive resources.

Govern: Determine which skills should be permitted based on their purpose, risk, and the environment in which they will be used. Establish processes for reviewing new or modified skills and restricting those that introduce unacceptable risk.

From there, teams can decide whether each skill belongs in a particular environment. A capability may be appropriate for one developer or project and unnecessary for another. Higher-impact workflows may call for tighter access, additional review, or other controls.

For example, a skill that helps a coding agent generate documentation or review code may present a different risk profile than one that directs it to modify application code, update dependencies, or change security configurations. A skill used in a local development environment may also introduce different risks when available to an agent with access to sensitive repositories, credentials, or production systems. The appropriate decision depends not only on what the skill is designed to do, but also on the permissions and resources available to the agent using it.

This gives teams a more complete basis for deciding which skills to allow and under what conditions.

Expand the inventory to include what agents can do

As agents become more configurable, knowing which agents are present provides only part of the security picture. Skills help shape how agents use their available tools, so teams need visibility into both the agent and the capabilities associated with it.

But visibility is only the starting point. Without understanding the risks introduced by those capabilities, organizations may overlook malicious instructions, inappropriate access, or changes to previously trusted skills.

That added context can help security teams assess whether a capability is appropriate, identify where additional controls may be needed, and understand the potential impact if an agent behaves in an unsafe way.

An agent inventory shows which systems are in use. A capability inventory helps explain what those systems may do. Discovering, assessing, and governing those capabilities helps organizations move beyond simply knowing what exists to managing the risks associated with what their agents can do.

All are needed to understand the agentic attack surface.