AI agents and OpenClaw: what the agent is allowed to do

I run local AI in my home lab, so this one is close to home. A model that gives a wrong answer is one problem. A model that takes a wrong action with access to files, credentials, or a shell is a different one.

OpenClaw is a useful example because it makes agents with tools accessible. The security questions depend on how it's deployed and what authority it's given. I don't think it's fair to say every deployment has no security model.

Start with the boundary

OpenClaw's security documentation describes a trusted operator model. It doesn't present one shared gateway as an isolation boundary for mutually hostile users. Its documented controls include authentication, tool policies, sandboxing, and a security audit command.

If the agent runs with my credentials, anyone who can influence its actions may be able to influence what happens under my authority. Giving several people separate chat sessions doesn't necessarily give them separate operating-system permissions or separate access to connected services.

I'd check the installed version and configuration before saying anything about its defaults. A product name isn't enough to tell me which controls are active.

Treat retrieved material as data

An agent might read a web page, a ticket, a repository file, or a document as part of a legitimate request. That material can also carry instructions aimed at the agent.

For example, a document could tell it to send the contents of a local file somewhere else. The person who asked for a summary didn't authorize that. The document doesn't get to authorize it either.

The test is whether the system keeps that distinction once tools are available. A prompt can express the policy. It doesn't replace filesystem permissions, scoped credentials, or network controls.

Give the task a small set of tools

For an agent that summarizes logs, I'd start with access to a limited set of log files. It doesn't need my browser profile, my SSH directory, or a general-purpose credential for the whole environment.

For an agent that suggests changes, I'd rather have it prepare a patch and run tests in a disposable workspace. Applying that patch to a live system is a separate capability.

I also wouldn't rely on a list of banned shell words as a security boundary. A shell has too many ways to express the same action. Restrict the environment and the available operations instead of expecting a string filter to understand every command.

Make approvals specific

"Allow the agent to continue" tells me very little. A useful approval shows the actual destination, action, scope, and data involved. It should apply to that one action and not carry over to the rest of the session.

That means the recipient and content of an outbound message, the diff for a file change, and who gains access to what for a permission change.

What I would test in the lab

I'd give the agent dummy files and credentials, then plant conflicting instructions in the material it's supposed to read. I want to see the surrounding system deny the unauthorized action, and I want the log to hold enough context to explain the decision.

I'd also test recovery. Can I stop the process, revoke its credentials, and identify what it changed? Does a saved memory carry untrusted instructions into the next session?

Running a model locally changes where inference happens. It doesn't automatically restrict the tools connected to it. That's the part I want to get right before giving an agent more responsibility.

For a broader threat reference, see OWASP's prompt injection guidance.