Bei der von AIR erstellten Skill handelte es sich um ein Paket mit dem Namen „brand-landingpage“. Es gab vor, mit Googles Designtool Stitch eine Landingpage zu erstellen, und richtete sich gezielt an nichttechnische Nutzer. Um Glaubwürdigkeit aufzubauen, setzte AIR laut Quelltext auf zwei bekannte Vertrauenssignale: GitHub-Sterne und ein sauberes Prüfergebnis durch Sicherheits-Scanner.
Für die GitHub-Komponente reichte AIR einen Pull Request in ein Skill-Marktplatz-Repository mit rund 36.000 Sternen und 156 Skills ein. Der Pull Request wurde nach einigen Tagen übernommen, wodurch die Skill von der Sichtbarkeit und dem Sterne-Zähler des Repositorys profitierte. Anschließend schaltete AIR eine Instagram-Anzeige für Marketing-, Vertriebs- und Design-Zielgruppen, die die Skill installierten und einsetzten.
Die von AIR getesteten Scanner prüften nach Darstellung des Unternehmens nur das eingereichte Paket selbst, also die Datei SKILL.md und die mitgelieferten Dateien. Genannt werden dabei Scanner von Cisco, NVIDIA sowie die in skills.sh integrierten Prüfungen. Die Skill selbst enthielt keine eigenen Einrichtungsanweisungen. Stattdessen forderte sie den Agenten auf, das „Stitch SDK“ anhand einer extern verlinkten Dokumentation unter stitch-design.ai zu installieren — einer von AIR kontrollierten Domain und nicht Google; die echte Stitch-Seite liegt laut Quelltext unter stitch.withgoogle.com.
Zunächst zeigte dieser Link auf die echten Stitch-Dokumente. Da das Paket selbst unauffällig war und auf eine plausibel wirkende Einrichtungsseite verwies, gaben die Scanner grünes Licht. Der entscheidende Punkt: Die Seite, die der Agent später tatsächlich abrufen und befolgen sollte, lag außerhalb des geprüften Pakets.
Erst nachdem die Skill breit installiert war, tauschte AIR den Inhalt hinter dem Link aus. Die neue Version wies den Agenten an, ein Skript herunterzuladen und auszuführen. In der Demonstration schickte dieses Skript lediglich die E-Mail-Adresse des Nutzers an AIR zurück. So ermittelte das Unternehmen nach eigenen Angaben die Zahl der erreichten Agenten.
AIR ist mit dieser Methode nicht allein. Drei Wochen zuvor hatte Trail of Bits laut Quelltext bereits den Malicious-Skill-Detektor von ClawHub, Ciscos Scanner und alle drei in skills.sh eingebundenen Scanner umgangen. Das Fazit dort: Ein Scanner prüft ein festes Paket, während ein Angreifer die Nutzlast so lange verändern kann, bis sie die Prüfung besteht.
Der Quelltext verweist außerdem darauf, dass reale Kampagnen diesen Ansatz seit Monaten nutzen: Das eingereichte Skill-Paket bleibt sauber, während die eigentliche Nutzlast auf einer externen Seite liegt, die der Agent erst bei der Installation abruft. Auch die Dokumentation von Anthropic warnt demnach bereits vor Skills, die externe URLs nachladen, weil sich deren Inhalte nach der Freigabe jederzeit ändern können. Weitere Untersuchungen in diesem Jahr kamen laut Quelltext zudem zu dem Ergebnis, dass Scanner oft zu unterschiedlichen Urteilen gelangen, weil sie Skills isoliert betrachten und weder externe Links noch spätere Änderungen einbeziehen.
Eins schränkt der Quelltext ausdrücklich ein: Die Angaben zur Größenordnung stammen allein von AIR und seien mit Skepsis zu betrachten. Das Unternehmen starte selbst einen verwalteten Skill-Marktplatz und bewerbe diesen am Ende seines Berichts. Die Zahl von 26.000, der Hinweis auf Unternehmenskonten und die Behauptung, man hätte die vollständige Kontrolle über jeden betroffenen Agenten übernehmen können, sind demnach nicht unabhängig bestätigt. Als belastbar beschreibt der Quelltext jedoch die Methode selbst: Die genannten Scanner prüfen nur das eingereichte Paket, der blinde Fleck bei externen Links ist real und unabhängig belegt, und genau diese Vertrauenssignale behandelt das Ökosystem weiterhin als Nachweis von Sicherheit.
