Skip to content

Security

Jump to bottom
Vinh Nguyen edited this page Aug 5, 2026 · 1 revision

Security

VT Code implements a defense-in-depth security model for command execution, protecting against argument injection, workspace escape, prompt injection, and privilege escalation.

Security Layers

User / LLM Prompt
   │
   ▼
Layer 1: Command Allowlist       Only safe commands allowed
Layer 2: Argument Validation     Per-command flag allowlists
Layer 3: Workspace Isolation     Path normalization & traversal blocking
Layer 4: Dangerous Command Blocking
Layer 5: Sandbox Integration     (optional) Filesystem + network isolation
Layer 6: Human-in-the-Loop       3-tier approval system
   │
   ▼
Safe Execution

Layer 1: Command Allowlist

Only explicitly allowed commands execute by default: ls, cat, cp, head, printenv, pwd, rg, sed, which. All other commands are blocked by default.

Layer 2: Argument Validation

Each allowed command has a dedicated validator. rg blocks --pre/--pre-glob; sed blocks execution flags (e, E, f, F); ls only allows -1, -a, -l. Unknown flags are rejected.

Layer 3: Workspace Boundary

All paths must be within the workspace root. Symlinks are resolved and checked; ../ traversal and absolute paths outside the workspace are blocked.

Layer 4: Dangerous Command Blocking

  • Destructive: rm, rmdir, dd, shred
  • Privilege escalation: sudo, su, doas
  • System modification: chmod, chown, systemctl
  • Container/orchestration: docker, kubectl
  • Network (without sandbox): curl, wget, ssh
  • Task schedulers: crontab, at

VT Code uses its own scheduler for automation instead of raw shell scheduling.

Layer 5: Sandbox Integration

Network commands can require the Anthropic sandbox runtime: filesystem isolation within the workspace, network access control via domain allowlist, and prevention of system directory access.

Layer 6: Human-in-the-Loop

Three-tier approval for tool execution:

  • Approve Once — no persistence
  • Allow for Session — memory only
  • Always Allow — saved to policy (~/.config/vtcode/tool_policy.toml)

Tool Policies

[tools]
default_policy = "prompt"

[tools.policies]
exec_command = "prompt"
code_search = "allow"
apply_patch = "prompt"

Command-level allow/deny lists complement tool policies:

[commands]
allow_list = ["ls", "pwd", "cat", "git status", "cargo check"]
deny_list = ["rm -rf", "sudo rm", "shutdown"]

Dotfile Protection

VT Code guards sensitive dotfiles (~/.bashrc, ~/.ssh/..., etc.) by default:

  • Backups are created before any permitted modification (~/.vtcode/dotfile_backups)
  • Immutable audit logging of all access attempts (~/.vtcode/dotfile_audit.log)
  • Blocked during automated operations and requires explicit confirmation
  • Configurable via [dotfile_protection] (enabled, whitelist, blocked_operations, ...)

Provider Governance

providers_whitelist restricts which LLM providers VT Code may access, preventing accidental data leakage to unapproved endpoints in corporate or air-gapped environments:

providers_whitelist = ["opencode-zen", "opencode-go", "gemini"]

Threat Model — In Scope

  • Prompt injection — malicious prompts, embedded prompts in code comments/repo files/log output
  • Argument injection — execution flags (-exec, --pre, -e), path traversal, output redirection, command chaining
  • Workspace escape — absolute/symlink/parent-directory traversal
  • Privilege escalation — sudo/su/doas, SUID exploitation, system config modification

Security Best Practices

  1. Review ~/.config/vtcode/tool_policy.toml regularly
  2. Use "Approve Once" for unfamiliar operations
  3. Enable sandbox for network commands
  4. Monitor .vtcode/logs/ for suspicious activity
  5. Don't process code from untrusted sources

Security Advisories

Responsible disclosure makes everyone safer. See the Security Policy for reporting guidelines.

Related

Clone this wiki locally