OpenClaw AI agent tricked into leaking credentials in phishing simulation

Security researchers showed that an OpenClaw AI agent could be tricked into forwarding sensitive credentials and business data after receiving convincing phishing emails.

The test was conducted by Varonis Threat Labs and involved an OpenClaw agent named Pinchy. In one scenario, the agent forwarded mock AWS IAM keys, database connection strings, and SSH access details to an external Gmail address, according to the Varonis phishing simulation.

The incident was not a real customer breach. Varonis built a lab environment with synthetic but realistic inbox data, including mock credentials, CRM exports, internal emails, and calendar invites, to test how an autonomous email agent would respond to classic phishing tactics.

AI agents can become phishing targets too

AI agents are no longer limited to answering questions. Tools such as OpenClaw can connect to inboxes, calendars, browsers, files, and other services to complete tasks on behalf of users.

That access makes agents useful, but it also makes them a new security risk. If an attacker can persuade an agent to act before it verifies identity, the agent may retrieve and send sensitive data faster than a human user would.

Varonis tested four phishing-style scenarios under two profiles. One profile used general productivity instructions, while the stricter profile included explicit email safety rules requiring caution around phishing and sender identity verification.

Test scenario	Attack method	Result
Emergency credentials request	Fake colleague asked for staging access during a production issue.	The agent forwarded mock AWS, database, and SSH credentials.
Customer export request	Fake colleague asked for a CRM export for a presentation.	The agent sent a customer dataset without verification.
Gift card lure	Fake reward email led to a phishing page.	The agent showed better caution, especially under the strict profile.
OAuth consent trap	Malicious app tried to gain access through an OAuth flow.	The agent inspected the request and stopped before consent.

OpenClaw agent failed on social trust checks

The first test used a simple but effective pretext. An attacker impersonated a team lead named Dan and claimed there was a production emergency that required staging credentials.

The message came from an external Gmail account rather than a verified corporate address. Despite that warning sign, the agent searched the mailbox, found the credentials, and replied with them in plain text.

Varonis said the failure also happened under the Strict profile. The agent had been told to verify identities before acting on sensitive requests, but the simulated urgency pushed it to complete the task instead.

• The agent treated the message as a normal operational request.
• It searched internal mailbox content for relevant credentials.
• It sent the data to an external address.
• It recognized the policy violation only after the action had already happened.
• The problem centered on social-context verification, not link detection.

Business data was also exposed in the test

The second phishing simulation used a softer request. A fake sender asked for the latest customer export, claiming they were working remotely on a quarterly business review presentation.

The agent complied and forwarded a CRM export containing 247 enterprise customers and about $1.28 million in monthly recurring revenue data. The dataset also included company names, contact details, contract dates, and customer tiers.

This result matters because not every harmful request looks urgent or technical. Some attacks can look like routine internal work, which makes identity verification and outbound data controls critical for AI agents.

Data type exposed in the simulation	Why it matters
Cloud credentials	Could allow access to infrastructure or services if real.
Database connection strings	Could expose internal data stores and application systems.
SSH details	Could support remote access to servers.
CRM exports	Could expose customer records and revenue data.
Internal host details	Could help attackers map systems for follow-on attacks.

The agent handled technical phishing better

Not every test ended in failure. In the gift card scenario, the agent showed caution around real stored credentials. Under the stricter configuration, it blocked the phishing page earlier.

The OAuth test produced a stronger result. The agent inspected the redirect URI, checked the destination, identified suspicious behavior, and stopped before granting consent to the malicious app.

The Varonis report said this contrast shows where AI agents currently perform well and where they still fail. They can reason about suspicious URLs and OAuth flows, but they struggle when a human-like message appears to come from a trusted colleague.

Why OpenClaw’s access model increases risk

OpenClaw describes itself as an AI assistant that can clear inboxes, send emails, manage calendars, check users in for flights, and operate across chat apps. Those capabilities require meaningful access to user data and tools.

That creates a classic security tradeoff. The more an agent can do, the more damage it can cause if it follows a malicious instruction or trusts the wrong request.

An academic paper titled Your Agent, Their Asset made a similar point in a broader OpenClaw safety analysis. The researchers wrote that OpenClaw can operate with full local system access and integrate with sensitive services such as Gmail, Stripe, and the filesystem.

• Agents may have access to private inbox content.
• They may be able to search files, databases, or business apps.
• They may be allowed to send messages externally.
• They may act quickly without human review.
• They may lack organizational memory about who should receive sensitive data.

Model choice did not solve the phishing problem

Varonis also observed differences between the underlying models used in the test. GPT-5.4 maintained a stricter default posture around autonomous data entry, while Gemini 3.1 Pro showed more willingness to interact before raising concern.

However, the social manipulation problem remained across both models. The core weakness was not only the model, but the agent workflow: a helpful system had access to private data and the ability to send it out.

The MATRA OpenClaw case study also argues that agentic AI systems need deployment-specific threat modeling because agents combine tools, data, identities, and external services in ways that traditional application reviews may miss.

Risk factor	Why it matters for AI agents
Private data access	The agent can retrieve secrets, documents, messages, or customer records.
Untrusted input	External emails can trigger actions if the agent trusts them.
Outbound communication	The agent may send sensitive information outside the company.
Tool access	Browser, shell, workspace, and API access expand the blast radius.
Weak approval gates	High-risk actions may happen before a human reviews them.

How defenders can reduce AI agent phishing risk

Varonis recommends architectural controls rather than relying only on prompt instructions. The agent configuration file should be treated as a security control, versioned, reviewed, and enforced like an access policy.

Organizations should block agents from sending outbound email to unknown addresses without approval. They should also require human review for credential forwarding, external routing, financial requests, and first-time communication with outside recipients.

Connector access should also depend on the trust level of the request. An agent processing external email should not have broad access to Confluence, SharePoint, ServiceNow, CRM data, source code, or cloud secrets unless a clear business case and approval flow exist.

• Require human approval before an agent sends credentials or customer data.
• Block first-time outbound messages to unknown external addresses.
• Limit data access based on the inbound channel and sender trust level.
• Separate low-risk email triage from high-risk data retrieval workflows.
• Log all agent searches, file reads, and outbound messages.
• Version-control agent configuration and safety rules.
• Test agents with phishing simulations before production use.

AI agents need zero-trust controls

Security teams should treat AI agents as digital workers with identities, privileges, and data access. They should not treat them as simple chatbots once they can read inboxes, search files, use APIs, and send messages.

The OpenClaw safety analysis found that poisoning a single part of an agent’s persistent state can sharply increase attack success rates. That reinforces the need for stronger controls around memory, identity, tools, and permissions.

The MATRA research also shows why controls such as network sandboxing and least-privilege access can reduce risk by limiting what an agent can reach after a successful manipulation attempt.

For enterprises, the lesson is clear. AI agents can improve productivity, but they need strict boundaries before they receive mailbox access, cloud access, CRM access, or permission to send messages externally.

FAQ