Endpoint security for AI agents

Your policy, enforced where the agent acts. No cloud or AI in the decision.

Dryx is the independent check across every AI vendor's own controls. It maps what each agent can reach on the machine, enforces your AI-agent policy at the gaps, and keeps a record of each decision in your own systems. Nothing goes to Dryx.

Installed through the device-management console you already own, beside the endpoint sensor (EDR) you already run. No new server and no cloud instance.

The problem

The people who buy, build and insure security say the gap is real, in their own words, with the dates.

AI agents now run on employees' machines with the employee's own access and their own tool servers (MCP servers), often in the modes that skip the permission prompt. The security stack was built to watch a process once it exists.

"Prompt injection, much like scams and social engineering on the web, is unlikely to ever be fully 'solved'."

OpenAI, on hardening its own agent, Dec 22, 2025. Source

"For applications where the consequences of failure are above tolerance, organisations should implement additional safeguards rather than relying solely on model-level or harness-level protections."

UK National Cyber Security Centre, Aug 20, 2026. Source

"You don't want to try to retrofit the ability to enforce security and responsible AI foundations after the fact." And "if you're going to rely on the model intrinsically to do the right thing, I think you're expecting too much of these frontier LLM companies."

Alex Balazs, Intuit's chief technology officer, in Fortune, Sept 16, 2026. Source

Agents misuse legitimate tools under prompt injection or ambiguous instructions, and tool definitions increasingly arrive through MCP servers.

OWASP Top 10 for Agentic Applications for 2026, Tool Misuse. Source

"We had no record of what it actually did." Across the fleet, more than 300 distinct MCP servers, 86 percent of them used by one or two people.

Elastic's information security team, on agents across more than 1,100 machines, Aug 11, 2026. Source

In an internal test, a hidden instruction in a GitHub issue convinced a coding agent to upload the company's credentials to a public repository. "EDR saw nothing." It was, in their words, a normal process making a normal network request.

Roblox security engineers, the abstract of their Black Hat USA 2026 briefing, published Jul 31, 2026. Source

"The organisations that win will set clear boundaries for what systems can do, keep auditable decision-to-action trails, and build controls that scale with change."

Craig Linton, Beazley, Spotlight on cyber threats and tech advances 2026, April 2026. Source

Unauthorized file operations are developers' top security complaint about AI coding tools, 43.1 percent of the security posts studied, and the largest part of that is the tool deleting project files or folders without authorization, 28.3 percent of the same posts.

York University researchers, a study of 1.1 million developer posts, July 2026. Source

Filtering the agent's intent, the words in the prompt, is surveillance on the employee, a liability for the company, and a leash on the productivity the agents were bought for. Dryx judges what the action would do on the machine instead, reads no prompt to decide, and lets the agent work.

The pain point

Three AI agent vendors. Three switches. One policy.

Each agent vendor ships its own controls. A security policy written for one tool reaches that tool alone, not the other two, and nobody can say, per machine, which switch is really in force. No agent can be left to check itself. One policy from one console is the right ask, and Dryx adds the part no vendor's own report gives you, an independent read of whether each switch really held on this machine, and a short published floor under all three that holds with no policy at all.

The blind spot

Four things the sensor was not built to see.

  • What each AI agent can reach, before it acts.
  • Whether your controls are in force, on this machine.
  • The command, before it runs.
  • A reach that moved this week.

Your sensor sees a process once it exists. Dryx sees the agent's command before it becomes one.

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.

  1. It decides on the machine before the action runs, in under a tenth of a second, with no cloud in the decision.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.

Why on the machine

The security net does not change when the AI models do.

AI agent vendors ship updates weekly and their models change. Your fence stays where it is, and Dryx keeps enforcing your policy.

Graceful to what you already run.

No new server. No cloud instance. Install through the console you own, and Dryx lands beside the EDR sensor and the platforms you already use. Your policy does not change. Dryx enforces it on the machine.

The same answer, every time.

The decision is made on the machine, with fixed rules. No AI model in the product. No black box to explain to a reviewer.

Reliable when the cloud is not.

Enterprises need the agent controlled at the moment of action on each machine, when no cloud can be reached and no AI model can be trusted to get it right. The floor holds when the policy, the server and the account are all gone.

What the sensor misses, Dryx adds.

  • The decision at the agent's own checkpoint, before the command becomes a process, with what the operating system's events do not carry, which agent asked and in which mode.
  • What the command would do to this machine, a delete aimed at the home folder refused and the same verb inside the project allowed, with no prompt, file content or tool output read to decide.
  • Whether each agent vendor's control really held on this machine, read the same way for all of them by something that is none of the vendors.

Keep the sensor. Add Dryx beside it.

How a company adopts it

Value on the first day, then the rings you already use.

  1. Discover. The inspection package runs one line per machine through your console, with nothing installed, and shows the gaps your sensor does not report, as counts.
  2. Trial. The floor and your policy on ten or so machines for a limited time, with a trial fee small enough to approve without a meeting.
  3. Prove. Record mode first, then Dryx on the rest of your machines through your normal rollout rings. The in-force sheet per machine, the record in your log system, the evidence pack for the auditor.
  4. Keep current. Dryx's knowledge of what each vendor's agents, tool servers and skills can reach is redrawn as the vendors ship and delivered through your own release rings. The app adds features over time. The security net does not change.

We show a company its gaps on one machine, free. The business follows.

Mac native (Linux and Windows planned with no date yet). In private early access today.

Who asks for it

Security buys. IT installs. The developer decides whether it stays. All three get to yes.

The security lead

Their own policy enforced, with proof from their own machines. Nothing to set up, the record in their systems, and the power to unplug.

IT and device management

Install through the console it owns. No new server, a rollout by ring, one line per machine and a drill-down.

The developer

Keeps the agents and the speed. Permissions that fit the work, a hold answered in the agent's own prompt, and the power to unplug.

The security operations center

The record in its own logs, one standard shape, content free. A decision log, not another alert stream.

The auditor and the insurer

Proof that a control was really on, per machine, dated. The evidence pack is generated from the record.

The regulated company

A uniform control with no cloud instance, and a record a reviewer can rerun.