Tools and security

Agents act on your project through tools. Every tool is confined to the task’s workspace and governed by a security policy you control from .vibe/config.toml.

The built-in tools

The web tools refuse to run unless security.allow_network = true. They are read-only tools, so read-only agents such as the researcher and the reviewers get them too.

Which tools an agent may use is decided per role (see Customising agents): the planner and the reviewers of the spec phase are read-only, the coder and the QA agents have everything.

Path containment

Every path an agent gives is resolved against the workspace root and must stay inside it:

• ../secrets, absolute paths and symbolic links that point outside are refused;
• a symbolic link whose target does not exist yet is refused as well, so a write can never create a file outside the workspace;
• writing tools additionally refuse to write through any symbolic link.

Paths listed in security.extra_read_paths may be read but never written. Nothing under a .git directory can be written by the file tools, whatever the path used to reach it.

The shell policy

The bash tool does not run a command before the security policy has approved it. The command line is parsed into segments (pipes, &&, ||, ;, &, subshells, bash -c "…", eval, find -exec, xargs) and every segment is checked. Anything the parser cannot understand is denied.

Always blocked

System, disk, privilege and network administration:

shutdown reboot halt poweroff init mkfs fdisk parted gdisk dd sudo su doas chown
iptables ip6tables nft ufw nmap systemctl service crontab mount umount
useradd userdel usermod groupadd groupdel passwd visudo

Program names computed at run time ($CMD, $(…), globs, brace expansion) are denied, and so are shells reading their program from standard input (echo x | sh).

Guarded commands

What you can configure

[security]
# Programs to block in addition to the built-in list.
blocked_commands = ["docker", "terraform"]

# If non-empty, ONLY these programs (and these wrappers, e.g. `nohup`) may run,
# plus harmless builtins: cd, echo, printf, true, false, pwd, test, [, exit, :.
allowed_commands = ["cargo", "git", "ls", "cat"]

# Default timeout of a shell command, in seconds (an agent may ask up to 600).
command_timeout_secs = 120

# Let agents use network clients (curl, wget, ssh, …).
allow_network = false

# Directories outside the project that agents may READ.
extra_read_paths = ["/usr/share/doc"]

When a command is denied, the agent receives the reason as a full sentence (“Command denied by the security policy: rm may not target /”) and can choose another approach.

Output limits

Tool output shown to the model is capped (30 000 characters for grep and bash, 100 000 for any tool). The full text of a truncated output is saved under .vibe/tool-output/<uuid>.txt and the path is given to the agent.

Hooks: your own rules

The policy above is static. For dynamic rules (“no npm publish on Fridays”, “log every command to Slack”, “ask me before touching migrations”) write a hook, either in Rust or as a plugin in any language; see Plugins and Extension points.

What the policy is not

It is a denylist and a set of validators, not a sandbox. An agent that can run python -c or node -e can, in principle, do anything the interpreter can. For untrusted code or strict environments, combine the policy with an isolated workspace, keep allow_network = false, and use the allowlist. The built-in container workspace runs every shell command in a hardened, throw-away container with no network by default; a VM or remote sandbox can be plugged in as a WorkspaceProvider plugin. The file tools still act on the host worktree, inside the path containment described above.