Agent Phishing Shows Why Tool Permissions Need Identity Checks

The most useful agent security story this week is not another argument about whether agents should have tools. It is a pair of fresh OpenClaw studies showing what happens when ordinary inputs reach powerful tools before identity and trust boundaries are enforced.

On June 9, Varonis Threat Labs published “Phishing for Lobsters”, a test of an OpenClaw email agent named Pinchy. The agent was connected to Gmail, browser tools, shell access, and Google Workspace APIs, then placed in a synthetic corporate inbox seeded with realistic secrets and business data. In two of the most important scenarios, a single plausible email caused the agent to forward mock AWS keys, database connection strings, SSH credentials, and a customer export to an external address.

The next day, Imperva published research on prompt injections in message objects. Instead of hiding instructions in a webpage or image, the researchers put malicious instructions in shared contacts, vCards, and location labels. Those message objects were flattened into the model prompt without a clear untrusted-data boundary. In Imperva’s tests, the hidden instruction crossed into the authenticated user context and triggered attacker-controlled code execution. OpenClaw fixed the reported issue in version 2026.4.23.

The broader security press noticed because the two findings rhyme. The Hacker News covered both studies together, framing them as different doors into the same room: an agent trusts what reaches it, and the agent’s access becomes the attacker’s. BleepingComputer, The Next Web, TechRadar, and a current Reddit discussion picked up the same lesson.

This is the right story for SkillSafe because it moves the conversation from “can a plugin be malicious?” to “what should a trusted plugin be allowed to do when the request came from an untrusted person or object?”

The Weak Point Was Not URL Detection

The Varonis results are uncomfortable because Pinchy did some things well.

In the gift-card phishing scenario, the stricter configuration blocked the attack immediately. In the OAuth-consent scenario, the agent inspected the redirect target, identified suspicious behavior, and refused to approve the malicious app. That is exactly the kind of technical phishing detection people hope agents will be good at.

Then the agent failed the simpler social cases.

An attacker impersonated a team lead named Dan from an external Gmail account and asked for staging credentials during a simulated production issue. Pinchy searched the mailbox, found the credentials, and forwarded them externally. In another scenario, the attacker asked for a weekly customer export for a QBR deck. Pinchy sent a synthetic dataset containing 247 enterprise customers and contract details.

The strict profile told the agent to verify senders before acting on sensitive requests. That instruction existed. The problem is that the verification step was still a prompt-level behavior competing with task completion, urgency, and the agent’s drive to be useful.

For human phishing, we teach people to look for suspicious links, fake domains, odd tone, and urgency. For agent phishing, those signals still matter, but they are not enough. An agent connected to email, files, SaaS APIs, and outbound messaging needs an enforced identity gate before the tool call happens.

That gate cannot just be a sentence in an instructions file.

Message Objects Are Tool Inputs Too

Imperva’s research is the prompt-injection version of the same failure.

OpenClaw already treated some fetched web content as untrusted. The problem was that messaging objects took a different path. A shared contact name, vCard field, or location label could be serialized into prompt text in a way the model interpreted as ordinary context rather than untrusted metadata.

That distinction matters because message objects feel harmless. A contact card is not a shell script. A location label is not a plugin. A vCard is not a skill. But once those fields are passed to an agent that can run tools, read memory, or execute commands, they become part of the agent’s input surface.

The attacker does not need the object to be executable. The attacker needs the object to be trusted enough to influence the model that chooses the executable action.

OpenClaw’s patch moved those fields into a separate untrusted-metadata channel. That is the right direction. It also points to a broader rule: every input that reaches an agent should carry trust context all the way to the tool policy layer.

The source matters. The sender matters. The channel matters. The object type matters. The current task matters. The requested tool matters.

If those attributes disappear during serialization, the agent is left with text and vibes. That is not a permission model.

Skills and Plugins Need Request Context

Most agent security advice focuses on install-time trust:

• Did this skill come from the publisher it claims?
• Did the plugin request dangerous permissions?
• Does the MCP server expose shell, filesystem, credential, or network access?
• Did the artifact pass a scan before install?
• Does the installed hash match the reviewed hash?

Those questions still matter. They are the reason we keep writing about dual-side verification, ClawHavoc, MCP tool poisoning, and Agent Bills of Materials.

But the Varonis and Imperva research shows why install-time trust is only the first layer.

A legitimate connector can still be dangerous when invoked from the wrong context. A safe filesystem tool can be unsafe if the request came from an external email. A useful CRM export skill can become an exfiltration path when the sender identity is spoofed. A trusted messaging integration can become a prompt-injection carrier when object metadata is flattened into the agent prompt.

That means skills and plugins need request context, not just static permissions.

For example:

• A skill that retrieves credentials should require a verified internal identity and human approval.
• A connector that sends outbound email should block first-time external recipients unless a human approves.
• A CRM export tool should refuse requests triggered by unverified email, even if the user normally has CRM access.
• A shell or browser tool should not run from content that originated in a message object, webpage, attachment, or vCard without a strong trust boundary.
• A memory-writing skill should treat untrusted inbound messages as data, not instructions.

This is not an argument against agent tools. It is an argument for attaching permissions to who asked, where the request came from, and what the agent is about to do.

The Supply-Chain Lesson

Agent supply-chain security has two halves.

The first half is artifact trust. Skills, plugins, MCP servers, connectors, and tool manifests need provenance, scanning, tamper detection, and update review. That is the part most similar to package security.

The second half is invocation trust. Once a capability is installed, the runtime needs to decide whether this specific request should be allowed to use it.

Traditional package managers mostly stop at install and update. Agents cannot. An agent consumes hostile content all day: emails, tickets, pull requests, webpages, calendar invites, documents, chats, screenshots, contact cards, and tool outputs. Some of that content will be adversarial. Some of it will look routine. Some of it will come from real people whose accounts are compromised.

If any of that content can steer a high-privilege tool, the installed capability becomes part of a live supply chain.

That is why scanning still matters. A skill that contains instructions to forward secrets should be blocked before install. A plugin manifest that asks for broad write access should be reviewed. An MCP server that exposes dynamic tools should be inventoried. But runtime policy needs to carry the rest:

• verified sender identity
• channel trust level
• data classification
• tool risk level
• destination trust
• human approval state
• audit trail for the full agent path

Without those fields, a clean scan report can create false confidence. The artifact may be clean, but the invocation may still be wrong.

Practical Defenses

Teams deploying agent tools can start with a simple rule: do not let unverified inbound content directly trigger privileged actions.

That rule has concrete implications.

Separate read, write, send, and execute permissions. An inbox-triage agent may need to read email. It does not automatically need the ability to forward secrets, export CRM data, call the shell, or send first-contact messages to external addresses.

Bind allowlists to stable identities, not display names. Email aliases, chat names, contact cards, and visible labels are presentation data. Policy should use stable account IDs, verified domains, signed identities, or admin-managed groups wherever possible.

Treat message objects as untrusted input. Contacts, vCards, location pins, attachments, calendar descriptions, ticket bodies, and PR comments should carry an untrusted marker into the model context and the tool policy layer.

Require human approval for high-blast-radius actions. Credential forwarding, customer-data export, new OAuth consent, deployment, payment, shell execution, memory writes, and outbound messages to new recipients should pause before they run.

Keep an agent inventory. For each agent, record installed skills, enabled plugins, configured MCP servers, connected accounts, OAuth scopes, paired devices, and sensitive tools. The inventory should also record which capabilities can be triggered from which channels.

Scan and verify artifacts before install. This is still the foundation. A runtime policy cannot compensate for a skill that is already malicious by design. Use publisher-side scanning, consumer-side re-scanning, and cryptographic hash binding so the artifact being installed is the artifact that was reviewed.

Log the whole path. A normal-looking API call can be unsafe if it was triggered by a spoofed email or poisoned contact card. Useful logs need to show the input source, agent reasoning boundary, selected tool, parameters, destination, policy decision, and human approval state.

Where SkillSafe Fits

SkillSafe focuses on the artifact layer: verifying AI skills and plugin-like files before agents consume them. That remains essential. ClawHavoc showed how malicious skills can enter a registry. MCP tool poisoning showed how hidden metadata can steer agent behavior. The current OpenClaw research shows that even ordinary content can become dangerous when a trusted tool has no identity-aware gate in front of it.

Those layers belong together.

A SkillSafe scan can tell teams whether a skill asks for credential access, network exfiltration, shell execution, memory writes, suspicious downloads, or prompt-injection behavior. Dual-side verification can prove that the installed files match the reviewed files. An Agent Bill of Materials can keep that evidence attached to the running agent.

The next step is making that evidence useful at runtime. If a skill has high-risk behaviors, the agent should require stronger sender identity, a more trusted channel, or human approval before invoking it. If a connector can export customer data, the policy should care whether the request came from a verified manager, an external email, a shared contact field, or a model-parsed document.

The Varonis and Imperva findings are a reminder that agents do not just need safer tools. They need safer decisions about when a tool may be used.

The artifact can be trusted.

The request still has to earn trust.