Skip to content

Trust and security

Wallah runs the tools the model asks for with your own privileges, and there is no built-in authorization gate: bash, write, and edit are not sandboxed, prompted for, or confined to the working directory. Treat anything the model can reach (your files, your shell, the network via webfetch) as in scope for whatever it decides to do.

The one place you can intervene is the tool_call hook. It is the same mechanism the rtk example uses to rewrite a command, but a handler that raises an error rejects the call outright: the tool does not run and the model is told it failed. So you can veto specific calls, for example refusing to run a tool outside the project directory (see the hook's own page for that example in full).

This is a convenience for catching obvious mistakes, not a security boundary. Wallah does not guarantee anything stronger: a hook is your own code matching your own patterns, and a determined or unlucky command can slip past it. If you need real containment, run the agent in a suitably isolated environment (a container, VM, or throwaway account with only the access it actually needs) rather than relying on the hook to hold the line.