Your AI agent just guided a developer through installing a malicious package. Your static analysis tools found nothing wrong. Your endpoint detection and response (EDR) didn't trigger. Your code review process approved it.
This scenario isn't hypothetical. Snyk researchers documented this attack pattern targeting OpenClaw users through ClawHub, where malicious "skills" (the agent equivalent of plugins) tricked users into compromising their own systems. The attack succeeded because security teams operate under outdated assumptions about how AI agents interact with code, users, and infrastructure.
These myths persist because AI agents are new, and we're applying old mental models. Let's break down what's actually happening—and what you need to change.
Myth 1: "Traditional SAST/DAST Will Catch Malicious Agent Behavior"
Reality: Your application security tools analyze code statically or test running applications. They don't evaluate the conversational logic that determines what an AI agent suggests to a user.
When ClawHub researchers scanned nearly 4,000 skills, they found 13.4% contained critical security issues. But a malicious skill doesn't need vulnerable code. It needs convincing prompts. Consider a skill that responds to "help me set up authentication" by guiding users through installing a backdoored package. The skill's code is clean. The package it recommends isn't.
Traditional tools miss this because they're not designed to evaluate:
- The semantic content of agent responses
- The trust relationship between agent and user
- The external actions an agent might recommend
- The context in which recommendations become dangerous
Your static analysis tool can't flag "this agent will recommend malicious dependencies" because that's not a code vulnerability—it's a behavioral one.
Myth 2: "Code Review Will Catch These Attacks"
Reality: Code review catches what reviewers can see. When an AI agent mediates the interaction, the attack surface moves outside your review process.
In the OpenClaw attack, the malicious actor didn't compromise your codebase. They published a skill to a public repository. A developer asked their AI agent for help. The agent fetched the skill, executed it, and followed its instructions to recommend malware installation. Your pull request review never saw this chain of events because it happened in the developer's local environment, guided by conversational prompts.
This is fundamentally different from traditional supply chain attacks where malicious code enters your dependency tree. Here, the AI agent becomes the vector, and the attack payload is delivered through natural language instructions that bypass your review gates entirely.
Myth 3: "We Can Just Vet AI Agent Plugins Before Use"
Reality: Vetting works when you have a stable, enumerable set of components. AI agent ecosystems don't work that way.
ClawHub implemented security controls, including requiring accounts to be one week old before publishing skills and hiding skills with more than three reports. These are necessary but insufficient. The fundamental problem is scale and dynamism: agents can discover, fetch, and execute skills at runtime based on user requests. You can't pre-approve what you don't know your agents will use.
Even if you lock down to an approved skill list, you're fighting two forces:
- Developer productivity demands mean they'll route around restrictions
- The value proposition of AI agents is their ability to dynamically compose capabilities
Vetting becomes an approval bottleneck that either slows development to a crawl or gets bypassed through shadow IT.
Myth 4: "Endpoint Security Will Stop Malicious Agent Actions"
Reality: From your EDR's perspective, the AI agent is a legitimate process making legitimate API calls at the user's request. There's no malware signature to detect.
When an agent recommends running pip install malicious-package, and the user executes that command, your endpoint security sees:
- Authorized user
- Standard package manager
- No suspicious process behavior
- No known malware signatures
The attack succeeds because it exploits the human-in-the-loop. The agent doesn't execute the malicious action—it convinces the user to do it. Your security tools are designed to catch automated attacks, not social engineering delivered through trusted interfaces.
Myth 5: "This Is Just a Supply Chain Problem We Already Know How to Solve"
Reality: Traditional supply chain security focuses on dependency integrity and vulnerability management. AI agent attacks introduce a new vector: conversational manipulation.
Yes, the OpenClaw attack ultimately delivered malware through a package repository. But the novel element is how it got there. Traditional supply chain attacks rely on:
- Typosquatting
- Compromised maintainer accounts
- Malicious code hidden in legitimate packages
AI agent attacks add:
- Social engineering through natural language
- Dynamic capability discovery
- Trust transfer from agent to external resources
- Context-aware attack timing
Your software composition analysis tools will catch known vulnerabilities in packages. They won't catch an agent recommending a malicious package that has no CVEs because it's purpose-built malware, not a compromised legitimate library.
What to Do Instead
You need security controls that operate at the agent interaction layer, not just the code layer.
Implement behavioral guardrails. Before an agent can recommend external resources, validate against a policy engine that checks: Is this domain/package/skill on an approved list? Does the recommendation match the user's actual request? Are there safer alternatives?
Log agent recommendations separately from executions. When an agent suggests installing a package, log that recommendation with full context before the user acts on it. This creates an audit trail for post-incident analysis and enables detection of suspicious patterns.
Apply least privilege to agent capabilities. Your agents don't need unrestricted access to skill repositories, package managers, and external APIs. Segment what different agent types can access based on their function.
Build content-aware monitoring. Monitor the semantic content of agent interactions for patterns like: recommending installation of packages not in your approved registries, suggesting commands that disable security controls, or walking users through multi-step processes that end in credential exposure.
Require explicit approval for high-risk actions. When an agent recommends installing dependencies, modifying authentication, or accessing sensitive data, inject a human approval step with context about what's being requested and why.
The security model that worked for static code and traditional applications doesn't map to AI agents that operate through conversation and dynamic capability composition. Your defenses need to evolve to match the new attack surface—or you'll keep missing threats that your existing tools were never designed to see.
AI security
