The Security Risks of Unverified AI Agent Skills

An agent skill is executable supply-chain input. Treating it as a prompt file, a marketplace listing, or a five-star review is a category error. The moment an agent can acquire a skill and act through it, that package can affect credentials, data, money, infrastructure, and every downstream agent that trusts its output.

This article is a threat model for teams consuming third-party skills. It separates five claims that are often collapsed into the word “verified”: identity, integrity, provenance, policy compliance, and safe behavior. They require different controls. None is a substitute for least privilege and isolated execution.

Reviewed July 28, 2026. The implementation examples below were checked against the open-source SkillLedger repository. The product is an experimental MVP, not a security certification service.

Why agent skills are a distinct supply-chain risk

Traditional package managers resolve code before an application runs. Agent systems can discover and compose capabilities at runtime, based on natural-language intent and incomplete context. That adds three failure multipliers:

• Dynamic selection: the model may choose a tool the application developer never reviewed.
• Delegated authority: the skill may inherit filesystem, network, mailbox, or payment access from the calling agent.
• Semantic trust: a syntactically valid result can still be deceptive, poisoned, or wrong enough to trigger damaging follow-up actions.

The OWASP Agentic Security Initiative treats tool misuse, cascading failures, and agent supply-chain attacks as connected risks. That connection matters: a compromised skill is rarely the final failure. It is the first untrusted step in a chain of trusted automation.

The five claims hidden inside “verified”

Claim	Useful evidence	What it does not prove
Identity	Publisher account, signing identity, ownership history	That the publisher is competent or benign
Integrity	Digest, signature, immutable artifact reference	That the signed bytes are safe
Provenance	Source revision, builder identity, build inputs	That the source has no vulnerability
Policy compliance	Declared permissions, path and secret checks, human approval	Behavior outside the checks performed
Safe behavior	Sandbox tests, runtime controls, monitoring, signed execution records	Safety under every input and environment

This is the core design rule: store each claim separately and preserve the evidence behind it. A single green badge destroys information. A buyer needs to know whether a package merely has a matching checksum or whether it was also signed, reviewed, tested in isolation, and observed in production.

A practical threat model

1. Publisher impersonation

An attacker publishes a look-alike skill or takes over a legitimate author account. A display name does not establish identity. Require scoped credentials, protect publisher accounts, and bind every released version to a stable publisher identity. For higher-risk packages, add independent maintainers or multi-party approval.

2. Artifact substitution

The reviewed manifest and the downloaded bytes are not the same artifact. A digest detects accidental or malicious modification only when the consumer recomputes it over the exact acquired payload. A signature adds publisher identity to integrity, while a transparency record makes later substitution harder to hide. Sigstore’s verification documentation shows this separation clearly: signature verification, identity checks, and artifact digest checks are distinct operations.

3. Misleading manifests

A manifest can declare narrow permissions while the code attempts broad access. Schema validation is still valuable—it makes entrypoints, inputs, outputs, runtime, and requested permissions inspectable—but declarations are claims, not enforcement. The runtime must deny undeclared access.

4. Malicious or vulnerable code

A package can be authentic, unmodified, and dangerous. Static analysis, dependency scanning, review, and sandboxed execution address different parts of this risk. The NIST Secure Software Development Framework is a useful baseline because it treats provenance, secure production, and vulnerability response as lifecycle practices rather than a one-time marketplace check.

5. Post-approval drift

A new version, mutable dependency, remote endpoint, or changed model can alter behavior after approval. Pin versions and dependencies, make approvals version-specific, and require re-verification after any artifact change. SLSA’s build track is a helpful model: provenance exists at the first level, while higher levels add stronger protection against tampering during and after the build.

6. Excess authority at execution time

Even a well-reviewed skill becomes dangerous when it inherits unrestricted credentials. Run acquired skills with a minimal capability set, explicit network destinations, resource budgets, timeouts, and a kill switch. High-impact actions should require an independent approval boundary—not another prompt to the same model.

7. Untraceable downstream effects

When an action fails, you need to reconstruct which skill version ran, who approved it, what inputs it received, which permissions were granted, and what it changed. That is the role of execution attestation: it complements package verification with evidence about a specific run.

What SkillLedger 0.1.0 actually verifies

The current SkillLedger code is deliberately narrower than the original “trust-minimized marketplace” idea. Its automated artifact verifier checks eight conditions: artifact presence, supported type, manifest shape, required fields, client-side runtime, bundled-file metadata, version consistency, and a SHA-256 checksum over canonicalized manifest JSON.

A separate policy service checks artifact size, file paths, declared permissions, obvious secret patterns, and basic name/description quality. Path traversal, absolute paths, and obvious secrets are hard failures. Other findings remain available for a human administrator. Verification and marketplace approval are separate records, and approval transitions are appended to an event log.

Those are useful controls, but the repository’s own security model states the boundary precisely: the checks do not prove that code is safe, behaves as described, contains no malicious payload, or runs in an isolated environment. The ledger is database-backed, not a blockchain; its event history relies on the trusted application and database.

For the complete product flow, implementation status, and limitations, read the SkillLedger 0.1.0 architecture article. This page owns the threat model; that page owns the implementation.

A minimum acquisition gate

Before an agent can acquire or enable a third-party skill, I would require this evidence envelope:

{
  "artifact": {
    "digest": "sha256:…",
    "version": "1.4.2",
    "publisher": "did-or-account-id"
  },
  "provenance": {
    "source_revision": "git-sha",
    "builder": "ci-workflow-identity"
  },
  "policy": {
    "requested_permissions": ["network:api.example.com"],
    "review_id": "review-…",
    "decision": "approved"
  },
  "runtime": {
    "sandbox_profile": "network-restricted-v2",
    "credential_scope": "read-only",
    "expires_at": "2026-07-28T18:00:00Z"
  }
}

The gate should fail closed if a required field is missing, the digest changes, approval applies to another version, or the requested runtime authority exceeds the approved policy. Discovery should also expose these attributes so an agent can rank compatible, lower-risk capabilities before selection; that is the missing layer described in the agent capability discovery article.

The boundary that matters

A marketplace can improve identity, integrity, provenance, and review accountability. It cannot make arbitrary third-party code safe. The security boundary must remain at execution: least privilege, isolation, explicit approval for consequential actions, observation, and revocation.

If your architecture treats “verified” as a binary property, replace the badge with evidence. Then make every consuming agent prove that the evidence satisfies its own risk policy before it runs the skill.