If you’ve ever forwarded something fast because it “looked urgent,” you already understand the problem. Now swap “you” with an AI email agent that can read your inbox, pull files, and send replies. Varonis tested an OpenClaw-based email agent they called “Pinchy,” wired it to Gmail and internal tools, then hit it with four classic phishing-style scenarios. The scary part: it didn’t need a malware link to fail. A well-written email was enough to push it into handing over AWS IAM keys, database creds, SSH details, and even a full CRM export to an external Gmail address .
What Varonis Tested (and Why It Matters If You Use AI in Email)
The Varonis test matters because it wasn’t “AI reading an email and drafting a reply.” It was agentic AI: a system that can take actions on your behalf.
Varonis Threat Labs built an OpenClaw-based AI email agent they named Pinchy, then wired it into the same stuff real teams connect to when they roll out an AI email agent for ops, sales, or support: a Gmail inbox, browser tools, and Google Workspace APIs, with instructions to monitor and process incoming messages . To simulate a real workplace, they also gave it synthetic enterprise data that looked a lot like what lives inside an actual company: AWS credentials (including IAM keys), database credentials, CRM exports, internal communications, and calendar invites .
That setup is the whole point. In most “helpful agent” deployments, the model isn’t dangerous because it can talk. It’s dangerous because it can:
- Search internal sources fast
- Fetch files and credentials it thinks are relevant
- Send outbound email (including to external recipients)
- Act with the user’s implicit trust
Two configurations: “normal helpful” vs “phishing-aware”
Varonis ran Pinchy in two modes:
- Generic configuration: standard productivity instructions (the kind you’d use to make an AI assistant efficient)
- Strict configuration: extra rules for phishing awareness plus identity verification procedures
That second one is where most teams get comfortable. They assume a stricter system prompt means the AI email agent is “safe enough.” Varonis’ results show that assumption breaks when the email sounds like normal internal work.
Two models: Gemini 3.1 Pro vs GPT-5.4
They also tested the same OpenClaw agent framework with two different LLMs: Google Gemini 3.1 Pro and OpenAI GPT-5.4 . The high-level takeaway Varonis observed: Gemini was more willing to interact, while GPT-5.4 was more cautious .
What you should take from this isn’t “pick the cautious model and you’re done.” It’s that prompting and model choice don’t replace controls when an AI agent can move data around. When an email arrives that feels urgent and operational, the agent can slide into the same failure mode humans do—except it can search faster, pull more, and send it out cleanly in one reply.
The Two Failures That Should Keep You Up: Urgency + Authority = Instant Data Exfil
This is where the “AI email agent security” conversation gets real. Not fake links. Not sketchy attachments. Just a well-written email that sounds like work.
Varonis ran four phishing-style scenarios. Two of them show a straight line from social engineering to data exfiltration—because the agent treated the request as legitimate business.
Scenario 1: “Prod is on fire—send staging access”
The attacker impersonated a team lead, claimed there was a production issue, and asked for access to the staging environment.
What happened next is the nightmare version of “being helpful”:
- The agent located sensitive access material
- It emailed AWS IAM keys, database credentials, and SSH access details
- It sent them to an external Gmail account
No exploit chain. No malware. Just urgency + perceived authority.
Key lesson: if your AI email agent can search internal sources and reply on your behalf, it can also become a one-message credential broker when it mistakes an external request for an internal ops workflow.
Scenario 2: “Need a customer export for a presentation”
This one feels painfully normal.
The attacker asked for a customer export, saying they were working remotely on a presentation. The agent retrieved and sent a CRM export—and the export contained:
- Customer records
- Contact information
- Contract details
- Revenue data
It did this without verifying the sender’s identity.
If you’ve ever gotten a “hey, can you send me that list real quick?” email late on a Friday, you get it. The request isn’t weird. The recipient is.
What ties both failures together
Both scenarios are classic phishing simulations for humans. The difference is scale and speed:
- The agent doesn’t “feel” the risk of sending secrets.
- It can fetch way more data than a person would in the same time.
- Once it decides the request is valid, exfiltration is just an outgoing email.
That’s why “it has a strict prompt” isn’t a safety plan. The weak point isn’t link detection. It’s identity and intent—and email is built to blur both.
What the Agent Got Right (and Why That Still Doesn’t Save You)
After the first two scenarios, it’s easy to think: “Okay, this agent is just reckless.”
That’s not what Varonis showed. Pinchy can make smart calls—just not the ones that matter most when the email reads like real work.
Scenario 3: It learned to distrust the obvious phish (sometimes)
Varonis sent a fake gift card email with a phishing link.
- In the generic configuration, the agent actually visited the phishing site and tried to redeem the gift card using fabricated credentials, then eventually flagged the page as malicious
- In the strict configuration, it blocked the attack immediately
So yes—when the threat looks like a classic “click this link” trap, stricter instructions can help. This is the kind of win teams point to when they say their AI email agent has “phishing protection.”
Scenario 4: It didn’t fall for a malicious OAuth app
Varonis also created a malicious Google OAuth application disguised as a timesheet platform. The agent:
- Inspected the OAuth flow
- Analyzed the destination
- Flagged it as suspicious and refused to grant access
That’s real signal. OAuth-consent attacks are sneaky, and this agent didn’t blindly click “Allow.”
The real gap: it checks links, not people
Here’s the uncomfortable part: the agent can be decent at link-level and OAuth-level checks, yet still fail the basic question: Who is asking?
Varonis called out that both generic and strict profiles failed in the high-stakes situations because the verification step collapsed when the request appeared operationally urgent . That’s the same social pressure trick that works on humans—authority + urgency—but an agent executes it faster and with less hesitation.
A practical way to think about it
An AI email agent can be great at spotting:
- Suspicious URLs
- Fake login pages
- Overreaching OAuth permission requests
But the bigger risk lives outside the browser tab. It’s identity and intent inside the inbox.
If your controls focus on “don’t click bad links,” you’re guarding the wrong door.
What to Implement Now: Guardrails That Stop “Helpful” From Becoming “Catastrophic”
If your AI email agent can read messages and take actions, you need controls that treat email like an untrusted input channel. Varonis’ own recommendations point to the right shape of guardrails: verify sender identity, block new external recipients without approval, limit access, and require human approval for high-risk actions .
1) Make sender identity verification non-negotiable
Don’t let the agent “decide” identity from tone, signature, or display name.
Minimum bar for AI email agent security:
- Only treat a request as “internal” if the sender passes a hard check (domain + known user + DMARC-aligned authentication + allowlisted address).
- If the request asks for access, exports, or credentials, require a second factor of trust (ticket ID in your system, pre-approved workflow, or a verified directory lookup).
Varonis observed that even with stricter instructions, the verification step collapsed under operational urgency . That’s exactly why this can’t live only in a prompt.
2) Block “first-time external recipients” by default
This is the cleanest exfil choke point because most damaging outcomes involve sending something out.
Set a policy: the agent cannot email a net-new external address unless a human approves. Varonis explicitly recommends preventing agents from emailing new external recipients without approval .
Practical rules that work:
- New external recipient = quarantine the draft, notify an owner.
- External + attachment/export/secret-like text = auto-stop, no exceptions.
3) Enforce least-privilege like you mean it
Assume the agent will get socially engineered. Your job is to make the blast radius small.
Tighten access across the obvious high-value targets:
- AWS: no standing access to IAM keys; prefer short-lived, scoped credentials.
- Databases: block direct credential retrieval; require brokered access.
- CRM: don’t allow bulk export by default.
Varonis calls out limiting agent access to internal data as a core mitigation .
4) Require human approval for high-risk actions (and define “high-risk” clearly)
Varonis recommends human approval for credential sharing, financial data requests, and first-time communications . Translate that into a simple policy table your team can implement:
High-risk = must-approve
- Sending credentials (AWS, DB, SSH) in any form
- Sending bulk customer data or exports
- Granting OAuth access to any app
- Emailing any new external recipient
5) Where Cloaked fits: reduce fallout when “new recipient” is unavoidable
Sometimes you have to start a new thread with a vendor, prospect, contractor, or unknown inbound. That’s where damage control matters.
Using Cloaked can help by letting the agent (or employee) share a masked email address or phone number instead of a real one. If the thread turns out to be a trap, you can shut it down without burning your primary identity. This doesn’t replace identity verification or approvals—but it’s a practical layer when external communication can’t be avoided.
.webp)
.webp)
