Security & Firewall

UGENT has a multi-layer security architecture: injection firewall, tool security policy, rate limiting, and sandboxed execution.

Injection Firewall

A deterministic, hook-based security layer that enforces source-boundary separation: untrusted text may provide evidence but must never grant authority.

Configuration

The firewall is configured in firewall.toml (discovered like other config files):

[firewall]
enabled = true
strict_mode = false

[firewall.strict_mode_categories]
sink = "permissive"      # warn-only for bash/web_fetch
memory = "global"        # follow global strict_mode
mcp = "global"           # follow global strict_mode

[firewall.strict_mode_tools]
"memory_*" = "strict"    # always block suspicious memory writes

How It Works

Phase 1 — Input Sanitization:

• Strips ANSI/OSC terminal escape sequences (clipboard writes, title-set, hyperlinks)
• Classifies text provenance via a taint lattice: Trusted, Untrusted, Tainted

Phase 2 — Taint Propagation:

• Each tool's output is classified by trust level (web fetch, MCP, search → untrusted)
• Taint is monotonic per session — never downgrades
• Per-actor taint partitioning: one user's session flags can't affect another's

Phase 3 — Egress Control:

• Once injection is observed in a session, sensitive sink tools (shell, network) are constrained
• Observe-and-warn by default; blocks in strict mode
• Memory writes are quarantined — strict mode blocks poisoned writes

MCP Pinning

SHA-256 fingerprints of MCP tool definitions (name + description + parameter schema). If a definition changes ("rug-pull"), the tool is withheld until re-approved via /firewall approve.

Pin baselines persist to ~/.ugent/state/firewall_pins.json — they survive process restarts.

[firewall]
enable_mcp_pinning = true

Skills Firewall

Scans skill bodies for authority-grab attempts at load time:

[firewall]
block_malicious_skills = true  # default: refuse Critical findings at load

Disable Flag

ugent --disable-firewall

Warns loudly that a security layer is disabled. Use only for debugging.

Tool Security Policy

Workspace Boundaries

[security]
allow_outside_workspace = true     # allow file access outside workspace root
allow_sensitive_file_read = true   # allow reading .env, keys, etc.
enforce_gitignore_boundary = true  # respect .gitignore
allow_ignored_paths = false        # deny access to gitignored files

Bash Auto-Confirm

[security]
auto_confirm_bash = true           # auto-approve bash commands (review risk first)
bash_backend = "auto"              # system | wsl | auto

When auto_confirm_bash is disabled, every bash command requires user confirmation via the interaction dialog.

Rate Limiting

[security.tool_flood_control]
window_seconds = 10
default_max_calls = 10
overrides = { "web_search" = 3, "read_file" = 20, "bash" = 10 }

Config File Protection

The write_file and edit_file tools refuse to overwrite security-critical config files by basename:

• ugent.toml, firewall.toml, mcp.toml, routing.toml, cron.toml, firewall_pins.json

Reads are not restricted — the agent can read config and logs for debugging. Human editor edits are unaffected.

Sandboxed Execution

Role-based capability policies control what each worker agent can do:

Capability	Tools	Granted to
CommandExecution	bash, kill_shell	Master, Coder, Tester, Executor, Architect
file_read	read_file, search_files, find_files	All roles
file_write	write_file, edit_file	Master, Coder, Executor, Architect
AgentInteraction	ask_user_input, task_management, use_skill	Master, Planner, Coder, Tester, Executor, Architect
RuntimeControl	session_control, checkpoint_control, cron_management	Master only

SecurityGuard tasks are non-delegating and read-only — they cannot run shell commands, write files, delegate, or use runtime-control tools.