arf.io / ARF / Dev Environments / ARF — Autonomous Request Filter · Agent Router & Filter
ARF · Agent Relay Fence

Agents inside
a fence.
Not just policy.

The Agent Relay Fence isn't just about HTTP-layer governance. It's about building actual walls: jailed worktree access, OS-level isolation with platform-native sandboxing, and network policy enforcement via pfctl and iptables. Policy is what agents are allowed to do. Environments are what they're physically capable of doing.

Why Isolation Matters

Policy says no.
The kernel enforces it.

"Policy is advisory until the underlying system enforces it. An agent that bypasses your proxy, finds an alternative network path, or escalates privileges can ignore all your TOML rules. The Agent Relay Fence builds walls at the OS level because policy alone isn't enough."
LAYER 1 ARF POLICY
Declarative TOML rules · Circuit breakers · Approval gates
LAYER 2 WORKTREE JAIL
Git worktree hardening · chroot-style path restriction · No symlink escapes
LAYER 3 OS SANDBOX
macOS sandbox-exec · Linux unshare namespaces · Seccomp filters
LAYER 4 NETWORK POLICY
pfctl (macOS) · iptables/nftables (Linux) · Egress allowlist only
Agent is inside all four layers simultaneously
Worktree Jailing

The agent sees
only its workspace.

ARF creates isolated git worktrees for each agent session. The worktree is the agent's entire file system view it cannot navigate above the worktree root, follow symlinks out of the tree, or access files in the main working tree directly.

This is critical for parallel agents: COPPER-ANVIL-2 working on the auth module cannot read or modify the files that SILVER-HAWK-3 is editing in the API layer. Worktrees provide natural isolation between concurrent agent branches without OS-level overhead.

Worktree hardening includes: path traversal prevention, symlink resolution blocking, and write-protection for files outside the agent's assigned scope. ARF enforces these at the tool-call level the file read/write operations are intercepted by the proxy before they're executed.

  • Isolated git worktree per session
  • Path traversal prevention (no ../ escapes)
  • Symlink resolution blocked outside tree root
  • Per-agent scope: read-only regions configurable
# arf-env.toml worktree configuration [environment.worktree] # Create isolated worktree for each session isolate = true base_branch = "main" worktree_prefix = ".arf-work" # Path access control within worktree [environment.worktree.access] # Read-write access read_write = ["src/", "tests/"] # Read-only (agent can read but not modify) read_only = ["docs/", "*.md"] # Blocked entirely blocked = [".env", ".secrets/", "*.key"] # Auto-cleanup worktree after session seal cleanup_on_seal = true cleanup_on_failure = true
OS Sandboxing

Platform-native.
Kernel-enforced.

ARF uses the platform's native sandboxing mechanism. On macOS, it generates and applies a sandbox-exec profile scoped to the agent's worktree and the ARF proxy connection. On Linux, it uses unshare to create a new network namespace, mount namespace, and PID namespace for the agent process.

The sandbox profile is generated from your ARF environment configuration you write TOML, ARF generates the appropriate sandbox rules for your platform. The result: the agent process literally cannot make system calls outside its permitted set, regardless of what code it runs.

arf · sandbox · linux namespaces 
$ arf spawn --profile strict --session WOLF-1

ARF Creating isolated environment...

✓ Worktree: .arf-work/WOLF-1
✓ Namespaces:
    net (new · no external access)
    mnt (bind-mounted to worktree)
    pid (isolated process tree)
    user (mapped uid 100000+)
✓ Seccomp: allowlist applied (82 syscalls)
✓ Network:
    lo:   127.0.0.1  (loopback only)
    arf0: 10.64.0.1  (proxy tunnel)
    egress: blocked except ARF proxy
✓ Agent connected:
    ANTHROPIC_BASE_URL=http://10.64.0.1:4554
    All API traffic through ARF only

Environment ready. Session WOLF-1 active.
Network Policy

Egress by allowlist.
Everything else: blocked.

Egress Allowlist

Agents can only make outbound connections to explicitly listed hosts. All other egress is blocked at the firewall level not by ARF policy, but by pfctl or iptables rules generated by ARF and applied to the agent's network namespace.

Proxy-Only Mode

In the strictest configuration, the agent has no direct internet access at all. All outbound traffic must flow through the ARF proxy tunnel. ARF decides what gets forwarded. The agent can't route around the watchdog.

DNS Control

ARF can run a local DNS resolver for the agent namespace that resolves only allowlisted domains. Attempts to resolve blocked domains return NXDOMAIN. DNS-based exfiltration attempts are logged.

Remote Environments

ARF supports remote agent execution: the agent runs on a remote VM or container, connected to the local ARF instance via a secure tunnel. Governance, auditing, and TUI visibility all work identically for remote agents.

# arf-env.toml network policy [environment.network] # Egress allowlist agent can reach these and nothing else allowed_hosts = [ "127.0.0.1:4554", # ARF proxy (always allowed) "api.github.com", # GitHub API (for git ops) "registry.npmjs.org", # npm (for package installs) ] # Block all other egress via iptables/pfctl default_policy = "block" log_blocked = true # DNS: only resolve allowed domains dns_allowlist = true # Remote agent support [environment.remote] enabled = false # tunnel_endpoint = "wss://agent-vm.internal:4005" # auth_key = "vault:remote-agent-key"