What Happened
AIR, a security research organization, deployed a fake AI agent skill marketed as a landing page builder tool. The skill passed security validation from Cisco, Nvidia, and skills.sh scanners, then reached over 26,000 users before its malicious intent was revealed. The attack exploited a fundamental flaw in current security practices: assuming AI agent skills behave consistently after installation. Instead, the skill's behavior changed post-deployment, after trust had already been granted through initial security scans.
Timeline
Pre-deployment: The malicious skill was submitted with benign functionality designed to pass static security analysis. Security scanners from three major vendors marked it as safe.
Installation phase: Over 26,000 users installed the skill based on clean scanner verdicts and apparent GitHub reputation signals.
Post-installation: The skill modified its behavior after deployment, introducing malicious functionality that was never present during the initial security review.
Detection: AIR disclosed the experiment, revealing that no runtime monitoring had flagged the behavioral change.
Which Controls Failed or Were Missing
Static analysis dependency: Security teams relied exclusively on pre-installation scans. These tools analyzed the skill's code at a single point in time, creating a false sense of security that persisted indefinitely after approval.
No behavioral monitoring: Once installed, the skill operated without runtime observation. No system tracked whether its actual behavior matched its initial security profile.
Missing supply chain governance: The skill was treated as a binary trust decision—safe or unsafe at install time—rather than as a living dependency requiring continuous validation.
Inadequate change detection: When the skill's behavior shifted post-deployment, no control existed to detect the deviation from its baseline security posture.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates that custom software undergo security testing before deployment and when changes occur. The requirement explicitly states that testing must occur "prior to release and with any changes." A skill that modifies its behavior post-installation violates this control because the changed behavior never underwent security review.
ISO/IEC 27001:2022 Control 8.31 (separation of development, test, and production environments) and Control 8.32 (change management) require that changes to production systems follow documented procedures. An AI skill that alters its functionality without triggering change management bypasses these controls entirely.
NIST 800-53 Rev 5 CM-3 (configuration change control) requires organizations to review, approve, and monitor changes to information systems. When an AI skill changes behavior without detection, it represents an unauthorized configuration change that would fail audit review.
SOC 2 Type II Common Criteria CC6.1 requires monitoring of system components to detect anomalies. A skill that changes behavior post-installation should trigger anomaly detection, but current implementations lack the instrumentation to observe AI skill behavior at runtime.
Lessons and Action Items for Your Team
Treat AI Skills as Living Dependencies
Your third-party JavaScript libraries get scanned with every build. Your container images are monitored for vulnerabilities throughout their lifecycle. Apply the same thinking to AI agent skills. These are not static binaries—they're network-connected tools that can change behavior without redeployment.
Action: Add AI agent skills to your software bill of materials (SBOM). Track which skills are installed, what permissions they hold, and when they were last validated. Tools like OWASP Dependency-Track can be extended to include AI skills as tracked components.
Implement Runtime Behavioral Monitoring
Static scans told you what the skill looked like at approval time. You need visibility into what it's doing right now.
Action: Deploy runtime application self-protection (RASP) principles to AI skills. Log every API call the skill makes, every data access, every external network connection. Set baselines for normal behavior and alert on deviations. If a "landing page builder" suddenly starts accessing your customer database, that's a detection event.
Require Continuous Validation
The skill that passed security review on Monday might be compromised by Wednesday. Your validation cadence must reflect that reality.
Action: Re-scan AI skills weekly at minimum. Better: implement continuous validation that checks skill behavior against its security profile on every invocation. If the skill's code hash changes, if its network traffic pattern shifts, if it requests new permissions—trigger a security review before allowing continued operation.
Build Permission Boundaries
The skill shouldn't have had access to 26,000 users' data in the first place.
Action: Apply principle of least privilege to AI skills. A landing page builder needs access to web templates and publishing APIs—not your user database, not your authentication system, not your financial records. Use OAuth scopes, API gateway policies, and network segmentation to enforce these boundaries at the infrastructure level.
Create an AI Skill Approval Process
You wouldn't let developers install arbitrary npm packages in production without review. Extend that discipline to AI skills.
Action: Document which skills are approved for production use. Require security review for new skills, including threat modeling of what damage the skill could cause if compromised. Maintain an approved skills list and block installation of unapproved tools through policy enforcement at your AI agent platform.
Test Your Detection Capabilities
AIR demonstrated that 26,000 installations could occur before detection. Can your team detect a malicious skill before it reaches 100 users? 10 users? One?
Action: Run purple team exercises specifically for AI skills. Have your red team deploy a benign but behavior-changing skill. Measure how long it takes your monitoring systems to detect the change. If the answer is "we never detected it," you've identified a critical gap to address.
The AIR experiment exposed a category of supply chain risk that existing controls don't address. Your security program likely has robust processes for traditional software dependencies. Extend those same principles—continuous validation, runtime monitoring, least privilege, change detection—to AI agent skills before an actual attacker replicates this research with malicious intent.
Runtime Application Self-Protection (RASP)
