The gate reads the action, not the argument.

Most security tools hand you a report and walk away. You read it, you triage it, you forget it. The risk it found is still sitting there the next time your agent acts.

Dryx started as a configuration inspector — it maps what the AI agents on your Mac can reach. But a map you read once isn't where the danger lives. The danger lives at the moment your agent acts: installs the MCP server, writes the config, runs the command, reaches for the secret.

So Dryx moved to that moment. It compiles what it knows about your workspace into a fixed reference your agent takes its bearings from before every action, and stays silent on everything that's fine.

No dashboard to read. No alert to triage. Your agent already has the answer.

The honest answer most security tools won't give: the vast majority of what your agent does is fine, and a tool that interrupts you on the safe stuff trains you to turn it off.

So Dryx stays out of it. On an action that's authorized and in-bounds, the gate returns a silent allow: no prompt, no banner, no log line in your face. Your agent keeps working. You don't hear from Dryx at all.

It speaks only on a precomputed-dangerous action: a destructive command on a path it can't prove safe, an install that resolves to a typosquat, a write to a protected config. Known truth, surfaced at the one moment it matters, in your agent's own words.

That distinction is the whole design. Prompt injection works by talking the model into something. Dryx's verdict isn't a model — it's a lookup against a signed policy. There's no prompt to inject into a lookup. You can convince the agent; you cannot convince the answer.

So the realistic attack isn't “trick Dryx into allowing.” It's “get Dryx out of the way.” We treat the gate itself as something worth attacking, and we say so plainly.

Here's the honest ceiling. This is a defense that runs in your user space, against attacks that run in the same user space. A determined process that races us can make Dryx loudly visible rather than always armed. The same rule covers a machine that cannot run the check at all — a Mac with no developer tools installed, say: Dryx marks the gate unproven and shows you, instead of reporting a block that never happened. And it covers time: the signed policy carries a freshness window, and if no Dryx process is alive to re-stamp it — the app and its login item both gone for more than a day — the policy-dependent checks degrade to the destructive floor until Dryx is back. That degradation leaves a receipt in the ledger; it is not silent. We'd rather tell you that than sell you a tool that hides its own edges.

The gate doesn't weigh, infer, or interpret. It reads the action, looks up the verdict that was already computed, and returns it. Same action, same workspace, same answer — every single time. Nothing to talk it out of, nothing that drifts between runs, nothing that phones home to decide.

The reasoning happened earlier, on the slow path, when Dryx compiled the policy from your blast-radius graph. The hot path inherits that reasoning frozen — and the worst-case denials don't even wait for the policy: they're built into the gate itself. That split is what lets a deterministic verdict be instant, and what lets you treat “allow” as a fact you can build on, not a probability that might flip tomorrow.

It also gives you something no model-based gate can. When you override a verdict once, Dryx remembers exactly — and only — what you allowed. That permission is tied to the precise action and the exact state of your workspace. Change the workspace and the permission stops matching, so Dryx asks again, once, and tells you what changed.

The six shapes: a recursive force-delete — refused outright where the target resolves to a system or home location, while an unresolvable target (a variable, a substitution) becomes an operator question rather than a guess, and stays refused on harnesses that cannot ask; dd onto or off a raw disk device; formatting a filesystem (mkfs); the fork-bomb literal; an unquoted redirect onto a raw disk; and chmod -R 777 on the filesystem root. The only paths a recursive delete may target without a question are the four temp roots, and a payload handed to a shell — sh -c, a piped literal — is re-checked as the command it is. If a command matches none of these, the floor does not speak: that is the entire stop-set, which is also the honest answer to “what could this halt in my release pipeline at 2am?”

This is a claim you can check, not a claim you take on faith. The full enumeration — every pattern, the safe roots, the three rm tiers, the parse limits — is published at dryx.ai/floor.json, and a test in the gate suite and in CI compares that file element-for-element against the gate's own constants on every change. The gate itself is readable Python at ~/.dryx/dryx-gate.py on your machine. If the page and the gate ever disagree, that check fails before your trust does.

The honest edges, stated rather than hidden: the fork-bomb literal is refused even quoted or echoed — no sound downgrade exists; a command too large to parse that carries a candidate pattern keeps its block; and every floor decision writes a local receipt naming which shape fired and how the parse reached the verdict — so a wrong block is distinguishable and countable, not something you disarm the gate to get past. There is deliberately no override for the floor: the class with no escape hatch is the class that destroys data. Everything softer lives in the policy plane, where Observe and operator decisions apply.