The trap of self-confidence and what to do before it is late

Two research teams have shown this week that self-housed self-employed agents can be committed to techniques that seem harmless: Imperva showed that OpenClaw performed hidden instructions in shared contacts, vCards and location pins, and Varonis proved that a well-configured agent can be persuaded by credible emails to filter keys and sensitive data. The vector was not a cryptic exploitation of the model, but the way the agent trusts the information that comes to him and gives it to the LLM without marking it as unreliable.

Imperva's technical finding reveals a failure in OpenClaw's "plumbing": by serializing messaging objects the agent inserts fields such as contact name or location label directly into the prompt, using a format that allows to include legal characters (such as minor / major signs) to camouflage instructions. The practical result was that, in its tests with Gemini 3.1 Pro, the model downloaded and executed a script hosted by the researchers. OpenClaw corrected that behavior in version 2026.4.23 by moving those fields to a metadata channel marked as unreliable; if the tool is used, updating to that version is the minimum and immediate action. To understand best practices on LLM insecurities and agents it is appropriate to review the Community's work on model safety, for example in the OWASP project on LLM security https: / / owasp.org / www-project-llm-security /.

Varonis, on the other hand, addressed the problem by social means: he built an agent called Pinchy, fed it with a simulated mailbox full of business data and conducted phishing campaigns directed to the agent in Gemini 3.1 Pro and OpenAI Codex GPT-5.4. The evidence showed that an apparently legitimate mail - urgent or routine - was sufficient for the agent, despite having rules to verify shipments, to send AWS keys and customer exports. The conclusion is clear: the agents are excellent by analyzing URLs and suspicious technical portals, but they are much more fragile against social pretexts that exploit their inclination to help. Varonis proposes architectural controls: policies such as system-applied code, exit doors for outgoing emails to new directions, control of the level of confidence by connector and blocking of high-risk actions until human confirmation.

These incidents not only expose specific bugs; they show a fundamental tension in the design of agents: for them to be useful they must read private data and, at the same time, decide with autonomy. Simon Willison described this as a "lethal trifect": private data reading, unreliable content ingestion and ability to send data out. OpenClaw has all three capabilities, and the attack vector can come from both a poorly formed file and a perfectly written mail by an attacker. This kind of risk transcends patches and requires changes in architecture and process.

The attack surface was also reflected in implementation errors reported by analysts: extensions for Slack, Discord, Matrix, Zalo and Teams resolved white lists by changing names rather than stable identifiers, allowing an attacker to be renamed to subplanted to an allowed account. OpenClaw has published arrangements for such cases, but the lesson is systemic: decisions on identity and trust must be based on unchanging and audibly verifiable identifiers.

Since the regulation, the impact has already come: the Dutch data protection authority (Autoriteit Persoonsgegevens) recommended not to run OpenClaw in systems containing sensitive data, due to leakage risks and account-taking. This statement stresses that the risk is not only technical but also legal and compliance; organizations must assess agents as points of possible data violation and controller responsibilities. For more information on regulatory frameworks and privacy, the website of the Authoriteit Persoonsgegevens can serve as an institutional reference https: / / autoriteitpersoonsgegevens.nl / en.

What should safety equipment and product managers do right now? First, apply published patches and mitigations(e.g. update 2026.4.23 of OpenClaw). Second, treat the agent as a junior employee with access to systems: impose policies as a code that the agent cannot exceed, require human confirmation for critical actions and record and thoroughly review any exit activity. Third, segmenting permissions per connector: an external mail channel should not involve free access to the CRM or secrets until the trust of the source is verified. Fourth, limit default memory and consider "ephemeral context" mechanisms to minimize persistent traces of malicious instructions. In addition, put out doors that prevent unauthorised shipments to unknown external addresses and apply network egress controls to block unapproved executable downloads.

Organizational controls are also needed: threat modeling policies for agents, specific training on social engineering directed against agents (not only against humans), audit reviews that correlate agent actions with human triggers, and SIEM / EDR detection rules that seek exfiltration patterns via integrations. The adoption of white lists based on immutable IDs and the separation of functions (principle of less privilege) reduce the risk of scale by renaming or supplanting.

Finally, there is a strategic reflection: the current corrections - unreliable metadata, validation of transmitters, capacity limitation - dampen concrete attacks, but do not resolve the contradiction of substance. A useful agent must rely to some extent on external inputs; any design that seeks maximum autonomy and maximum utility will be in tension with security and privacy objectives. The long-term response will be through models of confidence composed: policies forced by infrastructure, human goals for critical acts, and a "limited delegation" mentality in which the agent complements human work, does not replace it without supervision. For additional readings and practical guides on threats to agents and models, technical blogs of companies investigating these areas offer continuous analysis; it is recommended to follow specialized sources such as the security research publications of cyber security providers and consultants, for example the research sections of Imperva and Varonis https: / / www.imperva.com / blog / and https: / / www.varonis.com / blog /.

In short: to park and mitigate already, but above all to rethink how an agent is integrated into the perimeter of trust of the organization. Without architectural and operational changes, an innocent message or shared contact can become the gateway to compromise not only the agent, but the systems and data he manages.