A sandboxed AI agent still needs to do useful work
We learned to test permitted work alongside security boundaries. A safe configuration is only useful when the agent can complete its intended tasks.
There is a frustrating point in an agent build where the restrictions look sensible, but the assistant cannot do the work you brought it in to do.
We reached that point while repairing our ecosystem. The agents needed to stay inside their approved work areas. They also needed to create files, perform calculations, retrieve project knowledge, and carry out approved public research.
The repair required two questions: what must remain blocked, and what must succeed?
Turn the agent job into an acceptance test
For a writing assistant, a useful test might be drafting and saving an article inside its workspace. For a research assistant, it might be finding a public primary source and reporting what that source supports.
Our local work checks included creating a small file, performing a calculation, and reading the saved bytes back. We checked the actual result rather than accepting “done” in the chat as proof.
This exposed a practical issue: a path that made sense on the host did not match the path available inside the sandbox. The task needed the correct workspace path, not more authority.
That is a useful troubleshooting habit. Before expanding access, check whether the agent is trying the wrong location, missing an allowed tool, or using an unsuitable workflow.
Inspect the boundary around the task
A successful file write tells you that one file write worked. It does not tell you where else the agent can write.
We inspected the running sandbox restrictions as well as the intended configuration. Folder mappings, tool permissions, network behavior, and elevated execution each needed attention. We were also careful not to describe a shared workspace as isolation between the projects inside it.
OpenClaw's documentation distinguishes sandboxing from tool policy and elevated execution. A sandbox does not restore a tool that policy denies, and elevated execution, which grants a route to run commands outside the sandbox, changes that boundary. Understanding those separate controls helps explain both unexpected blocks and unintended access. See the official sandboxing documentation (opens in a new tab).
Give research a defined route
For our approved research agents, we used existing web search and public-page fetching tools while retaining the restrictions on their execution containers. Both agents then completed real public-source research checks.
This worked for our tasks and configuration. It is not a universal recipe for every agent platform or network setup.
We also gave the agents a clear public-research rule: stop at logins, paywalls, denied access, and apparently confidential material. Do not use authenticated browser sessions or attempt bypasses.
That instruction helps define acceptable behavior. It is not a technical guarantee that every retrieved page is appropriate. A reachable URL can still contain accidentally exposed information, and page text can contain misleading instructions. Research results remain material to evaluate, not permission to take further action.
Test permission boundaries without touching private data
You do not need to attempt reading personal files to check a boundary. Use harmless sample files created for testing, and inspect the effective permissions.
For example, create an approved sample document and a separate, non-sensitive sample outside the permitted collection. Confirm that the intended retrieval tool can read the first and refuses the second. That result establishes the tested boundary for that tool; other access routes still need their own assessment. The principles behind this approach are covered in our guide Agent permissions: why least privilege matters.
Report what the evidence supports
“Passed these tasks under these restrictions on this date” is more useful than “fully secure.” It tells the next person what was checked and what may need retesting after a change.
A good agent setup lets useful work succeed within a clear boundary. Test both halves, and fix the narrow cause of failure before reaching for broader permissions.