[Robotics](https://rankshieldrobotics.com/) / [Blog](https://rankshieldrobotics.com/blog/) Blog / Threat analysis # When a Robot Downloads a Skill, What Checks It Before the Arm Moves? Researchers scanned 49,943 skills in a public agent registry in early 2026 and found that 80.0 percent of them, 39,933 skills, showed at least one mismatch between what they declared and what they actually did [1](#ref-1). For a chatbot that is a data problem. For a robot it is a motion problem, because the same instruction stream that summarizes a document also tells an actuator where to go. Every control the industry currently recommends fires before installation. The arm moves later. By RankShield Robotics, Robot Security Research | Published August 25, 2026 ## Key takeaways - A scan of 49,943 registry skills surfaced 250,706 behavioral deviations , with 80.0 percent of skills declaring one thing and doing another [1](#ref-1) . - Most of it is not malice. 81.1 percent of deviations traced to developer oversight and only 18.9 percent to adversarial intent [1](#ref-1) , so there is often no bad pattern for a scanner to find. - The ecosystem is growing faster than review can follow: unique skills scanned rose from 60,000 to nearly 900,000 between March and May 2026 [3](#ref-3) . - Skills are not cryptographically signed by default and anyone with a repository account can publish one [2](#ref-2) . - Signing, provenance, and static analysis are all install-time controls [2](#ref-2) [4](#ref-4) . In an embodied system the last line has to sit between the instruction and the actuator. ## What is an AI skill, and why would a robot load one? A skill is a packaged capability an agent loads to learn how to do something: a bundle of executable code, a manifest declaring what it needs, and natural-language instructions the model reads at runtime [1](#ref-1)[2](#ref-2). Security researchers describe the core artifact as a markdown file that "stores the instructions the agent reads at runtime" [2](#ref-2). The agent reads it, and behaves accordingly. Robots load them for the same reason software agents do, which is that no vendor can pre-build every task. A warehouse robot needs to know how to handle a new tote type. An inspection robot needs a procedure for a new asset class. A humanoid needs a manipulation routine for a part it has never gripped. Packaging those as reusable modules is genuinely good engineering, and it is why the ecosystem exploded. The distribution model is the part that should give a robotics team pause. As Unit 42 puts it, "anyone can publish a skill to a public registry. Anyone can install one into a production agent" [1](#ref-1). Skills "aren't cryptographically signed and are rarely properly vetted or reviewed" [2](#ref-2). That is the same trust model as an early package registry, now wired to something with motors. ## How large is the skill supply chain now? Large, and growing at a rate that makes any manual answer obsolete. ESET reported analyzing nearly 900,000 AI skills for its H1 2026 threat report, identifying "more than 25,000 suspicious skills and over 3,000 malicious ones" [3](#ref-3). The growth curve matters more than the totals: unique skills scanned went from 60,000 in March 2026 to almost 900,000 by May, roughly a fifteen-fold expansion in three months [3](#ref-3). Individual registries are correspondingly deep. One official agent registry held "over 70k skills as of June 2026" [2](#ref-2), and the framework behind it drew over 370,000 repository stars within six months of its late-2025 release [2](#ref-2). Suspicious skills roughly doubled from about 10,000 to more than 25,000 over the same window, and malicious ones went from roughly 600 to over 3,000 [3](#ref-3). None of that is a robotics statistic yet. It is the substrate robotics is building on, and it is arriving faster than any procurement process was designed to evaluate. ## What did researchers actually find inside the registries? The most useful measurement is not the malware count, it is the gap between what skills claim and what they do. Unit 42 scanned 49,943 skills in a public registry in early 2026 and surfaced 250,706 behavioral deviations, with "80.0% of skills (39,933) showing at least one mismatch between declaration and behavior" [1](#ref-1). Category | Share of scanned skills | What it means | Benign, with documentation gaps | 72.5% [1](#ref-1) | The skill does more or less than it says, without adversarial intent | Single-stage adversarial deviation | 16.8% [1](#ref-1) | One deviating behavior consistent with adversarial intent | Multi-stage attack chain | 5.0%, 2,490 skills [1](#ref-1) | Flagged for mandatory review before any use | The reason no scanner catches this cleanly is structural. A skill presents three faces: metadata declarations, executable code, and natural-language instructions. Unit 42 notes that "no existing scanner reads all three, and the registry has no automated way to verify that the two sides match" [1](#ref-1). Where malice is present, two patterns dominate: silent credential exfiltration and instruction-override hijacking together account for 88 percent of multi-stage chains [1](#ref-1). ## Is this an attacker problem or a drift problem? Overwhelmingly a drift problem, and that changes which defense works. Of the deviations Unit 42 traced, "81.1% were traced to developer oversight" and only 18.9 percent to adversarial intent [1](#ref-1). Four out of five times, nobody is attacking you. A skill was written to do slightly more than its manifest describes, the documentation was never updated, and the mismatch shipped. This is the finding that should reorder a robotics team's priorities. A malware scanner asks whether a known bad pattern is present. Against an honest skill that quietly exceeds its declaration, there is no bad pattern to match, because nothing about it is bad in the signature sense. It is simply not doing what its paperwork says, and paperwork is what your review process reads. It also means the problem does not go away when you buy from reputable publishers. Reputable publishers employ developers, and developer oversight is the dominant cause. The exposure scales with how many third-party capabilities you load, not with how sketchy their sources look. ## What does a deviating skill do differently inside a robot? It converts an information failure into a physical one. The capability list researchers observed in malicious skills is the familiar software set: "command execution, file access, downloading third-party tools, credential loading, code injection, and obfuscation" [3](#ref-3). In a software agent those end in stolen data or unauthorized access. In an embodied system the same instruction stream terminates at an actuator, and security research on embodied AI is explicit that the risk profile changes precisely because software can now influence physical action [5](#ref-5). Consider the benign 72.5 percent rather than the malicious tail, because that is where the volume is. A manipulation skill declares that it grips and lifts. In practice it also nudges the base a few centimeters to improve reach. Nobody wrote that down. In a lab it is a harmless convenience. On a line, next to a person, in a cell whose safety case was built on the robot's declared envelope, it is an undocumented motion nobody assessed. That is the asymmetry worth naming plainly. The same 80 percent mismatch rate that produces a slightly wrong summary in a chatbot produces a slightly wrong movement in a machine that weighs more than you do. Our [embodied AI threat landscape](https://rankshieldrobotics.com/threats/embodied-ai-robot-security-threats/) covers the adjacent injection routes, where the instruction is corrupted rather than merely inaccurate. ## Why is signing the skill not enough for an embodied system? Because a signature proves authorship, not behavior. The recommended controls are good and you should adopt them: treat skill integrity "the same way the software industry treats package integrity: through cryptographic signing and verified provenance," move registries toward app-store-style review before publication, and constrain skills with sandboxed runtimes rather than granting them the agent's own permissions [2](#ref-2). Formal work goes further, adapting the SLSA graduation model to agent skills, "mapping L1 (basic provenance) through L4 (formal verification) to concrete, measurable criteria" [4](#ref-4). Note where all of it sits on the timeline. The SkillFortify analysis is explicit that its guarantee is proof before installation, contrasting itself with "reactive post-execution detection," and its soundness theorem holds that if no violations are found, execution cannot exceed declared capabilities [4](#ref-4). That is a real and valuable property. It is also a statement about the artifact you installed. Three things then happen in a real fleet. Skills update, and the same work models trust as decaying over time for unmaintained skills [4](#ref-4), so the artifact you verified is not indefinitely the artifact running. Static analysis answers "can this skill access resources beyond what it declares" [4](#ref-4), which does not answer whether the motion it legitimately declared is one this robot should perform right now. And a skill that correctly declares motion capability is precisely the dangerous case, because it passes. So install-time verification is necessary and it is not the last line. For a system that can hurt someone, the last line has to be closer to the actuator than the package manager. Signing, provenance, and static capability analysis all fire at install. The actuation risk arrives later, in a span nothing re-checks. ## What would it cost to review your way out of this? More time than you have, and the arithmetic is worth doing explicitly rather than hand-waving. Take the registry reported at over 70,000 skills in June 2026 [2](#ref-2). Assume a competent reviewer needs 30 minutes per skill to read the manifest, the code, and the instructions and judge whether they agree, which is generous given that researchers needed automated behavioral comparison across 29 capabilities in seven families to do it properly [1](#ref-1). Approach | Effort at 30 minutes per skill | What it buys | Review one registry once | ~35,000 hours, about 17 person-years | A snapshot that is stale on publication day | Review the 40 skills a single stack loads | ~20 hours per version cycle | Real coverage, repeated on every skill update | Automated install-time verification | Tooling, not headcount [4](#ref-4) | Proof at install, bounded by artifact drift | Deny-by-default check at the actuator | A control-layer project | Applies to every action regardless of skill origin | Those first two rows are our own arithmetic from the cited skill counts and a stated review-rate assumption, not a measured figure, and the point survives any reasonable change to the assumption. Halve the review time and one registry is still roughly nine person-years. Meanwhile the population grew fifteen-fold in three months [3](#ref-3). Manual review is a useful practice and it is not a control that scales with this curve. ## What should sit between a skill and an actuator? A check that evaluates the action rather than the artifact's paperwork. Unit 42's own operational advice is to "inventory the third-party skills installed and implement a behavioral-integrity check before installation rather than after" [1](#ref-1), and that inventory is the right first move. For an embodied system, add a second check that fires on every action, not once per install. A [pre-actuation authorization gate](https://rankshieldrobotics.com/solutions/pre-actuation-authorization-gate/) asks a different question from any scanner: is this specific action, on this specific robot, permitted by policy right now? A skill that has drifted beyond its declaration is refused at that boundary whether the drift came from developer oversight or adversarial intent, and whether or not anyone had classified it. High-consequence actions are deny by default and must be explicitly allow-listed, so a capability nobody documented is a capability nobody approved. Two supporting pieces make it hold up. [Attestation](https://rankshieldrobotics.com/solutions/firmware-attestation-rats/) establishes what is actually loaded and running, which is the thing skill drift makes uncertain. [Tamper-evident action provenance](https://rankshieldrobotics.com/solutions/robot-action-provenance/) records which attested configuration was authorized to do what, so when a skill turns out to have been deviating for six weeks, you can determine what it actually did rather than reasoning from its manifest. The honest boundary: none of this vets your skills, replaces install-time verification, or makes a robot unhackable. A deviating skill behind a gate is still a deviating skill, and you should still fix it. What the gate changes is that its deviation cannot become an unreviewed movement. ## What should a robotics team do this week? Start with an inventory, because most teams cannot currently answer the question. List every third-party skill, policy, plugin, and model your robot stack loads, including anything pulled at runtime rather than baked into a release. Then, for each one, record whether it can originate a command that reaches an actuator or whether a human is still in that path. That single column tends to reorder people's sense of the risk. Next, ask whether install-time verification exists at all: are skills signature-verified, is provenance recorded, and does anything compare declared capability against observed behavior [1](#ref-1)[4](#ref-4). Finally, determine what happens between an accepted instruction and a moving actuator, and whether that check can refuse. The estimator below applies the measured base rates to your own numbers, and everything runs in your browser. Interactive tool ### Robot Skill Exposure Estimator Applies published registry base rates to your own stack. A planning estimate, not an audit of your skills. Nothing you enter leaves your browser. How many third-party skills, policies, or models does your robot stack load? 40 Are skills verified at install (signature, provenance, capability analysis)? No, they are installed as publishedSignature and provenance onlySignature plus static capability analysis Can any loaded skill originate a command that reaches an actuator? Yes, skill output can drive motionNo, skills are advisory only, a human commands motion Is there a deny-by-default check between the instruction and the actuator? No, an accepted instruction actuatesActions are logged after they happenYes, every action is authorized before actuation ESTIMATED EXPOSURE 32 skills likely to deviate from their declaration 2 likely to carry a multi-stage chain Download your skill exposure estimate ## Frequently asked questions about the robot AI skill supply chain **What is an AI agent skill?** A packaged capability an AI agent loads to perform a task, typically combining executable code, a manifest declaring what the skill needs, and natural-language instructions the model reads at runtime [1](#ref-1)[2](#ref-2). Researchers describe the central artifact as a markdown file holding the instructions the agent follows [2](#ref-2). Skills are distributed through public registries and repositories where, as Unit 42 puts it, anyone can publish and anyone can install into a production agent [1](#ref-1). They are not cryptographically signed by default [2](#ref-2). **How common are malicious or deviating AI skills?** Deviation is the norm and outright malice is the minority. A scan of 49,943 registry skills found 250,706 behavioral deviations, with 80.0 percent of skills showing at least one mismatch between declaration and behavior; 5.0 percent carried multi-stage attack chains requiring mandatory review [1](#ref-1). Separately, ESET reported analyzing nearly 900,000 skills and identifying more than 25,000 suspicious and over 3,000 malicious [3](#ref-3). Critically, 81.1 percent of deviations traced to developer oversight rather than adversarial intent [1](#ref-1). **Does signing skills solve the problem for robots?** It solves authorship, not behavior, and it is still worth doing. Researchers recommend treating skill integrity like package integrity through cryptographic signing and verified provenance, plus registry review and sandboxed runtimes [2](#ref-2). Formal work maps SLSA levels L1 through L4 onto agent skills [4](#ref-4). All of these are install-time controls, and their guarantee concerns the artifact you installed. For an embodied system you also need a check at the moment of action, because a skill that correctly declares motion capability passes every install-time test and can still command a movement this robot should not make. **Why is a deviating skill more serious in a robot than in a chatbot?** Because the instruction stream terminates at an actuator. Security research on embodied AI notes the risk profile changes specifically because software can influence physical action [5](#ref-5). The same class of mismatch that yields an inaccurate summary in a chatbot yields an undocumented movement in a machine with mass and momentum. It also breaks assumptions elsewhere: a cell safety case built on a robot’s declared motion envelope is invalidated by motion nobody documented, even when the skill was written in good faith. **Can static analysis catch skills that exceed their declaration?** To a useful degree, at install time. The SkillFortify framework compares inferred capabilities against declared ones and flags a capability violation when a skill uses more than its manifest allows, with a soundness result holding that if no violations are found, execution cannot exceed declared capabilities [4](#ref-4). Two limits matter operationally: it proves a property of the artifact as analyzed, so skills must be re-verified on every version change, and the same work models trust as decaying for unmaintained skills [4](#ref-4). It also cannot judge whether a legitimately declared action is appropriate right now. **How do I inventory what my robots actually load?** Start with the release artifact, then add anything fetched at runtime, which is the part teams usually miss: skills, policies, plugins, model weights, and configuration pulled after deployment. For each entry record the source, whether it is signature-verified, whether provenance was captured, the version currently running, and whether it can originate a command reaching an actuator. Unit 42 recommends inventorying installed third-party skills and running a behavioral-integrity check before installation rather than after [1](#ref-1). Attestation makes the running-version column trustworthy rather than assumed. **What does RankShield Robotics provide here?** We do not vet skills, run a registry, scan marketplaces, or build robots. We provide the layer that sits between an instruction and an actuator: hardware-rooted per-robot identity, a deny-by-default pre-actuation gate that authorizes each action against the robot and a policy before motion occurs, attestation that establishes what is actually loaded, and tamper-evident provenance recording which attested configuration was authorized to do what. These controls are independent of where a skill came from, which is what makes them useful against deviation that no scanner classified as bad. ## References - Unit 42, Palo Alto Networks. Trust No Skill: Integrity Verification for AI Agent Supply Chains . 2026. [unit42.paloaltonetworks.com/ai-agent-supply-chain-risks/](https://unit42.paloaltonetworks.com/ai-agent-supply-chain-risks/) - HiddenLayer. The Next AI Supply Chain Risk: Malicious Skills in Agentic AI . 11 June 2026. [www.hiddenlayer.com/research/the-next-ai-supply-chain-risk-m](https://www.hiddenlayer.com/research/the-next-ai-supply-chain-risk-malicious-skills-in-agentic-ai) - Help Net Security. Thousands of malicious AI skills found capable of stealing data, running malware (reporting the H1 2026 ESET Threat Report) . 8 July 2026. [www.helpnetsecurity.com/2026/07/08/eset-ai-threat-trends-rep](https://www.helpnetsecurity.com/2026/07/08/eset-ai-threat-trends-report/) - Bhardwaj, V. P.. Formal Analysis and Supply Chain Security for Agentic AI Skills (SkillFortify), arXiv:2603.00195 . 27 February 2026. [arxiv.org/html/2603.00195v1](https://arxiv.org/html/2603.00195v1) - Recorded Future. Hacking Embodied AI . 2026. [www.recordedfuture.com/research/hacking-embodied-ai](https://www.recordedfuture.com/research/hacking-embodied-ai) ## Keep exploring [SOLUTIONPre-actuation authorization gate](https://rankshieldrobotics.com/solutions/pre-actuation-authorization-gate/)[SOLUTIONFirmware attestation and RATS](https://rankshieldrobotics.com/solutions/firmware-attestation-rats/)[BLOGOne credential, your entire fleet](https://rankshieldrobotics.com/blog/robot-fleet-one-credential-blast-radius/) ## Check the action, not the paperwork. Deny-by-default pre-actuation authorization, attested configuration, and provenance you can audit. [Request early access](https://rankshieldrobotics.com/request-access/) This article is for general information and does not constitute security or compliance advice. It describes ecosystem measurements and defensive design; it does not provide exploitation detail. Figures are attributed to the cited sources and reflect measurements taken at the dates stated, in an ecosystem changing quickly enough that they should be re-checked before being relied upon. The review-effort figures in this article are our own arithmetic from cited skill counts under a stated assumption, and are labeled as such rather than presented as measurements.