AI Agent Skills Are the New Supply Chain Vendor Risk

Unit42’s analysis of the OpenClaw agent-skill registry gives supply chain teams an uncomfortable starting point: 49,943 skills examined, 80.0% showing at least one mismatch between declared and actual behavior, 18.9% of behavioral deviations attributed to adversarial intent, and 5% carrying multi-stage attack chains. Two patterns accounted for 88% of those multi-stage chains: silent credential exfiltration and instruction-override hijacking.[1]

Those numbers are not a market-wide census of every agent-skill ecosystem. They come from OpenClaw. But they are still hard to wave away, because the underlying issue is not peculiar to one registry: agent skills are modular dependencies that can act. They are selected like add-ons, installed like components, and then allowed to read files, call tools, touch databases, use credentials, or run commands inside workflows that procurement, logistics, planning, and warehouse teams increasingly want to automate.

That is why agent-skill security belongs inside supply chain vendor risk, not off to the side under general AI policy. A skill may not appear as a named supplier in the vendor master. It may arrive through a platform marketplace, a registry, a systems integrator, a proof-of-concept team, or a bundled implementation. Yet once it can operate other software with privileges, it has become part of the dependency chain.

The Vendor Is Not Always the Company on the Contract

Traditional third-party risk management was built around identifiable counterparties. A supplier has a legal name, a contract, an onboarding workflow, insurance language, a security questionnaire, and renewal dates. Even when the model is imperfect, there is at least a place to attach responsibility.

Agent skills do not always enter that cleanly. A business team may approve an agent platform, then later add a skill that reconciles purchase orders, pulls carrier updates, prepares supplier emails, queries inventory, or posts status changes into an execution system. The named vendor may be the platform provider. The practical dependency may be the skill author, the registry, a transitive package, a connector, or the implementation partner that assembled the workflow.

This is familiar territory for supply chain risk managers in one sense. “Vendor” has never meant only the logo on the contract. It can mean a subcontract manufacturer, a broker, a data feed, an API connector, a customs filing service, or a transportation management plug-in. Agent skills extend that pattern into a more active layer: the dependency is not merely providing software; it may be operating the workflow.

That distinction matters because many existing controls still evaluate the declared artifact. They ask what the vendor says the tool does, what data categories it claims to process, and what controls the provider says are in place. Unit42’s finding is aimed directly at that weak point: in OpenClaw, the declared behavior and observed behavior diverged in most skills they examined.[1]

Why Standard TPRM Misses Agent Skills

Most vendor-risk processes can find a SaaS provider. They are less reliable at finding a capability embedded inside a larger automation stack. That creates several practical gaps before anyone reaches the deeper security question.

• The skill may not be onboarded as a vendor, so it avoids supplier intake, legal review, and security scoring.
• The platform may be approved, while later skill selection happens inside an administrator console or operational team workflow.
• The skill may be bundled by an implementation partner, making the dependency look like configuration rather than software supply.
• The review may rely on manifest descriptions, permission labels, or documentation rather than observed runtime behavior.
• Updates may change behavior after approval, while the original risk record remains untouched.

There is a useful analogy to mobile apps and browser extensions. TechRadar, drawing on JFrog’s enterprise governance framing, describes agent skills as following a pattern seen in those ecosystems: extensibility moves faster than audit primitives.[2] Organizations first adopt the convenience layer, then later discover that permissioning, provenance, review, and revocation were not designed with enterprise control in mind.

Open-source packages are another useful comparison, but only up to a point. A package can introduce vulnerable code into an application. A browser extension can read or modify activity inside a browser. An agent skill can be closer to an operator. If it has the right tool access, it can retrieve a credential, query a database, rewrite an instruction, run a shell command, or chain several actions together without waiting for a person to approve each step.

Declared Behavior Is Not Enough

The most important contribution of the Unit42 work is not only the count of mismatches. It is the Behavioral Integrity Verification approach: compare what a skill declares against what it actually does, then identify compound threat patterns when multiple behaviors line up into an attack chain.[1]

That is a more useful standard for procurement than asking whether the skill has a clean description. Declarations are still necessary. They tell reviewers what the skill claims, what permissions it requests, what systems it intends to touch, and what value it is supposed to deliver. But they are not proof of behavior. A questionnaire can be complete while the runtime behavior is still wrong.

For a supply chain workflow, the gap can become operational very quickly. A skill that “summarizes supplier performance” may need access to purchase orders, shipment events, warehouse receipts, quality incidents, and supplier communications. A skill that “updates order status” may need write access to an ERP, transportation management system, or control-tower dashboard. The permission set is not incidental; it is the working surface.

This is where agent skills depart from the way many risk teams still classify tools. A passive reporting component that renders a dashboard is one kind of dependency. A skill that can inspect data, decide which tool to call next, and execute an action under delegated authority is another.

The Attack Chains Make the Risk Concrete

Generic AI security language tends to blur the problem. The OpenClaw findings are more useful because the dominant attack-chain patterns are concrete. Silent credential exfiltration and instruction-override hijacking accounted for most of the multi-stage chains Unit42 identified.[1]

Silent credential exfiltration is easy to map to enterprise damage. A skill with access to environment variables, local files, configuration stores, API keys, or session tokens may be able to collect secrets that were never meant to leave the workflow. The immediate victim is not an abstract model. It is the credential that allows access to operational systems.

Instruction-override hijacking is different but equally relevant to supply chain operations. A skill that can alter or supersede instructions can redirect what the agent does next. In a low-risk workflow, that may produce bad output. In an operational workflow, it can change which system is queried, which file is trusted, which command is executed, or which downstream action is triggered.

The concern is not that every agent skill is malicious. The concern is that the review model often treats a skill as if it were a neat capability card, while the runtime model gives it room to behave like an actor in a system.

What Governance Has to Attach To

Supply chain organizations do not adopt skills because they are careless. They adopt them because operations teams are always short on clean handoffs. Planners wait on exception summaries. Buyers wait on supplier responses. Logistics teams wait on status updates. Warehouse teams wait on reconciliations. If a skill can remove three screens and two copy-paste steps from a daily process, people will try it.

A workable governance model has to respect that pressure. It also has to move the control point closer to where the skill is selected, installed, updated, and allowed to act. Reviewing only the agent platform is too broad. Reviewing only the business process is too late. Reviewing only the vendor questionnaire is too dependent on self-description.

Pre-selection: Treat the Skill as a Dependency

Before a team selects a skill, procurement and security need a minimum dependency record. The record should identify the source registry or marketplace, publisher, version, maintainer, update mechanism, required permissions, expected systems touched, and whether the skill was built internally, obtained from a public registry, supplied by a platform vendor, or assembled by an implementation partner.

The key question is scope. A skill that drafts a summary from non-sensitive documents does not deserve the same review as a skill that can read credentials, call production APIs, execute shell commands, or write back to a planning or execution system. The intake process should separate low-context assistance from operational authority.

Contracting: Make Behavior Testable

Contract language for agent-enabled workflows should not stop at generic AI assurances. The useful obligations are concrete: disclose source scope, document permissions, preserve provenance, notify customers of material behavior changes, support revocation, and allow behavioral testing or independent validation where risk justifies it.

If a platform vendor hosts third-party skills, the contract should clarify who validates them and what happens when a skill is removed, updated, or found to behave outside its declaration. If an integrator assembles the workflow, the statement of work should identify the skills and connectors it introduces rather than burying them under “configuration.”

Deployment: Consume Skills With Zero Trust

Zero-trust consumption means the skill receives only the access required for the approved task, and that access is bounded by environment, data category, action type, and time. A skill that reads supplier records should not automatically inherit write access. A skill that prepares a logistics update should not receive shell access. A skill used in testing should not carry production credentials into a sandbox.

The control design should assume the skill can be wrong, compromised, over-permissioned, or misdescribed. That means separate credentials, scoped tokens, tool allowlists, blocked command classes, network egress controls, logging, and approval gates for high-impact actions. Human review still matters, but it should not be the only barrier between an agent skill and an operational system.

Monitoring: Watch for Behavior Drift

Skills change. Registries change. Platform defaults change. A risk review performed at installation does not cover every future version. Monitoring should compare declared behavior, granted permissions, observed calls, data access, network destinations, and action chains over time.

This is where Behavioral Integrity Verification becomes more than a research method. In enterprise terms, it points toward a control objective: verify that the skill’s observed behavior remains consistent with its approved purpose. When the behavior changes, the approval should not remain silently valid.

Public Registries Are Not the Only Exposure

The OpenClaw boundary matters. Unit42’s percentages should not be casually applied to every private marketplace, enterprise platform, or internally developed skill catalog. A curated internal registry may have different controls. A bespoke skill written for one workflow has a different provenance profile from a public skill downloaded at scale.

Different does not mean safe by default. Private skills can still be over-permissioned. Integrator-built skills can still contain undocumented dependencies. Internal teams can still misstate what a capability does because they tested the happy path, not the full behavior surface. The exact OpenClaw rates may not generalize everywhere, but the audit gap does: extensible agent capabilities are being consumed faster than many organizations can verify them.

Bring Agent Skills Into Vendor Risk Scope

Supply chain organizations do not need to ban agent skills to take this risk seriously. They need to stop treating them as invisible implementation details.

The practical standard is straightforward: if a skill can read credentials, touch operational systems, override instructions, or chain actions together, it belongs inside vendor risk scope even when it is not a conventional vendor. That does not make every skill high risk. It does make every privileged skill accountable to the same discipline supply chain teams already apply to critical dependencies: know where it came from, test what it does, constrain what it can do, and keep watching after it changes.

References

1. Trust No Skill: Integrity Verification for AI Agent Supply Chains, Unit42 / Palo Alto Networks, https://unit42.paloaltonetworks.com/ai-agent-supply-chain-risks/
2. AI agent skills are becoming the next enterprise supply chain risk — here's how to govern them, TechRadar, https://www.techradar.com/pro/ai-agent-skills-are-becoming-the-next-enterprise-supply-chain-risk-heres-how-to-govern-them