Security Architecture

3-Layer Security Architecture

D.U.H.'s security model is defined in ADR-053 and ADR-054. The three layers are independent — each catches different classes of attack, and failing one layer does not bypass the others.

Layer 1 — Vulnerability Monitoring

D.U.H. ships a pluggable scanner framework with 13 scanners organized into three tiers. Tiers determine what runs by default vs. what requires explicit opt-in.

Scanner List (13 Scanners)

Minimal Tier (4 general + 5 D.U.H.-specific)

Extended Tier (4 scanners)

Layer 2 — Runtime Hardening

Runtime hardening (ADR-054) operates during session execution. It addresses LLM-specific attack vectors that static scanners cannot catch — particularly prompt injection and model-output manipulation.

Taint Propagation — UntrustedStr

UntrustedStr is a str subclass that tags every string entering the system with its origin and propagates that tag through all string operations. This is unique among open-source AI coding agents.

Origin tags:

• user_input — text typed by the user
• model_output — text returned by the LLM
• tool_output — output of tool calls (Bash, Read, etc.)
• file_content — file contents read from disk
• mcp_output — data from MCP servers
• network — WebFetch / WebSearch results

Propagation rules: Concatenating a tainted string with any other string produces a tainted string. Splitting, slicing, formatting — all propagate taint. The tag follows the data, not the variable.

from duh.security import UntrustedStr

# Tag a string as coming from model output
cmd = UntrustedStr("rm -rf /tmp/build", origin="model_output")

# Concatenation propagates taint
full_cmd = "sudo " + cmd        # still tainted (model_output)

# The Bash tool checks taint before executing
# A tainted string requires a confirmation token
bash_tool.call(full_cmd)   # → ConfirmationRequired unless token present

Confirmation Tokens

When a tainted string attempts to reach a dangerous tool (Bash, Write, Edit), D.U.H. generates an HMAC-bound confirmation token and presents it to the user. The token is tied to the exact command string — a modified command requires a new token.

Token properties:

• HMAC-SHA256 bound to the command string + session ID + timestamp
• Single-use — consuming a token invalidates it
• Short TTL — tokens expire after 60 seconds
• Non-transferable — a token for command A cannot be used for command B

This prevents a class of attacks where a model generates a dangerous command and then attempts to have the user confirm a different (benign) display of it.

Lethal Trifecta Check

The "lethal trifecta" is a capability combination that creates maximum risk for prompt injection attacks. D.U.H. detects sessions where all three conditions are simultaneously true:

# If your session needs all three capabilities, acknowledge explicitly
duh --i-understand-the-lethal-trifecta \
    -p "fetch the API docs and update our config"

# Without the flag, D.U.H. blocks when trifecta is detected
# and explains which capability combination triggered it

Layer 3 — OS Sandboxing

Shell commands and MCP stdio servers are wrapped by host OS sandbox primitives. This provides defense-in-depth: even if a model generates a malicious command and it passes confirmation, the OS sandbox limits blast radius.

macOS Seatbelt

On macOS, D.U.H. uses sandbox-exec with custom profiles to restrict shell commands and MCP servers. Profiles are generated per-session and limit:

• Filesystem access to the project directory and /tmp
• Network access to explicitly allowed domains
• Process spawning to a whitelist
• File descriptor inheritance

Linux Landlock

On Linux, D.U.H. uses Landlock LSM (since kernel 5.13) via syscall-level filesystem access control. The subprocess gets a restricted view of the filesystem without needing root privileges.

Approval Modes

CVE Defense Coverage

D.U.H. includes replay test fixtures for 4 published CVEs and architectural defenses for the entire 2024–2026 AI agent CVE corpus.

Additional Protections

• GlassWorm defense: NFKC normalization + rejection of zero-width, bidi override, tag block, and variation selector characters in MCP tool descriptions — prevents invisible prompt injection
• MCPoison defense: Hash-pinning of MCP tool descriptions at connection time; any server-side change triggers re-approval
• Per-hook filesystem namespacing: Each hook gets a private temporary directory; cross-hook file access is blocked at the OS level
• PEP 578 audit hook bridge: sys.addaudithook telemetry on open, subprocess.Popen, socket.connect, exec, import pickle — catches unexpected system calls at sub-500ns overhead
• Signed plugin manifests: TOFU (Trust On First Use) trust store with sigstore-ready verification and revocation list support
• Provider differential fuzzer: Hypothesis property tests verify all 5 provider adapters parse tool_use response blocks identically — prevents provider-specific parsing bugs that could bypass security checks

Security CLI Reference

# Initialize security policy (interactive wizard)
duh security init

# Initialize non-interactively (good for CI)
duh security init --non-interactive

# Install pre-push git hook
duh security init --install-hooks

# Run default scan (minimal tier)
duh security scan

# Run extended scan
duh security scan --tier extended

# Delta scan (only changed files since baseline)
duh security scan --baseline results.sarif

# SARIF output for GitHub Code Scanning
duh security scan --format sarif -o security-results.sarif

# Add an exception (with expiry)
duh security exception add \
    --scanner ruff-sec \
    --rule S603 \
    --reason "intentional subprocess in test fixture" \
    --expires 2026-06-01

# List exceptions
duh security exception list

# Check scanner health (are all tools installed?)
duh security doctor