fak

README

fak — the agent kernel

Treat the model like an untrusted program, and the tool call like a syscall. That one move is the whole idea. Everything an agent does to the outside world — call a tool, admit a result into its memory, reuse a cached answer — becomes a syscall that passes through a kernel the model doesn't control. From the security seat that kernel is a permission gate the agent can't talk its way past. From the performance seat it's a way to do the shared work once instead of every turn. The surprise of this project is that those turn out to be the same gate — and that owning that boundary lets you do things no production agent stack does today.

fak is not a faster model server. SOTA engines (vLLM, SGLang, llama.cpp) already win raw throughput and prefix-cache reuse, and fak doesn't try to beat them at it. It owns the questions they don't: which effects are allowed, which results may enter memory, when reuse is still legal, and what survives a session boundary.

_{▶ the headline benchmarks as a ~40-second reveal — full-resolution MP4 · stills below}

---

fak by the benchmarks — receipts in a lab-release grammar

Four headline visuals, in the visual grammar a frontier lab ships a model card in. Each is generated from one source-of-truth data file, every figure traced to its commit — and honest by construction (a [NAIVE] number is fenced, competitor cells never carry a fabricated figure, and the single-stream throughput fak doesn't target is shown, not hidden). → The full benchmark gallery · every number, traced to its commit + artifact ⭐

1 · The headline — fak spans the whole boundary; the serving stacks span one band. Its cache is addressable (it reaches into the middle of a kept run); theirs is front-prefix only. fak carries a value in every row — an em-dash is a capability the stack doesn't ship, not a measured zero.

2 · The mechanism — re-prefill cost is linear; fak's resident, addressable KV is not. Three lenses: a structural per-cold-miss tax, a measured 9.7× WebVoyager elimination, and the conservative 4.1× vs a tuned warm-cache SOTA stack.

3 · The receipts — three pillars + an honest single-stream fence, on one card. Serving efficiency, correctness (the reuse is bit-exact), and a security kernel — with the [SOTA-style] 4.1× and the greyed [NAIVE] 139.3× marked so neither can be misread.

4 · The sweep — eight axes, fak (green) vs one honest reference each. The final panel is the fence fak does not target, inverted to the SOTA leader.

---

Two flips that are bigger than they sound

1. The permission policy runs inside the kernel. Most agent safety bolts a recognizer onto the outside of the loop — a pre-tool hook, a sidecar, a second model asked "is this safe?". Two weaknesses: the model can argue its way past a recognizer (prompt injection is exactly that), and when the outside thing crashes or times out the call usually runs anyway — fail-open, precisely when you're under attack. fak puts the check on the same call path as the tool call — one address space, no IPC, default-deny — so the gate isn't something the agent talks to, it's something its call passes through, like read() through the OS kernel. Refusing an irreversible action doesn't depend on catching the attack; it depends on the lever never having been wired up. For thirty years "more security" meant more checks to recognize bad things — a game attackers win. The flip is to stop recognizing and start not building the lever. → Policy in the kernel

2. The cache becomes addressable — past what any shipped engine offers. As a model reads, it builds a scratchpad of the work-so-far (the KV cache) so it doesn't re-read from scratch each turn. Every way production reuses that scratchpad today — vLLM, SGLang, the OpenAI / Anthropic prompt caches — only reuses it from the front: keep the run from the very first word, and the moment anything changes in the middle, everything after that point is thrown away and recomputed. That's most of the speed, and it's commoditized. What no shipped engine offers is the other direction: reach into the middle of a kept run, cut one span — a poisoned tool result, an expired secret — and leave the scratchpad bit-for-bit identical to a run that never saw it (checked against the reference at max|Δ| = 0, i.e. not one number differs). fak can, because it owns that scratchpad as a kernel object instead of renting it from a serving engine. That turns the cache from a speed structure into one policy can address: evict a span because a verdict said so, not because memory got tight — and prove it's gone. → Addressable KV cache

---

The tension these resolve

For most of computing history, every optimization came with a tax: a faster cache opened a coherence hole, a clever reuse trick added arcane state nobody else understood — speed and safety pulled opposite ways. fak's bet is that for agents they converge, because the safety boundary and the reuse boundary are the same boundary. One write-time gate decides whether a tool result may enter context (a security act) and pages its heavy bytes out to a content-addressed store (an optimization act). One read of the code calls it injection containment; the other calls it working-set paging — same code. The correctness metadata is the performance metadata.

That's a claim about fak's object model shown by example, not a proven law — and it has an edge: the convergence doesn't hold on raw GPU throughput (fak pays for its bit-exact guarantee in memory), and it's a reuse win only for read-heavy fleets.

---

See it in 2 minutes (no key, no model, no GPU)

Just Go 1.26+. Or run it in a hosted notebook — free T4 GPU, nothing to install: (see notebooks/).

go run ./cmd/fak preflight --policy examples/customer-support-readonly-policy.json --tool refund_payment --args "{}"
go run ./cmd/fak preflight --policy examples/customer-support-readonly-policy.json --tool search_kb --args "{}"
go run ./cmd/fak agent --offline

refund_payment returns DENY (POLICY_BLOCK) — refused with a named reason. search_kb returns ALLOW. Then agent --offline runs the same task twice — tools wired directly vs. behind fak — and prints the before/after:

metric                       without fak   with fak
model turns                            9          7
injection in context                 YES         no
destructive op executed              YES         no
task completed (booked)              YES        YES

Both finish the task, but with fak the booby-trapped instruction never reaches the model and the dangerous action never runs. Full walkthrough: docs/repro-packet.md.

---

Why this matters now

An agent system's cost isn't one number — it's roughly agents × turns × working-set × reread-rate × legality checks, and the naive stack lets all five multiply. The waste isn't that the model is dumb; it's that the system keeps making it reread the same setup (five agents over fifty turns is 250 chances to reprocess the same shared prompt). You feel it as a cliff: a long conversation gets slower per turn because each turn reprocesses a longer history, and a single turn at long context is risky enough that whole workflows are built around not taking one. The frontier is full of these walls — KV residency, invalidation storms, tool-rate limits, approval queues.

fak attacks the one safe term, reread-rate, without deleting the proof reuse is still legal. We measure against the best already-shipped setup, not a strawman: on a 50-turn × 5-agent run that's ~4× vs a tuned warm-cache stack — the honest few-fold against state-of-the-art reuse. (Against the naive pattern that re-sends the whole growing context every turn it's ~60×, but beating naive is easy and we don't lead with it.) The counter-intuitive part: the first worker pays, everyone after reads for free, so more agents can mean less total work. Two fences: the reuse win is self-host only (an app that just calls a frontier API gets the safety floor, not the savings), and the frontier-scale "agent city" numbers are design targets, not measurements.

The benchmarks — the whole boundary, not one number. fak isn't a single-axis speedup; the breadth is the point. A capabilities sweep across the three pillars it spans — serving efficiency (it does the SOTA stack's reuse), correctness (that reuse is bit-exact — the thing no serving engine proves), and a security kernel (the default-deny gate, at syscall speed — the boundary they don't own) — with the single-stream throughput it doesn't target shown honestly below the line. The 4.1× is marked [SOTA-style], not a green win (its baseline is fak's own kernel held constant, so it isolates reuse); the seductive 139.3× is greyed and tagged [NAIVE] so it can't read as a SOTA result. Every number carries its commit and traces to the authority doc.

The breadth card, the capability matrix, and the per-benchmark sweep are at the top of this README; the full set lives in the benchmark gallery.

→ Every number, traced to its commit + artifact ⭐

And it's not one lucky box. The same pure-Go kernel — same bit-exact gates — is profiled across 4 distinct hardware platforms: Apple M3 Pro (Metal + arm64 NEON), AMD Ryzen 9 + Radeon RX 7600 (Vulkan), Intel + NVIDIA RTX 4070 (CUDA Ada), and an 8× A100 serving node (CUDA Ampere) — spanning 2 CPU ISAs, 4 GPU backends, and 4 operating systems. The deterministic results reproduce byte-for-byte across all of them. → The hardware matrix

Web agent workloads: the turn-tax is structural ✅

For web/browser agent benchmarks — WebVoyager, BrowseComp, Browser Agent Benchmark — the same story plays out at a different scale. Every navigation action re-prefills the entire browser context (DOM state, tool schemas, task history). That's 2K+ tokens per turn, times ~12 turns per task, times 586 tasks for WebVoyager.

Measured on real WebVoyager (643 tasks):

Workers	Naive Re-Prefill	fak Fused	Net Elimination
1	170.9 M tokens	19.4 M tokens	8.8×
8	1.37 G tokens	141.3 M tokens	9.7×

The same elimination, generalized into three lenses — re-prefill cost climbs ~linearly with context, fleet, and turns while fak's resident, addressable KV stays flat (the middle panel is the measured WebVoyager 9.7× above):

The turn-tax (re-prefill vs KV persistence) is worker-independent — every agent pays it, every turn, regardless of fleet size. SOTA agents like Alumnium (98.5% WebVoyager success) achieve the same capability through fak at ~9× less prefill cost (measured). → Frontier WebBench baselines ·

---

Security: the lock, not the screener

The capability gate refuses an irreversible action by structure — the tool was never allow-listed, so no amount of context changes the answer. A separate quarantine holds suspicious tool results out of the model's memory entirely. The detector that flags those results is the evadable part, and we say so: it's ≈100% evadable by design — a helpful bonus, never the floor. The floor is the lock (the lever doesn't exist) and the containment (the bytes never reach the model). An attacker has to beat two independent gates, not fool one classifier.

Same task — book the cheapest SFO→JFK flight after reading a booby-trapped refund policy — run twice, unmediated vs. behind fak:

model	booked?	trap reached the model?
gemini-2.5-flash (strong)	✓ → ✓	YES → no
gemini-2.5-flash-lite (weak)	✗ → ✓	YES → no
Qwen2.5-1.5B (local, CPU)	✓ → ✓	YES → no

The weak model is the case that matters: without fak it fell for the trap and booked nothing; with fak it ignored the trap and booked the flight. Across these runs the injection reached the unprotected baseline 5/5 and fak walled it off 5/5.

---

How far do you want to take it?

Every rung is useful on its own — you get value even if you never buy the whole thesis.

• Front your existing model. fak serve puts the gate in front of any OpenAI-compatible server (Ollama, vLLM, a cloud provider). Keep your model and your stack; gain a reviewable allow-list, result quarantine, and an audit trail. This is where most people should start, and it's a complete product by itself.
• Run the kernel offline. Author a policy, check a tool call, measure the adjudication boundary — no model, no network. (The 2-minute demo above.)
• Go all in: the fused kernel. For the believers — run the model inside the kernel's address space, so the KV cache is a kernel object and the context-MMU and vDSO become real operations on attention state. This is where the two flips stop being framing and become mechanism: quarantine that reaches attention, prefix reuse the kernel owns, a finished session that reloads as a core dump. It's a correctness reference, not a production serving engine — but on a model that fits the GPU, the in-kernel CUDA decode already hits parity with llama.cpp Q8_0 (~120 tok/s on an RTX 4070) with an opt-in CUDA graph. Capability is still your model's job; the kernel gives you frontier-grade safety and ~$0 cost on a small local model today.

→ Guided tutorial (zero to first adjudicated call, real output at every step) · Getting started

---

What's real, what's not (we keep score)

fak is built to survive a skeptic reading the code. Every capability in fak/CLAIMS.md carries one machine-checked tag. The short version: the permission gate, the local-answer shortcut, the auto-repair ladder, the quarantine, the in-kernel model (math proven exact against a reference), and the OpenAI-compatible gateway are shipped and on the critical path, each closed by a test. The power/energy numbers are simulated (no power meter on the box). Sharing one KV pool with a separate serving engine is a labeled stub. And a 29-claim prior-art audit scored 0/29 novel — every primitive is established; the contribution is the assembly, putting them together as one in-process gate where the tool call is the checkpoint.

---

Install

One static binary — no clone, no Go toolchain. Full guide: Getting started.

curl -fsSL https://raw.githubusercontent.com/anthony-chaudhary/fak/main/install.sh | sh

Or grab a prebuilt archive (linux_amd64, darwin_amd64, darwin_arm64, windows_amd64), or run it in a container. Then:

fak policy --dump > floor.json   # a starter allow-list you can edit + review
fak serve --addr 127.0.0.1:8080 --base-url http://localhost:11434/v1 --model qwen2.5:1.5b

Install with Go (needs Go 1.26+): the module is the repo root, so go install github.com/anthony-chaudhary/fak/cmd/fak@latest drops fak onto your $(go env GOBIN) ($GOPATH/bin). Or from a clone: go build -o fak ./cmd/fak. Full install matrix: INSTALL.md.

---

Go deeper

If you want…	Read
The two flips, from first principles	Policy in the kernel · Addressable KV cache
Every benchmark number (single source of truth, traced to commit + artifact)	fak/BENCHMARK-AUTHORITY.md ⭐
Every machine fak runs on (the hardware matrix — 4 platforms, 2 CPU ISAs, 4 GPU backends, 4 OSes)	docs/HARDWARE-MATRIX.md
Web agent benchmark results (real WebVoyager: 8.8-9.7× measured)	docs/webbench-baselines.md
The parable, personas, and when-the-win-kicks-in tables	docs/concepts-and-story.md
What "tuned SOTA" means (the 10 optimizations fak sits on top of)	docs/explainers/sota-optimizations.md
Shipped capabilities (runnable artifacts, claim tags)	fak/CLAIMS.md, fak/STATUS.md
Policy / permissions	fak/POLICY.md
Architecture (the registry seams, the frozen ABI)	fak/ARCHITECTURE.md
Build your optimization on fak (researchers/teams: plug in → prove correct → prove faster → ship)	fak/EXTENDING.md
First run, step by step (guided session, real output at every step)	docs/fak/tutorial.md ⭐
Quick answers (what is fak, how it differs from a firewall / guardrails / vLLM, the threat model)	docs/FAQ.md
A machine-readable map (for LLMs & answer engines)	llms.txt
New here?	START-HERE.md · Simple demo

---

About this repository

This repository is the canonical public home of the project's public content — it is edited directly here, not regenerated from a private mirror. A separate private repo holds only the operator-specific material that must never be published (machine names, IPs, lab hosts, internal paths).

Cite this work: machine-readable metadata is in CITATION.cff (GitHub renders a "Cite this repository" button from it).

License: Apache-2.0.

_{Topics: agent kernel · agent tool firewall · AI agent security · prompt injection defense · tool poisoning · capability security · default-deny permission gate · KV cache · addressable KV cache · LLM inference · LLM serving · self-hosted LLM · agentic AI · MCP tool security · Go.}