Skip to content
Endpoint AI Finder

DEVICE NOTE · 2026-10-12

Bay in context: AI agent security that decides on each action

This note sets out what its pages describe, where it fits and where it does not.

Short answer

Bay's public pages describe an on-device control for AI agents, coding assistants and MCP servers that decides Allow, Ask or Deny on each action before it runs, using identity, prior actions and data accessed, and rolls out through the EDR or MDM you already run with no new agent. It publishes no pricing.

By The Device Desk · Endpoint AI Finder · Published 2026-10-12 · 3 min read

Desk research from public vendor pages read on 27 September and 11 October 2026. Profiles follow our published method; we did not run the products.

What do Bay's pages describe?

Bay calls itself a fully preventive, agentless platform for AI agents and tools on enterprise endpoints. Bay states it covers AI agents wherever they work: endpoints, cloud workloads, cloud endpoints, browser and SaaS. Bay names its products Wave, Bay Enforcer, Bay Cloud and Lighthouse. Its pages describe three layers: an inventory of AI agents, MCP servers, tools, credentials, extensions, settings and endpoint deployments; activity monitoring that records who triggered an action, whether a human was involved, and the chain from prompt to system action; and enforcement that returns Allow, Ask or Deny.

The enforcement detail comes from Bay's August 2026 research post. It says Bay Enforcer evaluates prompts, pre-tool calls and post-tool responses and returns Allow, Ask or Deny locally, which it states takes under 4ms, on supported agent surfaces. Capability rules cover shell and code execution, process spawning, package installation, cloud CLIs, containers, Kubernetes, browser automation and system changes. For Claude Code, Codex and Claude Desktop, administrators can lock permission rules, preserve managed hooks, restrict MCP servers and constrain plugin sources. New rules can run in Simulation Mode.

Delivery is the other distinctive part. Bay says it deploys through your existing EDR or MDM, with no new agents and no new tools, as an ephemeral binary it calls Wave that scans and exits.

Policies can be scoped by agent, group, endpoint or device, so a team can start with a narrow set of rules for one group of developers and widen them once the results look right. Because Simulation Mode runs a rule without enforcing it, the first weeks can show what a rule would have stopped before anyone is blocked. That makes a staged rollout practical for teams wary of interrupting work.

Where does that fit?

In the finder, Bay matches the device position fully and every device-related check it can: naming coding agents, tool-call decisions, rollout through existing EDR or device management, ask, block, a watch-only or simulation mode, and an action record. In our example profiles, it comes first alone for a company whose coding agents can reach production, which wants to block first and runs EDR and device management. It comes second in the Palo Alto Networks and SentinelOne profiles, behind the product built into that platform. That reflects how the rules treat a product whose pages describe decisions on the device in detail.

Where does it not fit?

The pages we read do not describe delivery through a browser extension, network proxy or gateway, so a company whose main concern is employees pasting data into browser AI will see products that describe those positions weighted for that answer.

What are the limits to weigh?

  • Bay does not publish a documentation portal or pricing; ask for architecture documents and references during evaluation.
  • Bay's headline figures are its own statements, and we have not verified them. One example is under 5 minutes to full deployment.

How does it compare with the other EDR-delivered product?

Noma Security also states that it works through existing EDR or MDM without a new endpoint agent. The difference on our checks is in decisions and breadth: Bay's pages describe ask, a simulation mode and a person-versus-agent record, which Noma's pages do not describe; Noma's pages describe SaaS and homegrown agents. The Bay and Noma head-to-head shows every recorded fact side by side.

Does Bay replace EDR?

No. Bay's pages describe deploying through EDR or MDM, and its decisions are about what AI agents may do, not about malware or intrusion. Plan for both.

What should you ask Bay in an evaluation?

  1. Which agent surfaces does Bay Enforcer support today, and which are next?
  2. What exactly runs on the device, for how long, and what does it change?
  3. What does a developer see when an action is set to Ask, and how fast is the answer recorded?
  4. Can you share architecture documentation?
  5. What would cover the browser, cloud workspaces or SaaS agents alongside Bay, if we need them?

These are the same kinds of questions we suggest for every product, sharpened by where Bay's public pages are thinnest.

Sources

Source: Bay product and coverage information supplied by Bay (15 October 2026) · Read 15 Oct 2026

Source: Bay homepage · Read 27 Sep 2026

Source: Bay blog: Ghostjacking, an AI agent attack (August 2026) · Read 27 Sep 2026

Source: Bay blog index · Read 27 Sep 2026

Source: Bay demo request · Read 27 Sep 2026

Source: Noma Security: endpoint agents · Read 27 Sep 2026

Source: Noma Security homepage · Read 27 Sep 2026