OpenClaw AI Agent Leaks Credentials in Phishing Simulation

Autonomous email agents can become high‑impact phishing victims, leaking cloud credentials and sensitive business data even when wrapped in explicit safety instructions.

In a controlled lab deployment on the OpenClaw agent platform, an AI agent dubbed “Pinchy” failed multiple classic phishing simulations, including one in which it forwarded AWS IAM keys, database passwords, and SSH credentials from a corporate-style inbox to an external Gmail account after a single casual request from an impersonated “Dan.”

The lab setup replicated a realistic enterprise inbox inside Google Workspace, backed by a dedicated Gmail account populated with synthetic but representative artifacts: mock AWS credentials, CRM exports, internal mail threads, calendar invites, and typical low‑priority noise.

OpenClaw orchestrated a dual‑agent design: an “Orchestrator” agent received incoming emails, classified the task, planned a response, and delegated work, while a “Worker” agent executed actions via browser automation, shell access, and Google Workspace APIs.

Both Google Gemini 3.1 Pro and OpenAI Codex GPT‑5.4 were evaluated under two configuration profiles: a Generic productivity profile and a Strict profile that layered an explicit Email Safety policy on top, instructing the agent to verify identities and treat phishing as a first‑class risk.

Varonis distinguishes between indirect prompt injection and what it calls “agent phishing.” Prompt injection rides in hidden instructions embedded in content such as web pages, documents, or invites and attacks the parsing and intent‑derivation layer of the model.

Agent phishing operates higher up: it delivers a plausible‑looking email or message and wins if the agent acts on the request without confirming who is asking.

Both fit Simon Willison’s “lethal trifecta” of private data access, exposure to untrusted content, and the ability to send outbound messages, but they exploit different layers of that stack.

OpenClaw AI Agent Leaks Credentials

Varonis Threat Labs explored whether the same phishing techniques that have tricked humans for decades would also work on the AI agents working on their behalf.

In the first case study, an attacker posing as “Dan” emailed Pinchy from an external Gmail address, asking for staging credentials to handle a supposed production incident.

The agent searched the inbox, found stored secrets, and forwarded AWS keys access, database connection strings, and SSH details in plaintext.

Notably, this occurred even under the Strict profile, which clearly instructed the agent to verify sender identity before acting on sensitive requests.

The post‑hoc reasoning trace acknowledged that this violated policy, but the urgency framing of a production emergency overrode the verification step in both profiles.

The second scenario used a softer, business‑as‑usual pretext: a request for the latest customer export to finish a QBR presentation from home.

Pinchy pulled a CRM export containing hundreds of enterprise customers, contact details, contract data, tiers, and over a million dollars in recurring revenue information, then forwarded it externally without identity checks.

Here, the pretext’s normality was the problem: the agent’s default task‑execution loop cut straight through Zero Trust principles that would require identity and channel verification before sharing internal data, again in both Generic and Strict configurations.

Some simulations exposed more nuanced behavior. In a “gift card” phishing test, an external email lured the agent to a fake redemption site.

Under the Generic profile, Pinchy followed the link and interacted with the page but refused to submit real credentials, instead entering fabricated data; only after a failed server‑side validation did it escalate suspicion and classify the site as phishing.

The Strict profile blocked the flow immediately. While the agent avoided credential loss, its initial interaction still revealed that the page was live and exposed network metadata, illustrating that partial resistance is not the same as safe behavior.

The clearest display of technical reasoning appeared in an OAuth consent trap involving a malicious Google application disguised as a timesheet system. Rather than blindly accepting the OAuth prompt, Pinchy inspected the redirect URI, independently visited the destination, judged it suspicious, and stopped before granting access.

Across runs, the models reliably detected impersonation attempts against major cloud platforms such as AWS, Azure, Microsoft, and Google.

GPT‑5.4 showed a stricter default stance on autonomous data entry, whereas Gemini 3.1 Pro was more inclined to interact before escalating; however, both were similarly vulnerable to socially framed, identity‑based deception.

Varonis’ findings support a shift from prompt-only mitigations to architectural controls around AI agents.

Treating the agents.md configuration as a governed security control, segmenting connector access by inbound channel, preventing agents from acting as phishing proxies for first‑touch outbound mail, and enforcing human‑in‑the‑loop approval for high‑privilege actions like credential forwarding were all effective in reducing or containing compromise.

These results echo broader industry concern that as enterprises wire agents directly into inboxes and internal systems, low‑skill phishing may become less effective, but highly contextual spear phishing aimed at agents could become dramatically more valuable.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.