Martins joined WhatsApp. Five minutes later, everyone was his manager.
How a helpful OpenClaw assistant turned a WhatsApp contact list into shared authority over Gmail and the host—and how to rebuild it with real trust boundaries.
Case file / Martins
Martins was not hacked. Martins was promoted.
I connected OpenClaw to WhatsApp, named the bot Martins, and gave it an instruction that sounded hospitable: if one of my contacts asks something, answer them. In ordinary human language this means, “Be helpful, but do not rummage through my private life or administer the server on behalf of whoever says hello.” In access-control language it means absolutely nothing.
Martins already had useful tools. It could reach Gmail. It could use the browser. It could run commands on the host. Then other WhatsApp contacts were admitted to the same tool-enabled agent. A contact asked Martins to look through my Gmail. Martins did not pause to consider the constitutional implications of delegated email search. It saw an authorised conversation, an available Gmail capability and a task that fit the words. Another request involved a command on the host. Martins, now apparently running a tiny consultancy from inside WhatsApp, obliged.
The tempting explanation is that the bot “went rogue”. That lets the architecture off far too lightly. The agent used the authority it had been given on behalf of a sender who had been allowed to steer it. OpenClaw’s own trust model is explicit: if several people can message the same tool-enabled agent, they can steer that agent within its granted permissions. Session separation can keep conversations apart, but it does not transform each contact into a different operating-system user or a different Gmail principal.
“Talk to my contacts” quietly became “accept operational requests from my contacts using my credentials.” Martins did not cross the boundary. I had painted the boundary on the floor in watercolour.
This is a classic confused-deputy problem with excellent conversational manners. The contact did not necessarily possess my Gmail token or a shell account. Martins possessed them and was willing to act. The bot became the deputy; WhatsApp supplied the request; my credentials supplied the authority. A friendly tone, a separate chat window and the name Martins supplied the false sense that somebody sensible must be in charge.
Scope
For people running OpenClaw through WhatsApp while the same agent can reach personal email, browser sessions, local files, or host commands.
Start with the situation, not the slogan
An incident rarely arrives with a neat label. It arrives as a forwarded screenshot, a worried telephone call, or a monitoring alert written by a machine with no sense of occasion. In this case “Martins joined WhatsApp. Five minutes later, everyone was his manager.” is the working heading, but the label is only a starting hypothesis. The useful work is to establish what happened, what can still happen, and which decision cannot safely wait.
Keep three clocks in view: the attacker’s opportunity, the business interruption, and the lifetime of the evidence. They do not run at the same speed. A hasty change may interrupt access but erase context; a perfect investigation conducted at geological pace may leave the organisation exposed. Good response is the slightly unglamorous art of making the next reversible decision with the best evidence currently available.
When several people can message one tool-enabled agent, they can steer the authority already granted to that agent. A WhatsApp sender allowlist controls admission to the conversation; it does not create a separate Gmail, browser, filesystem, or host permission boundary for each contact.
Composite scenario
How this usually reaches the desk
Imagine the report begins with this observation: “A contact asks Martins to inspect the owner’s Gmail and the agent proceeds without the owner approving that specific request.” A second check returns another clue: “A WhatsApp sender can cause shell commands, browser actions, file reads, or other privileged tools to run on the gateway or node host.” Neither fact alone tells the whole story. Together they justify a documented incident, a defined owner, and a deliberate containment decision. This is where a timeline beats a collection of heroic memories; memory is an excellent storyteller and a dreadful audit log.
This scenario combines common operational patterns; it is not presented as a report of one named incident.
What to look for
Begin with preserved, comparable evidence. One signal is rarely proof; use independent observations and a reliable timeline before declaring scope or intent.
A contact asks Martins to inspect the owner’s Gmail and the agent proceeds without the owner approving that specific request.
Record the exact time, source, identity, system and time zone. Compare it with a known-good baseline and with what the user or service owner expected. A surprising event is a lead, not a conviction.
A WhatsApp sender can cause shell commands, browser actions, file reads, or other privileged tools to run on the gateway or node host.
Look for the control-plane event that made the visible activity possible: a changed credential, permission, rule, route, token or trusted device. Persistence often looks administrative because, technically, it is.
Different contacts have separate conversations, yet all of those sessions reach the same agent credentials, workspace, tools, or host.
Correlate the report with independent telemetry before deciding scope. User testimony, identity logs, endpoint evidence and service audit records are strongest when they agree on sequence rather than merely on mood.
Trust boundary
The four permissions that became one very large permission
WhatsApp admission
dmPolicy, allowFrom, pairing and group rules decide who may reach an agent. They do not, by themselves, decide which Gmail messages that person may inspect or which host command they may cause.
Agent tool policy
The tools visible to the shared agent form its delegated authority. If Gmail, browser and execution tools are present, every admitted sender can potentially steer those capabilities unless a stronger control blocks the call.
Stored credentials
OAuth grants, browser profiles, API keys and local credentials normally belong to the runtime or agent, not to the WhatsApp contact asking the question. The requester borrows the agent’s identity rather than presenting their own.
Execution boundary
Host execution is not read-only because file-editing tools were disabled. A shell can read, write, delete, connect and launch other interpreters wherever the selected host and operating-system account permit.
A per-contact session is still valuable. It reduces accidental context mixing and keeps one contact’s conversation from casually appearing in another contact’s history. What it does not provide is per-contact host authorisation. The official documentation describes session keys as routing and context boundaries, not replacements for separate credentials, gateways, operating-system users or hosts.
Mentions are similar. Requiring @Martins in a group is good noise control. It is not an authorisation ceremony. A mention answers “should the bot wake up?”; an allowlist answers “may this sender talk to it?”; a tool policy answers “what may this agent do?”; a sandbox answers “where can the tool act?” The safest design makes all four answers explicit.
First hour
What to do when Martins has already been taking requests
- Stop new instructions.Disable WhatsApp DMs temporarily or reduce
allowFromto the owner. Disable groups. Denyexecand elevated execution. Do not ask the same public bot to repair itself while everyone can still give it suggestions. - Preserve the story.Copy the effective configuration, relevant session transcripts, gateway logs, approval records and WhatsApp timeline. Record the OpenClaw version, gateway host and time zone. Preserve before deleting conversations or “cleaning up” the machine.
- Separate words from actions.Models sometimes say they performed work that did not occur, and sometimes perform work with remarkably modest prose. Confirm each Gmail search, browser action, file read and command from tool-call records and provider or host evidence.
- Review Gmail as an identity incident.Identify the OAuth grant or browser session Martins used, review recent account and mailbox activity, revoke or replace the grant when appropriate, and examine messages, forwarding, filters, sent mail and security settings relevant to the observed requests.
- Review the host as a host.Account for commands, child processes, changed files, new scheduled work, downloaded material, network activity and accessed secrets. Rotate credentials after preserving the evidence needed to understand their exposure.
- Tell the contacts to stop testing.A real incident is a poor group game. Ask people to preserve what they sent and received, then use one named investigator and one trusted channel for further checks.
OpenClaw hardening
A safer job description for Martins
The decisive control is architectural: do not attach personal authority to an agent that accepts requests from people who do not share that authority. Keep the privileged personal assistant owner-only. If friends, family, customers or colleagues need a bot, give them a separate agent—and, for materially different trust, a separate Gateway, operating-system user or host—with dedicated credentials and deliberately boring tools.
The following is an illustrative baseline for a shared WhatsApp agent whose job is conversation, not Gmail archaeology or remote administration. Configuration names can change between OpenClaw releases, so compare it with the linked current documentation and inspect the effective policy before relying on it.
{
gateway: {
bind: "loopback",
auth: { mode: "token", token: "REPLACE_WITH_A_LONG_RANDOM_TOKEN" }
},
session: { dmScope: "per-channel-peer" },
channels: {
whatsapp: {
dmPolicy: "allowlist",
allowFrom: ["+OWNER_NUMBER", "+APPROVED_CONTACT"],
groupPolicy: "disabled",
configWrites: false
}
},
agents: {
list: [{
id: "martins-public",
workspace: "~/.openclaw/workspace-martins-public",
sandbox: { mode: "all", scope: "session", workspaceAccess: "none" },
tools: {
allow: ["whatsapp"],
deny: [
"exec", "process", "browser", "read", "write", "edit",
"apply_patch", "gateway", "cron", "nodes", "sessions_spawn"
]
}
}]
},
tools: {
exec: { mode: "deny" },
elevated: { enabled: false }
}
}Use a dedicated WhatsApp number. OpenClaw recommends it, and it makes sender policy, routing and incident response much clearer than borrowing the owner’s personal identity.
Allowlist exact senders. Use dmPolicy: "allowlist" with E.164 numbers. For groups, allowlist both the group and permitted senders, or disable groups. Never use "*" merely because typing phone numbers has become tedious.
Separate privileged and shared agents. Give each its own workspace, state, sessions and credentials. When users are not in the same trust boundary, use separate Gateways and preferably separate OS users, VMs or hosts.
Deny host execution by default. For a shared agent, set exec to deny and disable elevated mode. If a trusted operator genuinely needs commands, use an owner-only agent with allowlists and human approval on misses; avoid no-approval or “YOLO” modes.
Sandbox every shared session. Use mode: "all", an agent or session scope, and workspaceAccess: "none" unless the public job requires a narrow read-only directory. Do not mount home folders, credential stores or the Docker socket.
Keep personal Gmail elsewhere. A public agent should not inherit the owner’s browser profile or OAuth grants. If email is genuinely required, use a dedicated service account or mailbox, minimum scopes, limited data, and explicit approval for sensitive reads or sends.
Route approvals only to the owner. An approval prompt delivered to the person who requested the action is not a second factor; it is customer self-service for your incident report.
Turn off remote configuration changes. A messaging surface should not be able to widen its own channel or tool policy. Keep Gateway administration on a separate authenticated control path.
Run the security audit after every exposure change. Use openclaw security audit and openclaw security audit --deep, resolve critical findings, then inspect the effective sandbox and tool policy rather than trusting the intended configuration.
Test refusal. From a non-owner WhatsApp account, ask for Gmail, a host command, a local file, a browser session and a configuration change. Every request should fail for a technical reason recorded in logs, not because Martins happens to be feeling responsible that afternoon.
Recommended topology
Two Martinses are cheaper than one incident
The owner-only Martins may have carefully approved access to personal services and, where unavoidable, a constrained command path. It accepts requests only from the owner through a private account and keeps strong approval gates. The shared Martins uses a dedicated WhatsApp identity, a separate agent and preferably a separate Gateway or host. It can answer questions and send ordinary messages, but it has no personal Gmail, host shell, browser profile, password manager, private workspace or route to the privileged agent.
If information must cross the boundary, expose a narrow service built for that purpose: for example, a read-only calendar containing public availability, a curated knowledge base, or a specific business mailbox. Do not solve information sharing by placing the owner’s entire digital life behind a conversational “please be sensible” sign.
Martins can remain charming. He can tell jokes, answer family questions, confirm that the office is closed and perhaps remind somebody about a birthday. He simply should not become the person who reads your mail and administers your server because a cousin discovered verbs.
Working examples
Run it, read it, decide what changes
These examples use documentation addresses, test identities and bounded targets. Replace placeholders only inside systems you own or are explicitly authorised to operate. Read the expected result and next action before running the command; a successful command is evidence, not yet a conclusion.
Create a UTC evidence note and hash
- Prerequisites
- A directory that only the responder can write to.
mkdir -p incident-evidence
date -u +"%Y-%m-%dT%H:%M:%SZ" | tee incident-evidence/collection-time.txt
sha256sum suspicious-file 2>/dev/null | tee incident-evidence/file.sha256The note contains an absolute UTC time and the hash line contains 64 hexadecimal characters plus the filename.
The hash identifies the collected bytes; it does not say whether they are malicious. A changed hash means the file changed or a different file was collected.
Make the evidence directory read-only, record who collected it, and work on a copy. On macOS use `shasum -a 256` if `sha256sum` is unavailable.
Inventory environment-variable names without exposing values
- Prerequisites
- Run only on a system you are authorised to inspect.
env | cut -d= -f1 | sort | grep -Ei 'TOKEN|SECRET|KEY|PASSWORD|CREDENTIAL'Potential secret-bearing variable names appear without their values.
Names are hints; secrets may also live in files, keychains, CI variables or process arguments. Avoid commands that print values into terminals or tickets.
Map each credential to an owner, provider, permissions and rotation procedure; revoke suspected exposures before cleanup.
Capture processes, listeners and sessions
- Prerequisites
- Root or sudo access and a protected output directory.
sudo sh -c 'date -u; ps auxww; ss -plantu; who -a; last -Fai | head -100' > incident-evidence/live-state.txt
sha256sum incident-evidence/live-state.txtOne text file records collection time, processes, sockets and recent sessions, followed by its hash.
The snapshot is volatile and incomplete. Rootkits can lie to local tools, while containers and namespaces can hide additional processes.
Preserve relevant journals and cloud/EDR telemetry, then compare unknown processes with packages, executable hashes and service definitions.
What to do
Read the whole sequence before starting. Several workstreams may run in parallel, but their evidence, authority and expected outcomes still need to be explicit. Every step below points back to a concrete example; use the example as implementation evidence, not as permission to operate outside the stated scope.
Operational judgement
Containment and recovery are different verbs. Containment limits the next harmful action; recovery returns a service to trustworthy operation. Between them sits eradication: removing the access path and persistence that would make the freshly restored service merely a cleaner target. For OpenClaw, WhatsApp and Agent security, keep those decisions separate in the timeline even if a small team performs them minutes apart.
Communication is also a control. Tell affected people what is known, what remains uncertain, what they must do and when the next update will arrive. Avoid both melodrama and false reassurance. “We are investigating” is useful only when followed by an owner and a time. The goal is to reduce secondary harm without teaching a possible attacker exactly what the team has discovered.
Handover
Make the result useful to the next person
Maintain two views of the incident. The working timeline should contain detailed events, evidence locations, hypotheses and technical actions. The stakeholder update should contain confirmed impact, current containment, material uncertainty, decisions required and the next reporting time. Do not copy speculative indicators into executive statements. Equally, do not polish away uncertainty merely because it looks untidy. Both records should use absolute times with a declared time zone and should identify the source of each important fact.
At shift change, hand over the current scope, trusted administration path, preservation status, active controls, failed actions, business priorities and the next three decisions. Read back the most consequential assumptions. For this case, ensure the record begins with “Disable inbound access or restrict WhatsApp to the owner while preserving the relevant OpenClaw configuration, session transcripts, gateway logs, approval records, and message timeline.” and does not finish until the team has addressed “Test the negative cases with a non-owner account: Gmail access must fail, host execution must fail, privileged browser sessions must be absent, and approval prompts must reach only the owner.” A concise, accurate handover prevents the incoming team from repeating disruptive work or mistaking a quiet telemetry gap for successful containment.
Validate before you close
Close the incident only when historical actions are accounted for, affected credentials are replaced, the privileged agent is owner-only, the shared agent has no route to personal Gmail or host execution, and unauthorised requests fail in a recorded test.
Capture the test, the expected result and the observed result. Where a person or business owner must accept restored service, name them in the record. A green dashboard can confirm that a component is answering; it cannot confirm that invoices, identities or restored data are trustworthy.
Finish with a compact closure note: the original trigger, confirmed scope, evidence retained, controls changed, tests passed, known gaps, residual risk, and the people responsible for the remaining work. Schedule a review while the timeline is still fresh enough to challenge. The purpose is not to find a person to blame; computers already perform blame with admirable efficiency. The purpose is to make the next response faster, safer and less dependent on one person remembering where the useful log was hidden.
Common mistakes
- Resetting systems before preserving volatile evidence and audit logs.
- Treating the first visible symptom as the complete scope of the incident.
- Restoring service without verifying that the attacker’s access path is closed.
These errors usually come from haste, unclear ownership or misplaced confidence. Build the safeguard into the runbook: a required evidence field, a second-person review, a rollback test or a specific exit criterion.
Questions people ask when the clock is running
Does one suspicious event prove compromise?
No. Treat “A contact asks Martins to inspect the owner’s Gmail and the agent proceeds without the owner approving that specific request.” as a reason to investigate and preserve evidence. Confidence should rise when independent identity, service, endpoint or network records support the same sequence.
Should we reset everything immediately?
Reset or revoke what the evidence and risk justify, but preserve the state you will need to understand the incident. Broad, undocumented resets can interrupt the attacker, the business and the investigation in one impressively efficient stroke.
When can the incident be closed?
Close the incident only when historical actions are accounted for, affected credentials are replaced, the privileged agent is owner-only, the shared agent has no route to personal Gmail or host execution, and unauthorised requests fail in a recorded test. Closure also requires named owners for residual risk and follow-up work; “it seems quiet now” is an observation, not an exit criterion.
Safety boundary
Use these steps only on systems you own or are explicitly authorised to assess. Preserve evidence, follow your organisation’s legal and regulatory obligations, and prefer reversible actions when the situation is not yet understood.
Primary references
- Security and trust modelOpenClaw
- WhatsApp channel access controlOpenClaw
- Exec approvalsOpenClaw
- SandboxingOpenClaw
- Multi-agent routingOpenClaw
- Gateway exposure runbookOpenClaw
- SP 800-61 Rev. 3: Incident Response Recommendations and ConsiderationsNIST
Editorial status: first edition. Review the linked vendor documentation for product- and version-specific changes before acting.