MoorAI vs Bay Security
Last updated
Bay and MoorAI work at the same point: on the employee’s machine, inside the coding agent’s own hooks, deciding each action before it runs, without a cloud round-trip. Bay: “Bay runs an on-device enforcer over every action Claude Code and Cowork take - allowing, prompting, or blocking each one before it runs.” and “Rides Claude's own hooks - evaluated in the call path, locally, in milliseconds, and works offline” (bay.io/use-cases/platform/claude) MoorAI runs where the agent runs too. On employee endpoints it is a PreToolUse hook inside the coding agent and an MCP stdio proxy in front of its tool servers, and a device whose console is unreachable keeps enforcing its cached policy. On AI servers it is server mode of the same hook, @moorai/agent-sdk in the service’s own process, the moorai-serve localhost sidecar, an MCP gateway in front of remote MCP servers and a model proxy in front of model APIs.
The differences are in what each keeps, who writes the policy, and what happens when the enforcer cannot decide. Bay drafts the policy: “Bay scans your environment and auto-generates policies based on your actual tools and data flows.” (bay.io) MoorAI’s policy is signed and declared, and it decides against its 85-threat matrix on the device that reads the content of each action: the file read into context, the shell command, the Model Context Protocol (MCP) arguments and results, the model’s tool calls and its output. By default it sends only category · risk · keyed one-way hash (plus the login and hostname, which the console pseudonymises on arrival). Bay says its enforcement “fails open”; MoorAI lets the administrator choose open or closed for each surface.
Three things this page does not state. (1) Which agents Bay enforces on. Bay names Claude Code, Cowork and Claude in Chrome, manages settings for Codex and Claude Desktop, and writes that its Enforcer works “On supported agent surfaces” (bay.io/blog/ghostjacking-ai-agent-attack); the full list is in its documentation, which requires a sign-in: “The Bay documentation is available to signed-in users.” (docs.bay.io) (2) Whether Bay can be run without its cloud. Enforcement runs on the device; where the Admin Center is hosted, and whether it can be self-hosted, is not described. (3) Pricing. We found no price list on Bay’s site; its pages lead to a demo request. Bay’s public material is a home page, a Claude use-case page, two research posts, an event page and its legal pages. Every Bay statement below is quoted from Bay’s own site, and the page is named.
Both stop the action, not the sentence. The difference is what else each reads, and what leaves the machine.
Where MoorAI holds ground Bay does not
These rows follow from reading the content of each action on the device, keeping that content off the console, and covering agent services as well as laptops.
Scroll sideways →
| MoorAI | Bay | |
|---|---|---|
| By default only category · risk · keyed one-way hash (plus login and hostname, pseudonymised on arrival) leave the device | ✓ | ◐secrets masked before upload; activity, and prompts and outputs where monitored, may be uploaded |
| Detects an injected instruction in what the agent reads | ✓detectors on ingested content; session taint | —enforces on the resulting action instead |
| Screens the agent’s own output for secrets, PII and insecure code | ✓ | —not in public material |
| Administrator chooses fail open or fail closed, per surface | ✓signed policy or root-owned admin binding | ✗“enforcement fails open” |
| Agent services on servers: Agent SDK in-process, localhost sidecar, MCP gateway, model proxy | ✓ | —bay.io describes endpoints |
| Coding agents by name beyond Claude: Codex CLI, Copilot CLI, Gemini CLI, Cursor, Factory Droid | ✓pre-tool hooks; validated end to end on Claude Code | —enforcement names Claude Code and Cowork; managed settings for Codex |
| Open source, so the data claim can be checked in code | ✓agent MIT | ✗no public repositories |
| Public product documentation, no demo call | ✓ | ✗docs.bay.io requires a sign-in |
| Self-hosted console, and enforcement documented for air-gapped networks | ✓free to self-host, no user limit | —not described |
Where Bay covers ground MoorAI does not
This list matters. Bay writes the first policy for you, scopes it by team, and locks the agents’ own settings.
Scroll sideways →
| MoorAI | Bay | |
|---|---|---|
| Policy generated from the environment and tuned per team | ◐declared profiles and envelopes; observed destination map; nothing drafts the profile | ✓“auto-generates policies” |
| Policy scoped by identity-provider group | —not described in the agent README | ✓ |
| Locks agent settings (Claude Code, Codex, Claude Desktop) and reports tampering | ◐reports weakened settings in a daily heartbeat; does not lock them | ✓ |
| MCP rules by action category (Read, Create, Update, Delete, Execute) per server or tool | ◐server allow-list and argument checks; write verbs treated as high-impact | ✓ |
| Removes a disallowed MCP server from the agent’s configuration | ✗refuses its calls instead | ✓in Enforcement mode |
| Claude in Chrome browser actions under the same policy | —not described | ✓ |
| Claude Cowork actions through a workstation hook | ◐Inference hooks beta server only; tested on sample frames | ✓ |
Same capability, different mechanism
Both products do each of these, so the table describes how rather than scoring.
Scroll sideways →
| MoorAI does it by… | Bay does it by… | |
|---|---|---|
| Stopping an agent’s action before it takes effect | A PreToolUse hook in the agent’s own process, validated end to end on Claude Code. Codex CLI, Copilot CLI, Gemini CLI, Cursor and Factory Droid block through their own pre-tool hooks. An MCP stdio proxy enforces for any host that launches a stdio MCP server. A device that is not enrolled in a MoorAI console coaches and never blocks. | An Enforcer at the agent’s hooks: “On supported agent surfaces, the Enforcer evaluates prompts, pre-tool calls, and post-tool responses, then returns Allow, Ask, or Deny locally, in under 4ms, with no cloud round-trip.” (bay.io/blog/ghostjacking-ai-agent-attack) |
| Trying a policy before enforcing it | moorai-ingest replays the tool calls, results and prompts the agents already recorded on the machine through the hook’s own decision functions, under the policy in force or a candidate, and reports what enforce mode would have done, as counts. |
“Teams can run them in Simulation Mode, inspect would-be decisions, tune rule order and exceptions, and then move to enforcement without rebuilding every agent configuration by hand.” (bay.io/blog/ghostjacking-ai-agent-attack) |
| Finding the agents and what they can reach | An on-device AI bill of materials, Skill Analysis of the skills, sub-agents, commands and MCP configs an agent auto-loads, a credential exposure map by class, and coverage integrity findings for an agent in use with no MoorAI hook traffic or with weakened settings. | “Bay inventories AI agents, MCP servers, tools, credentials, extensions, settings, and endpoint deployments, and applies 200+ detection rules with risk scoring and guided remediation across that inventory.” (bay.io/blog/ghostjacking-ai-agent-attack) |
| Checking skills and add-ins | Skill Analysis: an inventory and intent view of everything an agent auto-loads, with the MCP server reputation score and a signed catalogue of vetted servers and skills. | “The Skill Security Profile also analyzes agent add-ins for instruction overrides, approval bypass, concealed content, execution behavior, credential access, and network destinations.” (bay.io/blog/ghostjacking-ai-agent-attack) |
| Getting onto the machines | An installer or package per platform (macOS, Windows, Linux), with MDM provisioning (Jamf, Intune) writing the enrollment file so the device never shows a sign-up form. | “Deploys through your existing EDR or MDM. No new agents, no new tools. Scans in minutes, exits cleanly.” (bay.io) |
MITRE ATLAS, as documented. In our reading of vendor material against the 76 ATLAS techniques tagged Agentic AI, Bay’s published material documents 8 of the 76, each with a limit on what it covers (read 29 October 2026): AML.T0053 AI Agent Tool Invocation, AML.T0086 Exfiltration via AI Agent Tool Invocation, AML.T0098 AI Agent Tool Credential Harvesting, AML.T0101 Data Destruction via AI Agent Tool Invocation, AML.T0081 Modify AI Agent Configuration, AML.T0110 AI Agent Tool Poisoning, AML.T0083 Credentials from AI Agent Configuration and AML.T0103 Deploy AI Agent. Bay’s own statement that it does not claim to keep attacker-written text out of an agent’s context means no cell for prompt injection, which the method honours over any implication elsewhere. That counts what the public pages say; Bay’s documentation is behind a sign-in and was not read. The method and every quote behind the number are in MITRE ATLAS agentic-technique coverage.
Where MoorAI is stronger. What is inside each action, and what never leaves the machine. MoorAI reads the content of the file read, the command, the MCP argument and result, the model’s tool call and the agent’s output on the device, and coaches, masks or blocks there, including an injected instruction Bay chooses not to make its boundary. The console receives no content, the code that guarantees that is MIT, and enforcing is free on a self-hosted console, with enforcement documented for air-gapped networks. The administrator decides whether each surface fails open or closed. And the same signed policy covers agent services on servers through the Agent SDK, the sidecar, the MCP gateway and the model proxy.
Where Bay is stronger. A policy nobody has to write, scoped by team, on settings nobody can quietly turn off. “Bay self-tunes a policy for every team - automatically calibrating connectors, settings, and action-level guardrails to how engineering, finance, and legal actually work.” (bay.io/use-cases/platform/claude) Its managed settings lock Claude Code, Codex and Claude Desktop configuration and report tampering, its MCP rules work per tool and per action category, it removes disallowed servers from the agent’s configuration, and it covers Claude in Chrome. For a security team that wants a working policy on day one without writing one, Bay starts further ahead.
Which to run where. On employee machines the two overlap directly and both decide before the action runs; the choice is about what you want kept and who writes the policy. Bay if you want a generated, team-scoped policy and locked agent settings. MoorAI if you want each action also judged by its content and by the person’s request, with a record that holds no prompt content, code you can read, a console you can host yourself and a fail mode you choose. On agent services that call model APIs and MCP servers, MoorAI’s server mode, SDK, sidecar, gateway and proxy apply the same signed policy. Two enforcers on the same hook would each answer every call; we have not run them together.
Questions about MoorAI and Bay Security
Do Bay Security and MoorAI both enforce on the device, before the action runs?
Yes. Bay runs an on-device enforcer through Claude’s own hooks that allows, prompts or blocks each action of Claude Code and Cowork before it runs, evaluated locally and working offline. MoorAI runs as a pre-tool hook in Claude Code, validated end to end there, and in Codex CLI, GitHub Copilot CLI, Gemini CLI, Cursor and Factory Droid through their own pre-tool hooks, plus an MCP stdio proxy, and a device keeps enforcing its cached policy when the console is unreachable.
What data does each send to its console?
Bay masks secrets and PII on the endpoint before upload, and its privacy policy says the data it processes may include agent and tool activity and, where the customer monitors them, prompts and outputs. MoorAI sends a category, a risk level and a keyed one-way hash by default, plus the login and hostname, which the console pseudonymises on arrival, and never the prompt, the file or the matched span.
Who writes the policy?
Bay scans the environment, auto-generates policies from the tools and data flows it finds, and self-tunes a policy for each team, scoped by identity-provider group. MoorAI’s policy is signed and declared by an administrator: the threat matrix and its actions, egress rules, an approved MCP server list, entitlement envelopes and workload profiles. Both let you try a policy against past activity before enforcing it.
What happens when the enforcer cannot decide?
Bay states that its enforcement fails open. MoorAI fails open by default on the coding-agent hook, and an administrator can make each surface (the hook, the model proxy, the MCP gateway and the inference hooks server) fail closed through the signed policy or a root-owned admin binding; each closed refusal raises a content-free alert.
Is Bay Security’s documentation or pricing public?
No. Bay’s documentation requires a sign-in, and its pages lead to a demo request with no price list. MoorAI’s agent is MIT and documented in its public repository, and its console is free to self-host with no user limit.
Bay Security capabilities are taken from Bay’s own published material, checked on 29 October 2026: bay.io, its Claude use-case page (whose three tabs were read in a browser), the research posts Ghostjacking and The Hidden Channel Between Your Devices, and the privacy policy. Bay’s documentation requires a sign-in and was not read. Every quoted phrase is Bay’s. Customer quotes and outcome figures on Bay’s pages are not used. ◐ = partial: present but narrower than the other column. — = unconfirmed, not necessarily absent. MoorAI marks reflect shipped capability: hook enforcement is validated end to end on Claude Code; Codex, Copilot CLI, Gemini CLI, Cursor and Factory Droid block through their own pre-tool hooks. The agent is MIT and runs on macOS, Windows and Linux; the console is source-available under the Elastic License 2.0, free self-hosted with no user limit, and paid when hosted by MoorAI. Bay Security is a trademark of its owner; this page is independent and is not affiliated with or endorsed by Bay Security. Both products change, so check specifics against current documentation.