Least Privilege for Agent Skills: Scoping Permissions, Metadata, and Isolation

Here is the fact that makes agent skills different from ordinary plugins: a skill runs with the agent's full permissions. It does not get its own sandboxed, cut-down set of rights by default. When a skill loads, it inherits everything the agent hosting it can do, every file the agent can read, every tool the agent can call, every network destination the agent can reach. So the moment an over-scoped or malicious skill is installed, it is not asking for permission. It already has all of the agent's.

That is why least privilege for skills is its own discipline. It is not enough to scope the agent well. You also have to scope what each capability package running inside that agent can reach, keep its metadata from becoming an execution vector, and isolate it from the host. This guide walks those three problems, organized around the December 2025 OWASP Top 10 for Agentic Skills: AST03 Over-Privileged Skills, AST04 Insecure Metadata, and AST06 Weak Isolation. For the framework in full, start with the OWASP Agentic Skills Top 10 guide.

Skill least privilege is not agent least privilege

It is easy to conflate these two, and the conflation leaves a gap. We have a separate, broader guide on least privilege for AI agents, and it is about a different layer. That guide is about the agent's identity and credentials: giving each agent a dedicated, scoped, short-lived credential so the agent as a principal cannot reach more than its job requires. It answers the question, what can this agent authenticate as and access?

This guide is about the layer inside the agent. A skill is a capability package that the agent loads and runs, and it operates within the agent's authority. Skill least privilege answers a different question: given that the agent can reach many things, how do we make sure this particular skill can only reach the sliver its function needs? You need both controls. A perfectly scoped agent identity still inherits risk from an over-privileged skill running within it, because the skill executes as the agent. Scoping the agent bounds the outer envelope; scoping the skill bounds what a single capability inside that envelope can do.

AST03: over-privileged skills and the inheritance problem

AST03 Over-Privileged Skills is the core failure, and it follows directly from inheritance. Because a skill runs with the agent's full permissions, any capability the skill holds beyond its actual function is pure downside. A skill that formats a document does not need network egress. A skill that reads one project file does not need broad filesystem access. A skill that calls one internal API does not need a wildcard scope across all of them. Every excess capability is a capability an attacker gains the instant that skill turns out to be malicious, gets hijacked, or is steered by untrusted input.

The fix is to scope each skill to only what its function requires, and to treat any broad or wildcard grant as a defect. That means reading what the skill actually does, comparing it to what it can reach, and closing the gap. It also means the skill's requested scope should be an explicit, reviewable declaration, not an implicit consequence of running inside a powerful agent. The same excessive-permissions logic that OWASP applies to agents applies here, with the added twist that the skill borrows the agent's power rather than holding its own.

AST04: metadata is an execution vector, not just settings

A skill ships with configuration and metadata: a manifest describing the skill, config files that set its behavior, and similar bundled data. The intuitive assumption is that this data is inert, that it configures the skill but does not run. AST04 Insecure Metadata is what happens when that assumption is wrong. If a skill's config format is parsed with an unsafe deserializer, or the metadata is processed in a way that can invoke code, then loading the config file is itself code execution. The malicious payload never has to be in the obvious code layer; it can hide in what looks like settings.

Metadata hygiene closes this. Use safe parsers that cannot instantiate arbitrary objects or execute code, treat every config file as untrusted input, and never allow metadata to run code on load. During review, read the config files with the same suspicion you apply to code, because in an AST04 world they are code. This is one of the reasons a skill's markdown and config surface has to be part of vetting, a point we make in the vetting and approving skills playbook.

AST06: weak isolation lets a skill roam the host

Even a correctly scoped, clean-metadata skill is a risk if it runs with the run of the host. AST06 Weak Isolation is the failure where a skill is not sandboxed from the machine it executes on, so it can read the host filesystem, open arbitrary network connections, spawn processes, and interfere with other skills, all far beyond its stated function. Isolation is the containment that assumes a skill might misbehave and bounds the damage when it does.

Practical isolation means running each skill in a sandbox that restricts filesystem, network, and process access to what the skill's function needs. A skill that transforms text in memory should not be able to touch the disk or the network at all. A skill that reads one directory should not see the rest of the filesystem. Isolation also keeps skills from touching each other, so a compromised skill cannot pivot into a trusted one. This is the same architectural-control logic behind sandboxing agents generally: enforcement has to live somewhere the skill cannot reach, because a skill running with the agent's authority can otherwise defeat controls it hosts itself.

Over-privilege smells and their fixes

In practice, over-privilege shows up as a handful of recurring smells. Here is how to recognize each one, why it is dangerous, and what to do about it.

You cannot scope what you have not inventoried

Every control above shares one precondition: you have to know what each skill can actually do. Scoping assumes you can compare a skill's function to its reach. Metadata hygiene assumes you know which config files a skill loads. Isolation assumes you know what a skill touches so you can bound it. If skills are pulled onto developer machines with no inventory, none of this is possible, and over-privilege accumulates unseen, exactly the way it does for agent identities.

Inventorying skills is the same Discover-and-Understand work that underpins any non-human identity program, and it belongs alongside the agent and MCP inventories described in how to build an AI agent inventory and the broader non-human identity governance guide. Knowing what each skill can reach is not a nice-to-have; it is the first control, because it is what makes the rest enforceable.

Where Anomity fits

This visibility layer is where Anomity sits. Its lightweight, unprivileged Endpoint Sensor runs on every managed endpoint (Windows, macOS, Linux) and discovers skills as one of the eight AI artifact types it inventories, alongside agents, MCP servers, extensions, plugins, secrets, hooks, and CLIs. It sends metadata only over HTTPS, never source code and never prompts, with secrets redacted on the endpoint. That inventory is what lets you see which skills are installed and what each one can reach, so an over-scoped skill is visible rather than latent.

Continuous policy evaluation flags skills that are over-scoped or newly modified, and violations route to your SIEM, Slack, email, and Jira. On agents that expose a hook, Anomity applies runtime governance, returning allow, deny, or log on each tool call before it runs, which is how a skill reaching beyond its scope at runtime gets contained rather than executed. Every added, removed, or modified skill lands in a queryable 90-day audit trail. Anomity is SOC 2 Type II and complements, rather than replaces, your EDR, DLP, network, and GRC controls. As the principle goes: you can't govern what you can't see. See the features overview for the full picture.

The bottom line

A skill runs with the agent's full permissions, so least privilege for skills is about bounding what a capability package inside the agent can reach, not about the agent's identity. Scope each skill to only what its function needs and treat wildcard grants as defects (AST03). Keep metadata from becoming an execution vector by using safe parsers and forbidding code execution on load (AST04). Isolate each skill so it cannot roam the host or touch other skills (AST06). And underneath all three, inventory every skill and what it can do, because you cannot scope, clean, or contain what you have not seen. Combine this with a strong agent-identity program and a vetting pipeline, and an over-privileged skill stops being a fleet-wide blast radius and becomes a bounded, observable component.