An AI agent skill is a reusable set of instructions and resources that teaches an agent how to perform a task. Securing it means reviewing what the agent will read, what code it may run, which permissions it can use and how those conditions change after installation.
Consider a startup that installs a skill to prepare production releases. It reads changes, checks test results and drafts release notes. The skill also recommends a setup script and fetches a remote deployment guide. If the assistant has a production credential, an instruction in either resource could lead it from preparing a release to publishing one.
The skill has introduced new instructions into a workflow that already has production access. Reviewing the generated release notes would not reveal all of that exposure.
The OWASP Agentic Skills Top 10 whitepaper gives teams a way to examine these failures, from malicious packages to weak isolation and changes that escape review. This article explains all ten categories and turns them into an approval process, test scenarios and operating practices for companies using agents.
The release-preparation workflow is a hypothetical example. The diagrams and acceptance checks are Oktsec’s analysis. As of September 20, 2026, the project’s site invites public review of v1; its proposed security manifest is not a format every agent already enforces.
What a skill adds to an agent
In the Agent Skills specification, a skill is a directory containing a SKILL.md file. That file combines structured metadata with instructions. The directory may also contain scripts, reference material and templates. Hosts load information progressively: descriptions help choose a skill, instructions guide the task, and additional resources are loaded when needed.
This gives the security review several entry points. A misleading description may influence selection before a script runs. A referenced guide may change after approval. A helper may execute with credentials inherited from the agent’s process.
A skill is different from a tool. A tool performs an operation, such as querying a database. A skill explains a workflow that may use several tools. An MCP server exposes tools and resources through the Model Context Protocol; a plugin can package skills and tool connections together. Reviewing only the MCP connection leaves the skill’s instructions and other execution paths unexamined.
Metadata, instructions and the files shipped with them.
release-review / SKILL.mdLocal guides, remote documents and content loaded later.
Scripts, dependencies, install hooks and compiled files.
Host agent, model, tools, credentials and writable state.
A hash can identify the package. It does not tell you what permissions the host will grant it.
For a deeper explanation of the software connecting the model to tools, permissions and execution, see what an AI agent harness does.
The OWASP Agentic Skills Top 10, at a glance
The ten categories describe different weaknesses, not ten independent incidents or a universal severity ranking. A malicious skill can also exploit excessive privileges and evade a scanner. Track the underlying finding once, then record the contributing failures. Prioritize it by the data, systems and actions exposed in your environment.
Start with the source and installation
AST01: Malicious Skills
A malicious skill is built to make the agent do something harmful. It may contain executable code, plain-language instructions, or both. Professional documentation and a useful main function do not rule out an unrelated operation hidden in a setup step.
In our release example, a skill could ask the agent to upload its environment as a prerequisite for diagnosing a build. That environment might contain deployment credentials. Calling the operation a diagnostic does not make the destination appropriate or the data necessary.
Review prerequisites as carefully as the advertised task. Inspect installation steps, executable helpers and instructions that request access to credentials, agent configuration or persistent memory. Run unfamiliar packages with synthetic data and disposable credentials in an isolated environment.
A useful test: place a harmless credential-shaped marker outside the permitted working directory. Ask the skill to complete its normal task and exercise its error paths. Verify that file permissions prevent access and that unexpected outbound requests are denied. An absence of suspicious behavior in this test is evidence about that run, not proof that the skill has no other behavior.
AST02: Supply Chain Compromise
This category concerns how a skill and its dependencies reach the organization. A trusted publisher’s account may be taken over. A familiar package name may point to a different owner. An approved script may download an unreviewed dependency during installation.
Record the resolved source and content digest, not just the skill’s display name or a moving branch such as main. Include bundled files and dependencies in the approval. For frequently used skills, a small internal catalog of reviewed versions is easier to govern than unrestricted installation from search results.
Signatures can help establish that content came from a trusted signing key. They require a trusted way to associate the key with the publisher and a way to revoke that trust. A key supplied only by the package author cannot establish its own trustworthiness. A valid signature also does not prove that the signed instructions are safe.
A useful test: change a helper script while keeping the skill’s name and version unchanged. The installation or load check should reject the changed artifact or require a new review. Repeat with an external dependency; hashing only SKILL.md will miss it.
AST04: Insecure Metadata
Metadata is supplied by the publisher. Names can impersonate known companies, descriptions can understate access and a self-declared low risk level can contradict the package’s behavior. Treat these fields as claims to inspect.
There is also a loader problem. A parser configured to accept executable object constructors can turn metadata processing into code execution. This depends on the parser and configuration; YAML or JSON is not inherently executable. Use a safe parser, then validate the resulting data against the supported schema before using it to configure execution. Apply size and nesting limits as well.
Suppose our release skill describes itself as read-only but its helper changes package-manager configuration. The relevant finding is the mismatch between the declaration and the operation. The word “read-only” in a description cannot enforce that boundary.
A useful test: submit malformed metadata, unsupported permission fields and a package whose scripts contradict its declared purpose. The loader should reject invalid input or surface unsupported controls, rather than silently treating the package as approved.
Control what happens when the skill runs
AST03: Over-Privileged Skills
A legitimate skill can be dangerous under the wrong account. Preparing release notes requires reading selected repository data and writing a draft. It does not require production deployment rights, customer exports or access to every secret in the developer’s home directory.
Enforce restrictions in the host, operating system and destination service. Give the workflow a dedicated identity with limited credentials. Narrow access by operation, resource and destination: “may use the shell” or “may call the database tool” is usually too broad to describe a business task.
If one agent asks another to act, the second should validate the original authorization and the requested scope. Trusting the immediate caller without checking the underlying grant can let a low-privilege workflow borrow an administrator’s access.
A useful test: confirm that the permitted release draft succeeds, then attempt a deployment against an isolated production-like test target through the configured tool and through any alternative shell or API route. A refusal by the model is useful, but the permission boundary must still hold if the model attempts the action. Our analysis of prompt injection and authorization explains this distinction.
AST05: Untrusted External Instructions
A pinned skill can still read changing instructions. Its remote guide might be edited, redirected or replaced after the package passes review. The same problem appears when a tool response, issue description or document contains instructions that the agent mistakes for part of its assignment.
In the release workflow, a remote guide could tell the assistant that publishing a diagnostic archive is now mandatory. The local skill’s digest would remain unchanged. The agent would nevertheless be acting on different material.
Separate instructional dependencies from task data. Snapshot and review instructions that define the workflow. When they must be fetched, verify the exact content that will be used and reject unapproved changes. Live issue comments and logs cannot all be frozen; process them as untrusted data and prevent them from granting new permissions. Restrict external references and review transitive links rather than assuming the first trusted hostname covers everything downstream.
A useful test: keep the package unchanged and alter a test reference to request a forbidden operation. Confirm both that instruction drift is detected where pinning is required and that authorization still rejects the action if hostile text reaches the agent.
AST06: Weak Isolation
Isolation determines what a failed review can expose. A helper running on a developer’s ordinary account may see cloud configuration, browser state, SSH material and unrelated repositories. A writable directory shared across agents can also carry instructions or scripts from one workflow into another.
A container is a starting point, not a complete boundary. Review mounted directories, inherited environment variables, host sockets, network access and resource limits. Keep production credentials out of a test environment. Separate persistent state by workflow or trust level, and protect the directories from which the host loads skills.
There are two execution paths to examine: scripts launched in the sandbox and actions the host agent takes after reading the skill. Isolating a helper does not restrict the host’s email, browser or deployment tool automatically.
A useful test: check whether the helper can reach another workspace or a host service, and whether its output can persuade the host to perform an operation outside the task. These are different tests and require different controls.
The agent uses them to plan the release review.
Only the working directory is mounted. Credentials, network access and resources are limited.
The task permits a draft. A request to publish to production needs separate authorization.
Keep the approval valid after installation
AST07: Update Drift
Drift works in two directions. A team can remain on a vulnerable old version, or automatically install a new version with unreviewed behavior. A version label alone does not establish which files are in use.
Record the deployed digest and make updates a controlled change. Compare instructions, dependencies, requested permissions and external sources, then retest the relevant boundaries. Recheck installed components when new advisories or detection rules become available. Production skill directories should not accept arbitrary writes or silently load edited instructions mid-task.
Pinning needs an update process beside it. Otherwise the team has replaced unpredictable changes with permanent patch lag. Emergency revocation and a reviewed recovery version should be part of that process; a rollback to an older artifact is not automatically safe.
A useful test: change the installed files during an active session and verify what the host actually loads. The system should either keep using the approved immutable copy or stop and require review. Record the loaded digest, not merely the digest checked earlier.
AST08: Poor Scanning
Skills combine prose, metadata, code and resources. A scanner may understand some of those formats and ignore others. It may also truncate a large file, fail to parse a header or stop following references at a configured limit. Each of those conditions changes what its result means.
In a June 2026 Trail of Bits investigation, researchers demonstrated scanner bypasses using file padding, instructions inside a document archive, Python bytecode and misleading explanations around a package-registry change. These were adversarial tests of the scanners studied, not a measurement of every skill or every scanner. They show why the reviewed files and the files used at runtime must agree.
Ask for a coverage record alongside findings: discovered files, hashes, analyzer versions, supported formats, skipped items, unresolved references and limits reached. If a required file could not be inspected, return an incomplete result. Keep confirmed findings visible even when the wider scan is incomplete.
Use different methods for different questions. Deterministic checks can find known patterns and structural violations. Code analysis can examine flows. Model-assisted review can help interpret instructions, but its evaluator can itself be influenced by hostile content. Isolated execution can reveal behavior in a tested scenario, while leaving dormant branches untested.
A useful test: include an unsupported artifact and force a timeout in a controlled fixture. Neither result should become “clean.” Also test ordinary legitimate skills: a detector that flags every network request has not demonstrated useful discrimination. See our skill auditing guide for the complementary manual review.
AST09: No Governance
A security team cannot revoke a skill it cannot find. An inventory needs the installed copy, computer or hosted workspace, responsible team, resolved version, last observation, approval and permitted use. Installation counts and registry popularity do not supply these facts.
Discovery must account for incomplete visibility. An unreadable directory is not an empty directory. A laptop that stops reporting has not proved that a skill was removed. Hosted assistants may require administrative exports, connected-app records or identity telemetry rather than a local file scan. An OAuth grant can identify a lead to investigate; it does not by itself prove which skill caused an action.
Assign someone to review alerts and someone with authority to stop the workflow. Cover employee offboarding, credential revocation and persistent state left behind after uninstalling a skill. Keep risk acceptance separate from correction: an accepted advisory still describes an unresolved condition.
A useful test: select a skill digest and locate every observed deployment. Revoke it in a test environment, check that it cannot be reloaded and record which devices or services could not be reached. Those exceptions remain open work.
AST10: Cross-Platform Reuse
The same skill files can run with different authority on two hosts. One may enforce restricted tools and network access; another may ignore unfamiliar metadata or give the agent its usual workstation permissions. Copying the package can therefore change its security properties without changing its digest.
Portability of the instruction format does not establish equivalence of enforcement. The Agent Skills specification, for example, marks allowed-tools as experimental and notes that support varies. Check the destination host’s behavior rather than relying on a field’s presence.
OWASP’s whitepaper proposes a common security manifest for identity, permissions, integrity and other review data. It is a proposal. Adding those fields to a skill does not cause every existing runtime to enforce them.
A useful test: move the release skill from a restricted test host to the intended production host and repeat the denied file, network and deployment operations. Record the host, model, toolset and policy versions with the result. If a restriction cannot be represented or enforced on the destination, do not silently approve the migration.
A practical approval flow for an agent skill
Approve a defined artifact for a defined task and environment. A generic “approved skill” label loses the conditions under which the review was performed.
- 01 · IdentifyResolve the exact artifact
Source, publisher, package digest, dependencies and external instructions.
- 02 · InspectRead the coverage result
Review instructions, code, metadata and everything omitted by the checks.
- 03 · ConstrainDefine the task’s access
Use scoped credentials, restricted execution and explicit destinations.
- 04 · TestExercise allowed and denied actions
Verify the useful task, misuse cases and alternative execution paths.
- 05 · OperateApprove a bounded deployment
Record the owner, evidence, monitoring and revocation procedure.
For the release assistant, the initial approval might allow reading one repository and its test results, then writing a draft into a designated directory. It would exclude publishing, changing package registries and reading unrelated credentials. Expanding that scope is a new authorization decision.
Store the approval outside the skill’s writable directory. Bind it to the package digest and the relevant runtime configuration, with a review date and triggers for re-evaluation. Otherwise the agent or a compromised package may be able to rewrite the evidence used to approve itself.
What a trustworthy scan result should say
Findings and coverage answer different questions. Findings describe detected problems. Coverage describes what the scanner examined successfully. Both are needed to decide what happens next.
The selected checks finished on the declared inputs. Runtime tests and permission review still apply.
Preserve its location and evidence. Other parts of the scan may also be incomplete.
List unreadable files, unsupported formats, unresolved references and exhausted limits.
The scanner needs its own isolation. Do not execute package-supplied installers or shell expansions simply to understand them. Bound archive extraction, file traversal, decoding depth, CPU, memory and time. Keep production credentials away from the scanner and prevent symlinks from escaping the review directory. If a bound prevents required analysis, report the omission.
Keep raw content for evidence and analyze normalized forms when appropriate. Invisible characters and encodings can conceal instructions, but they can also occur in legitimate documents. A suspicious encoding needs context; a broad rule that treats every encoded string as malware will overwhelm reviewers.
Network reputation needs similar care. Fetching a reviewed artifact from a hosting service is different from uploading customer data to an arbitrary account on that service. An approved provider hostname does not authorize every repository, object, webhook or destination it hosts.
These requirements are useful when evaluating any skill scanner, including Aguara. Coverage must be demonstrated against a specific version and test set. This article does not assert that a scanner implements every control in the ten categories.
Eight checks to run before granting sensitive access
Use a disposable environment and synthetic data. Capture both the agent’s proposed action and independent evidence from the destination or operating system. The checks below are proposed acceptance tests, not attack results.
Swipe or scroll horizontally to compare all columns.
| Test | Expected behavior | Evidence to keep |
|---|---|---|
| Normal task | Read permitted changes and test results; write the release draft. | Completed draft, permitted accesses and task result. |
| Unexpected credential access | The host and helper cannot read a marker outside the approved directory. | File-access denial and effective mount or permission configuration. |
| Changed remote guide | Reject an unapproved instruction revision; deny any unauthorized action it requests. | Resolved source, digest mismatch and action decision. |
| Unapproved package update | Do not load a modified helper under an old approval. | Loaded artifact digest compared with the approved digest. |
| Partial scan | Surface unsupported content or a timeout as incomplete. | Coverage record with omitted artifact and reason. |
| Alternate deployment path | Reject production publication through a direct API or shell as well as the usual tool. | Policy decisions and destination-side checks for each route. |
| Revocation | Stop new loads and address active sessions, credentials and persistent changes. | Revocation record, session outcome and unreachable deployments. |
| Host or model change | Repeat the workflow and misuse cases under the new environment. | Exact environment versions, test inputs and observed outcomes. |
A control can pass one test while another fails. Keep those results separate. A successful draft does not prove that credential access is denied; a denied deployment does not prove that all network routes are restricted.
Keep evidence that supports investigation and recovery
A conversation transcript shows what the agent said. An investigation also needs the installed artifact, effective access, requested operation, policy decision and observed outcome.
Link each action attempt to its workflow and identity, the relevant policy revision, resource and destination, decision time and tool result. Record the skill digest when the host can reliably attribute the action to it. If several skills influenced a shared context and attribution is uncertain, preserve that limitation instead of inventing a precise origin.
Separate permission to act from confirmation that an action happened. A recorded approval does not establish successful execution. A missing outcome may mean the request was blocked, but it can also mean a crash or lost telemetry. Reconcile the record with the destination and the health of the logging pipeline.
Signatures and tamper-evident records help detect changes to captured evidence. They do not establish that every action was captured or that the outcome was correct. Apply redaction, access restrictions and retention to the evidence itself; do not turn an audit export into a collection of raw secrets. Our guide to evidence for agent work develops these checks.
If a skill is suspected of compromise, disable new invocations and contain the affected sessions. Preserve its files, digest and relevant logs. Revoke or rotate exposed credentials, inspect configuration and persistent memory changes, and check other deployments of the same artifact. Removing the skill directory alone may leave active tokens, scheduled jobs or altered instructions behind.
Restart only from reviewed artifacts and a known configuration. Verify the normal task and the failed boundary again, and keep unreachable devices visible until their state is established.
What a startup or security team can do first
Start with one consequential workflow rather than attempting to approve an entire marketplace. A release assistant, customer-support agent or finance automation provides a concrete task, an owner and a set of systems to protect.
- Find its installed skills and effective access. Record local and hosted copies, incomplete observations, credentials, tools and external sources. Remove permissions the task does not need.
- Review and pin the version in use. Inspect instructions and dependencies, record scan coverage, and test allowed and denied operations under a restricted account.
- Make changes observable. Track artifact, permission and runtime changes; recheck advisories; assign alerts to someone who can act. A stale check remains stale after a risk is accepted.
- Practice stopping and recovering the workflow. Confirm revocation, credential rotation, evidence retrieval and restart from a reviewed version.
Measure the work against known deployments: which have an owner, an observed digest, current inspection coverage and a tested revocation path. Report missing observations alongside the totals. “Ninety percent approved” is not useful if the team cannot explain what the denominator excludes.
Oktsec’s Signal inspects skills and dependencies. Continuous monitoring around discovered inventory is under development. When evaluating a deployment, ask which resources are observed, when they were last checked and what happens when collection fails. For workflow testing, Assessment is the place to scope tests of the workflow and its boundaries. Control addresses policy decisions for actions routed through configured enforcement points. These roles complement artifact inspection; they do not make an unexamined skill trustworthy.
The continuing operational question is whether the reviewed conditions still hold. That connects this work to cyber hygiene for AI agents: keep the inventory current, maintain access restrictions, investigate changes and verify corrections before expanding what the agent can do.
Sources and scope
This analysis uses the OWASP Agentic Skills Top 10 whitepaper and primary documentation reviewed on September 20, 2026. The ten category names come from OWASP. The release example, diagrams, approval flow and acceptance tests are original Oktsec explanations. No customer deployment, scanner benchmark or complete Aguara coverage assessment is claimed here.
- OWASP Agentic Skills Top 10 — whitepaper: the ten risks, controls, scanner coverage and proposed security manifest.
- OWASP Agentic Skills Top 10 — project: project status and public review. The category definitions in this article follow the whitepaper.
- Agent Skills specification: package structure, progressive loading and the experimental allowed-tools field.
- Trail of Bits — The sorry state of skill distribution: the scanner experiments described in the scanning section.