What Dryx does
The map, the read before anything enters, the floor, the gate, the in-force sheet, and the record.
The map. What each agent and tool server can reach, per machine.
Your inventory already lists which agents and tool servers are installed. Dryx draws what each of them can reach from this machine, the keys, the folders, the servers and the outside world, built on the machine from the agents' own files, and counts the keys in reach, because a list of what is installed and a map of what it can touch are different things. The surface the sensor does not model, on one line per machine in the console you already run.
Sources. A community MCP server for GitLab that developers run locally held an access token any network client could take, GitHub advisory, June 22, 2026 · Ashish Pulivarthy in SC Media, The MCP server nobody inventoried, Nov 3, 2026 · Elastic, more than 300 distinct MCP servers across one fleet, Aug 11, 2026
Before anything new enters. The map, run on a tool server, package or skill before your agent reads it.
To your sensor a new tool server is a download and a file write like any other, and a hook meets it only once it is installed and running with the developer's access. When you or your agent asks, Dryx fetches the thing to a scratch space off your workspace, reads it there outside the agent's context with no AI model in the read, and says whether its publisher is one Dryx recognizes and, for what it can read, what it would reach on this machine. Your agent gets the verdict alone, never the untrusted text, so a hidden instruction in the package has no agent to hijack while it is being judged. Nothing is uploaded to a vendor, and once it is installed, the gate still decides before the agent acts.
Sources. Invariant Labs named tool poisoning, instructions hidden in a tool's description that the model reads and the user does not, April 1, 2025 · Trail of Bits, an MCP server can attack before any of its tools is invoked, April 21, 2025 · Postmark, a malicious npm package posing as its MCP server secretly blind-copied emails to an outside server, Sept 25, 2025 · A coding agent vendor's own advisory, a prompt injection could make the agent write a tool-server configuration file with no user approval, and the server it added ran the attacker's code on the developer's machine, CVE-2025-54135, Aug 2, 2025
The floor. A short published list of catastrophic actions, refused first.
Several products block at the agent's hook. Dryx's list is published, each entry judged by what the command would do to its target, like wiping a disk or deleting the home folder, and refused before any policy is read, so it holds with no policy, no account and no server, when the cloud is unreachable, and in the modes that skip prompts. The list is at dryx.ai/floor.json for anyone to read.
Sources. The Claude Code documentation on its bypass mode, "offers no protection against prompt injection or unintended actions," read Nov 5, 2026 · The same documentation on hooks, which "run before every tool call," read Nov 5, 2026 · York University researchers, an AI coding tool deleting project files or folders without authorization is 28.3 percent of developers' security complaints, July 2026
The gate. Your policy, enforced where the agent acts.
Coding agents ship their own hook, and several products enforce a policy at it. What Dryx brings to that checkpoint is its own code running the moment before a command, a file write or a tool call, a decision of refuse, hold or allow made on the machine in under a tenth of a second with no cloud, no account and no AI model in it, and a gate that fails closed with its gate file missing and puts the file back. The company writes its stop list once. Dryx compiles it with the machine's own map, holds it at the gate, and writes it into each AI agent's own rules as well, so the policy holds whether or not a vendor's settings ever reached that machine.
Sources. OpenAI, prompt injection is unlikely to ever be fully solved, Dec 22, 2025 · UK National Cyber Security Centre, additional safeguards beyond the model and the harness, Aug 20, 2026
In force. Whether your controls hold, per machine.
Your console shows a control was pushed. Dryx reads on each machine whether it reached the agent's session or was displaced on the way, a managed file shadowed by a profile, a hook a project file switched off, and reports which controls hold and which only look set, the security vendor's hook included, read by something that is none of the vendors. Counts and states, never content, into the platform and log system you already run, through your own collectors. No vendor grades its own control.
Sources. NIST SP 800-53, control CA-2(1), independent assessors who do not "assess their own work" · Craig Linton at Beazley, set clear boundaries for what systems can do, April 2026
The record. The decisions that mattered, in your own systems.
Your sensor's record begins when the process starts. Dryx's record is what came before, what the agent asked, what was decided and in which mode, one line per decision that names the kind of thing that happened and never the command, the path or the prompt. It lands in your own log system through a webhook you set up, beside the sensor's record of what the process did after, so you can hand an auditor or an insurer dated proof that a control was really on, without ever holding a developer's work. Together they are the whole timeline, and nothing goes to Dryx. The app does contact a few addresses, an update check and the connections you start, and the What leaves your machine page lists each one.
Sources. The EU AI Act, Article 12, asks high-risk AI systems to record their events automatically over their lifetime, from December 2, 2027 for the listed uses under the 2026 amendment · Craig Linton at Beazley, auditable decision-to-action trails, April 2026 · Elastic, we had no record of what it actually did, Aug 11, 2026 · Cloud Security Alliance, 94.1 percent of the AI-related alerts examined "were noise generated by legitimate developer and business use", Sept 14, 2026
What Dryx does, in eleven lines
The short list for when someone asks what Dryx does that the cloud security products do not, with their sensor watching what processes do and their hook asking the cloud for a verdict.
- It decides on the machine before the action runs, in under a tenth of a second, with no cloud in the decision.
- It decides from what the agent and its tool servers can actually reach on that machine, not from the words in the prompt, so source code and secrets never leave the machine.
- It refuses a short published set of catastrophic actions even with no policy, no account and no server, so it holds when the cloud is unreachable and in the modes that skip prompts.
- It enforces the company's own policy, on the machine, at the agent's checkpoint (right before it acts). The company writes its stop list once. Dryx compiles it with the machine's own map, holds it at the gate, and writes it into each harness's own rules as well, so the policy holds whether or not a vendor's settings ever reached that machine, and its refusals hold in the modes that skip prompts.
- It is the independent check across every vendor's own controls, the security vendor's hook included. Per machine, which controls the company set are present, managed, set to fail closed and actually firing. No vendor grades its own control.
- It shows where the company's policy stops holding by the vendors' own rules, and holds it there anyway. A managed file shadowed by a profile, a hook a project file switched off, a deny rule that never reaches a process the agent started, a hook with no fail flag that waves everything through when it crashes. Dryx's gate fails closed, puts itself back if removed, and holds the line below the agent at the operating system for what a process the agent started tries to do.
- It maps the surface the sensor does not model. Every agent and tool server on the machine, which sit outside what the company manages, which start unpinned or remote, which keys each one can reach, what runs unattended, what syncs to a cloud.
- It puts the keys out of the agent's reach and a boundary around each tool server, the same on every machine, and checks that both landed.
- It records what the agent asked, what was decided and in which mode, before the action, in the company's own log system beside the sensor's record of what the process did after. Together they are the whole timeline, and nothing goes to Dryx.
- It runs at sale time with nothing installed, through the console the company already uses, one line per machine, and that line is the day one baseline it measures drift against after install.
- Mac native (Linux and Windows planned with no date yet). Nothing as root, no kernel code, no content scan, measured per harness and per mode with the fail posture written down.
Keep the sensor. Add Dryx beside it.