AI coding agents need filesystem access, shell execution, and network calls to do their job. The default posture is auto-approve, because reviewing forty prompts an hour is not a workflow. The problem is that the thing approving actions is the same probabilistic model that a poisoned README or a clever prompt injection can steer.
Grith (launched August 28, 2026) is a security proxy that sits between the agent and the operating system. It intercepts syscalls, scores them against deterministic filters, and enforces a three-verdict policy: allow, queue for human review, or deny. No LLM in the enforcement path. Median scoring time is 0.02ms.
This is not a sandbox. It is a runtime supervisor that gates writes without blocking reads, and it runs on Linux using ptrace with a seccomp-BPF pre-filter.
Architecture: Interception Without Latency
Grith wraps the agent process and hooks into the kernel’s syscall interface. The flow:
- Pre-filter (seccomp-BPF): A kernel-side filter catches security-relevant syscalls (file access, process execution, network operations) before they reach userspace. Routine calls that match known-safe patterns pass through immediately.
- Scoring pipeline: Intercepted calls run through 18 filters in three phases:
- Static checks (path validation, permission boundaries)
- Pattern matching (1,618 secret patterns, egress policy, destructive-op detection)
- Contextual filters (taint tracking, multi-step exploit detection)
- Verdict injection: The proxy returns one of three verdicts to the syscall:
ALLOW(score under 3.0): syscall proceedsQUEUE(3.0 to 8.0): process freezes until human reviewsDENY(over 8.0):EPERMinjected into syscall return
The seccomp pre-filter is the key to keeping latency low. Most syscalls never hit the scoring pipeline. Only the ones that touch security boundaries (write operations, network egress, process spawns) get scored.
Permission Model: Read-Free, Write-Gated
The default policy allows agents to read freely but gates writes. This maps to the actual risk surface: an agent that reads your entire codebase is doing its job. An agent that writes to /etc/passwd or exfiltrates secrets is not.
Edge cases:
- File renames and symlinks: Treated as write operations. A rename from
safe.txtto/etc/cron.d/backdooris a write to/etc/cron.d/. - Append vs. overwrite: Both are writes. The scoring pipeline checks the target path, not the operation type.
- Temporary files: Agents often write to
/tmpfor intermediate state. Grith’s pre-built profiles for tools like Aider and Cline auto-allow writes to known temp directories.
The permission model is path-based, not capability-based. This is a trade-off: path-based rules are easier to reason about and audit, but they are vulnerable to TOCTOU (time-of-check-time-of-use) races. Grith mitigates this by re-checking paths at syscall time, not at policy evaluation time.
Audit Trail: Intent and Command History
Every intercepted syscall generates an audit log entry. The log captures:
- Command: The syscall name and arguments
- Score: The risk score and which filters triggered
- Verdict: Allow, queue, or deny
- Context: The agent’s current working directory, environment variables, and parent process tree
The missing piece is intent. The agent knows why it wants to write to a file, but the syscall does not. Grith does not solve this. The audit log shows what the agent tried to do, but not why. If you need intent, you have to instrument the agent itself (via tool-call logging or a wrapper around the LLM API).
Multi-Step Exploit Detection
An agent that tries to escalate privileges or chain commands is harder to catch than one that tries to write to /etc/passwd directly. Grith’s taint-tracking filter watches for multi-step patterns:
- Privilege escalation: If an agent writes a file, then spawns a process that reads that file with elevated permissions, the second syscall inherits the taint from the first.
- Command chaining: If an agent writes a shell script, then executes it, the execution inherits the taint from the write.
Taint tracking is stateful. The proxy maintains a map of file descriptors and their taint status across syscalls. This adds memory overhead (roughly 1KB per open file descriptor) but catches exploits that single-syscall filters miss.
The weakness: taint tracking only works within a single process tree. If an agent writes a file, then a separate process (started by a cron job or a user) reads it, the taint is lost.
Policy Updates and Session Continuity
Grith’s policy is a YAML file that lives in /etc/grith/policy.yaml. Updating the policy does not require restarting the proxy or the agent. The proxy watches the policy file with inotify and reloads it on change.
Active sessions continue under the old policy until the next syscall. This avoids a race where a policy update mid-syscall causes the proxy to score the same call twice with different rules.
The trade-off: if you push a policy update that tightens restrictions, agents that are already running may continue to operate under the old policy for seconds or minutes (depending on how often they make syscalls). If you need immediate enforcement, you have to restart the agent.
Deployment Shape
Grith runs as a single binary that wraps the agent process. The deployment options:
| Mode | Use Case | Overhead |
|---|---|---|
grith exec -- <cmd> | Wrap an existing agent (Aider, Cline, etc.) | 0.02ms per syscall |
grith run "<prompt>" | Built-in agent mode with OpenAI-compatible API | Same, plus LLM latency |
| Systemd service | Run Grith as a daemon that supervises all agents | Persistent process, same per-call overhead |
The systemd service mode is useful if you run multiple agents on the same machine. The proxy starts once, and all agent processes inherit the same policy and audit log.
Failure Modes
Bypass via direct syscalls: If an agent uses inline assembly or a language runtime that bypasses libc, the seccomp filter will not catch it. Grith assumes the agent is using standard syscall wrappers.
Policy drift: If the policy file is too permissive, the proxy becomes a logging layer with no enforcement. If it is too restrictive, the agent cannot do its job. Grith ships with pre-built profiles for common tools, but custom agents require custom policies.
Audit log growth: Every intercepted syscall writes to the audit log. On a busy agent, this can generate gigabytes per day. Grith does not rotate logs automatically. You need logrotate or equivalent.
Taint tracking memory: The taint map grows with the number of open file descriptors. An agent that opens thousands of files without closing them will exhaust memory. Grith does not enforce file descriptor limits.
Code Example: Wrapping an Agent
# Install Grith
curl -fsSL https://grith.ai/install | sh
# Wrap an existing agent (Aider in this case)
grith exec -- aider --model gpt-4 "refactor the auth module"
# Built-in agent mode with a local Ollama model
grith run --model ollama/codellama "fix the failing tests"
# Check the audit log
grith audit --last 100The grith exec command spawns the agent as a child process and attaches the ptrace supervisor. The grith run command is a built-in agent that routes prompts through an OpenAI-compatible API or local Ollama model, then executes tool calls through the same syscall interception pipeline.
Technical Verdict
Use Grith if:
- You run coding agents on Linux in environments where they touch production systems or sensitive data.
- You need a deterministic enforcement layer that does not depend on LLM reasoning.
- You want an audit trail of every filesystem write, process spawn, and network call the agent makes.
- You are willing to tune policies per agent and accept the operational overhead of log rotation and policy updates.
Avoid Grith if:
- You run agents on macOS or Windows (Linux x86_64 and arm64 only).
- Your agents use languages or runtimes that bypass standard syscall wrappers (inline assembly, custom syscall tables).
- You need intent capture (the “why” behind each action) in the audit log. Grith only logs the “what.”
- You cannot tolerate the 0.02ms per-syscall latency (though this is negligible for most coding workflows).
The gap Grith fills is between “let the agent do anything” and “lock it down completely.” It is not a sandbox. It is a runtime supervisor that enforces boundaries without breaking the agent’s ability to read, write, and execute code. The trade-off is operational complexity: you own the policy, the audit log, and the failure modes.