Skip to content

AI Technology

OpenClaw security: assess the trust boundary before connecting work data

A practical security review for agent tools, covering gateways, permissions, untrusted content, secrets and recovery before business use.

Published 2026-02-01 · Updated 9 October 2026 · 3 min read

Connected glass network nodes inside a transparent enclosure with an open gate.

Verify the project and version first

Pin down exactly what you’re evaluating before you install anything. The historical names in this URL are retained for existing links, but a current evaluation needs the exact project, repository, release and documentation you intend to use. Don’t install a package just because its name resembles one mentioned in an article or social post.

OpenClaw’s current security documentation describes one gateway as one trust boundary and advises separate gateways for adversarial users. For a business weighing shared use, that’s a material design consideration. Don’t assume that separate personas inside a shared agent establish a security boundary between unrelated users.

Inventory the authority you are granting

List every connected account, local directory, browser session and tool permission. Separate read access from the ability to change files, send messages or operate another system. For each permission, ask whether the task really requires it, and remove whatever it doesn’t before testing.

Use a dedicated test environment with approved material, and keep production credentials and candidate records out of the first experiment. A tool that can act inside a logged-in session may hold practical authority well beyond the words in the prompt, so assess the connected environment as well as the model. The same goes for any vendor’s product, FluxHire included; our page on how FluxHire handles security lists the questions and the evidence to ask for.

Treat retrieved material as data

Treat anything an agent reads as data, never as instructions. A document, web page or message may contain text telling the agent to change its instructions, so design the workflow so that such content cannot grant new permissions or authorise an external action. Ask the implementer to demonstrate the boundary using a harmless test document containing an instruction the agent should ignore.

Take a hypothetical recruitment research task: an agent is profiling a company ahead of a BD call, and the company’s page includes text asking the assistant to export its contact list. The correct behaviour is to treat that text as untrusted page content. A person should still approve any external action, and the application should enforce the allowed scope independently of the model’s response.

Examine secrets, logs and attachments

Find out where tokens, configuration, transcripts and downloaded files are stored, who can read them and how that access is revoked. Keep secrets out of prompts and broadly shared notes. Then ask how sensitive content is redacted from diagnostics without making investigation impossible.

Test with a marked, non-sensitive file so you can trace where copies end up. Look in the working directory, the logs, the exported output and the connected destination. And don’t describe the workflow as local-only unless the complete data path supports that statement, including inference and any tools it calls.

Plan cancellation and recovery

Decide who can stop an agent, and what stopping means for actions already queued or issued. Record external operation identifiers where they are available. Before you retry a failed task, reconcile whether a message was sent or a record changed. A timeout does not prove that nothing happened.

Test the separation with a hypothetical interrupted draft-and-send workflow, such as a candidate outreach message that stalls on its way out. The agent may prepare a draft, but a person should approve the final content and recipient before sending. If delivery status is uncertain, the operator should investigate rather than automatically repeat the action.

Make the adoption decision specific

Approve a bounded use rather than a general yes: named accounts, permitted tools, data categories and review requirements. Record the unresolved issues and the person responsible for each. Reassess after a release, plugin or permission change.

This article does not assert a vulnerability count, a breach rate or a guarantee that a configuration is secure. Use the current project documentation and an appropriate security review of the actual deployment. Recruitment data and consequential actions need controls that have been demonstrated, not inferred from an agent’s ability to get through a demo.

Sources and reading

Primary sources checked 9 October 2026. The practical evaluation steps in this article are editorial recommendations, not measured customer outcomes.

Continue Reading

View all articles