2026-08-14 · AI red teaming
AI agent security risks: lessons from the OpenClaw exploits for SaaS teams
Two research teams recently demonstrated how easily AI agents can be tricked into leaking credentials and executing attacker code. The techniques they used should concern every SaaS engineering lead integrating LLM-powered automation into their products.
The OpenClaw vulnerabilities aren't edge cases; they're textbook examples of AI agent security risks that emerge when connecting language models to real business systems without fully understanding how prompt injection works in production. We've seen these patterns repeatedly during our AI red teaming engagements: agents that trust their inputs, lack proper authorization boundaries, and execute actions based on conversational requests rather than verified commands.
The input trust problem: when message objects become attack vectors
The Imperva research exposed a fundamental architectural mistake: OpenClaw was treating structured message objects (contacts, vCards, location pins) as trusted data and injecting them directly into the LLM prompt without marking them as untrusted content.
When you send a shared contact through WhatsApp to an AI agent, the platform serializes it as <contact: name, number>. The angle brackets are legal characters in a contact name field. The agent truncates long names in the UI, so users don't see what's actually there. An attacker can stuff the name field with instructions like "download and execute this script," and the LLM receives it as part of the system prompt, no different from legitimate instructions you wrote.
This isn't theoretical. The researchers got Gemini 3.1 Pro to execute attacker-controlled code through a contact name. The same technique worked through vCard full-name fields and location pin labels. All three are ordinary features users interact with daily.
The fix (moving untrusted fields into a separate metadata channel) is straightforward once you recognize the problem. Most teams building AI features don't recognize it until after deployment. They focus on obvious injection vectors like user messages or web scraping and miss the structured data that flows through their integrations.
We see this constantly: teams assume that because data comes through an authenticated API or established messaging protocol, it's somehow safer than raw user input. It's not. Any content your agent processes that originated outside your direct control is an injection risk.
Authorization failures: when agents execute before they verify
The Varonis research demonstrated something even more concerning: you don't need hidden instructions to compromise an agent. A normal email from an unknown address, written in plain English, convinced the test agent to forward AWS credentials and customer data to an external recipient.
This is agent phishing, and it works because most AI agents are designed to be helpful first and careful second. The test agent ("Pinchy") received an email from someone claiming to be "Dan" from the team, requesting staging credentials during a fake production incident. The agent found the credentials in its accessible context and forwarded them. No prompt injection, no hidden payloads. Just a believable request through a legitimate channel.
The agent never checked:
- Does this sender actually work here?
- Is this email domain authorized to receive credentials?
- Should I be able to access these secrets at all?
- Does this action require human approval?
These aren't LLM limitations. They're authorization architecture failures. The agent had broad access to sensitive data and the ability to share it externally, with no guardrails beyond the model's judgment about whether a request "seemed reasonable."
This is the AI agent security risk that keeps us up at night when we're scoping red team engagements. Your agent might be perfectly resistant to jailbreaks and prompt injection, but if it has access to your customer database and someone can convince it through natural conversation to export records, you have a data breach waiting to happen.
What multi-tenant SaaS teams need to know
If you're building AI features into a B2B SaaS platform, these vulnerabilities compound in multi-tenant environments.
Cross-tenant context leakage is the first concern. An agent with access to multiple customers' data needs rock-solid tenant isolation. A prompt injection or social engineering attack that works in one tenant's context shouldn't be able to extract another tenant's information. We test for this explicitly: can we get an agent to "accidentally" include Tenant B's data when responding to Tenant A's query?
Tool and integration sprawl compounds the risk. Every integration you give your agent (email, Slack, GitHub, AWS, your own API) is a potential privilege escalation path. The OpenClaw agent could download and execute code because it had that capability. Your agent probably has access to your production database, your CI/CD pipeline, and your customer communication channels. Map those permissions before an attacker does.
Persistent memory attacks are underappreciated. OpenClaw enables conversation memory by default. Imperva noted that a single piece of widely shared content with hidden instructions could compromise multiple agents over time. If your agent remembers context across sessions or users, a successful injection in one conversation could influence future interactions, including interactions with different customers.
Practical security controls you can implement today
Based on what we've learned from dozens of AI red team assessments, here's what actually reduces AI agent security risks in production.
Mark all external content as untrusted. Anything that didn't originate from your verified system prompt should be explicitly tagged. Use delimiters, separate channels, or structured formats that make it impossible for the LLM to confuse user content with instructions.
Implement strict authorization checks before actions. Your agent should verify sender identity, check permissions, and require approval for sensitive operations, regardless of how convincing the request sounds. Don't rely on the LLM to make security decisions.
Limit agent capabilities to the minimum required. If your agent doesn't need to execute code, don't give it that capability. If it doesn't need to send external emails, remove that integration. Every tool is an attack surface.
Log everything with full context. When your agent takes an action, log the complete conversation, the tools it used, and the authorization checks it performed. You need this for incident response and for understanding how an attack succeeded.
Test with adversarial inputs regularly. Don't wait for researchers to publish exploits against your specific platform. Run your own red team exercises with prompt injection attempts, social engineering scenarios, and cross-tenant attack simulations.
Getting AI security right before compliance audits force it
The OpenClaw vulnerabilities were patched quickly because security researchers found them first. Most SaaS teams aren't that lucky. They discover AI agent security risks during a SOC 2 audit, a customer security questionnaire, or worse, after an incident.
If you're integrating AI agents into your product and you haven't specifically tested for prompt injection, jailbreaks, tool abuse, and cross-tenant isolation failures, you're shipping known vulnerability classes into production. The techniques aren't secret. They're documented in OWASP LLM Top 10 and MITRE ATLAS. The question is whether you find them before your customers do.
At Faultline Security, we run AI red team assessments specifically designed for B2B SaaS platforms. We test your agents with the same techniques that compromised OpenClaw, including dozens of other patterns we've developed from real-world engagements. You get reproducible findings with full conversation transcripts, not generic scanner output. If you're facing a compliance audit, investor due diligence, or you just want to know whether your AI features are actually secure, get in touch. We'll tell you exactly where your agents break and how to fix it.