MoorAI vs Bloom Security
Last updated
Both work on the employee endpoint, and both treat AI agents, MCP servers, IDE extensions and packages as the new risk there. Bloom is an endpoint control plane: it inventories everything on the machine, scores each tool’s risk, removes or reconfigures what is risky and blocks risky software at install. MoorAI decides each agent action before it runs, on the device, by what the action contains and what the user asked for. Bloom describes its product as follows: “With Bloom you can see, control, and secure everything that runs on the endpoint.” (bloom.security) Its reach is the whole machine: “Monitor the OS, local data, installed applications, plugins, and code libraries” (bloom.security), and it stops software at install: “Block malicious, vulnerable, or policy-violating packages and skills at the source” (bloom.security). MoorAI runs where the agent runs. On employee endpoints it is a PreToolUse hook inside the coding agent and an MCP stdio proxy in front of its tool servers. On AI servers (MoorAI for AI Servers) it is server mode of its hook in claude -p CI jobs, the Claude Code GitHub Action and Agent SDK services in containers, @moorai/agent-sdk in the service’s own process, the moorai-serve localhost sidecar for other agent loops, an MCP gateway in front of remote MCP servers and a model proxy in front of model APIs. It reads the prompt, the file read into context, the shell command, the Model Context Protocol (MCP) arguments and results and the tool calls in a model’s response, and coaches, masks or blocks on what it finds.
They meet on the endpoint, at different moments. Bloom’s decisive moment is when a tool arrives or is configured: “with a supply-chain firewall that stops software at the door rather than after it's running” (bloom.security/blog/why-we-built-bloom). MoorAI’s is each action an agent takes once it is running: the file it reads, the command it runs, the MCP call it makes. Bloom also blocks one kind of runtime action, an AI tool’s connection to a sensitive datastore, using Cyera’s data labels: “If an AI tool tries to connect to a datastore Cyera flagged as Sensitive and above, Bloom blocks it in milliseconds.” (bloom.security/blog/bloom-cyera-data-aware-ai-security) MoorAI decides against its 85-threat matrix on the device and by default sends only category · risk · keyed one-way hash (plus the login and hostname, which the console pseudonymises on arrival).
Bloom covers ground MoorAI does not. It inventories and scores software that has nothing to do with AI, enforces install policy across “npm, Chrome Web Store, Open VSX, and others” (bloom.security), analyses tools with “behavioral sandboxing”, and remediates: “Surgically remove risky tools, revoke permissions, and fix misconfigurations” (bloom.security). The rows where Bloom covers more ground are further down.
Three things this page does not state. (1) What Bloom’s endpoint component sends to Bloom, and what Bloom keeps. Bloom’s Claude integration says “Bloom retrieves every artifact Claude generates and every file users upload.” (bloom.security/anthropic-compliance-api-integration); which fields its endpoint records carry, and where they are processed, is not described. (2) How an action is stopped on the endpoint. Where Bloom intercepts an AI tool’s connection, and which agents its guardrails reach, is not described in public material; its documentation site, docs.bloom.security, requires a sign-in and was not read. (3) Pricing. We found no price list on Bloom’s site; its pages lead to a demo request. Every Bloom statement below is quoted from Bloom’s own site, and the page is named.
The core difference is when and on what each decides: on the tool, when it arrives and is configured, or on the action, each time the agent takes one.
.env read into the agent’s context, a secret in the arguments of an approved MCP call, a destructive command on a path the prompt never named, an injected instruction in a fetched page. That catches harm done with a tool that passed every install check.npm, pip or cargo install of a near-miss or hallucinated package name, on-device and by name only; an MCP server reputation score that can refuse a low-scoring server; moorai-scan, a pre-install gate for a skill or agent artifact; and a report-only scan of installed IDE extensions for published malicious versions, typosquats, publisher impersonation and invisible code. MoorAI has no malicious-package feed for npm or PyPI and no browser-extension store policy.Where MoorAI holds ground Bloom does not
These rows follow from reading the content of each agent action on the device, before it runs, and from keeping that content off the console.
Scroll sideways →
| MoorAI | Bloom | |
|---|---|---|
| Decides each agent tool call before it runs, by its content | ✓pre-tool hooks; validated end to end on Claude Code | —blocks connections to sensitive datastores; content check not described |
| Blocks a secret at the file read, before it enters the model’s context | ✓hooks the agent's file-reading tools | —not in public material |
| Detects an injected instruction in what the agent reads | ✓detectors on ingested content; session taint | —researched in its blog, not claimed as a control |
| Masks a secret or PII span and lets the call proceed | ✓mask action | — |
| Flags a risky action aimed at something the user’s request never named | ✓intent alignment; lexical, keyed hashes | — |
| AI servers as well as laptops: agent services, MCP gateway, model proxy | ✓server mode, Agent SDK, sidecar, gateway, proxy | —describes endpoints |
| By default only category · risk · keyed one-way hash (plus login and hostname, pseudonymised on arrival) leave the device | ✓capture tiers are opt-in, admin-enabled | —fields sent not public; Claude artifacts and files retrieved for scanning |
| Enforces with no network, on a self-hosted console | ✓air-gapped deployment; cached and last-known-good policy | —not described |
| Open source, so the data claim can be checked in code | ✓agent MIT | ✗proprietary; publishes research scripts |
| Public product documentation, no demo call | ✓ | ✗docs.bloom.security requires a sign-in |
| Free to start and to enforce, without talking to sales | ✓agent free; console free self-hosted, no user limit | ✗no public pricing; demo-led |
Where Bloom covers ground MoorAI does not
This list is long, and it matters. Bloom covers the whole endpoint, not only its AI, and it acts on what it finds: it blocks software at install and removes or reconfigures what is already there.
Scroll sideways →
| MoorAI | Bloom | |
|---|---|---|
| Inventory of all software on the endpoint: OS, applications, extensions, packages | ◐AI bill of materials: agent hosts, MCP servers, IDE extensions, local model servers, AI keys at rest | ✓ |
| Blocks malicious or vulnerable packages, extensions and skills at install, across npm, Chrome Web Store and Open VSX | ◐agent installs gated by name (typosquat, hallucinated); MCP reputation; skill pre-install gate | ✓supply-chain firewall |
| Behavioural sandboxing of a tool before it is trusted | ✗static checks; packages are not run | ✓ |
| Removes risky tools, revokes permissions and fixes misconfiguration, with a preview of who is affected | ✗reports and blocks; does not uninstall or rewrite configuration | ✓ |
| Blocks an AI tool’s connection by the data classification of the datastore it reaches | ✗no data-security posture integration | ✓with Cyera DSPM |
| Scans Claude artifacts and uploaded files for secrets and PII through the Compliance API | ✗read-only, content-free by design | ✓ |
| Published vulnerability research on agent, extension and package marketplaces | ◐detection research and a public benchmark | ✓CVEs in Open VSX; disclosures to marketplaces |
Same capability, different mechanism
Both products do each of these, so the table describes how rather than scoring.
Scroll sideways →
| MoorAI does it by… | Bloom does it by… | |
|---|---|---|
| Finding the agents and their tools | An on-device AI bill of materials (agent hosts, MCP servers, IDE extensions, local model servers and AI keys at rest, exportable as CycloneDX or SPDX), Skill Analysis of the skills, sub-agents, commands and MCP configs an agent auto-loads, and coverage integrity findings for an agent in use with no MoorAI hook traffic. | “Discover software, extensions, AI, and everything running on your endpoints” (bloom.security), and “Bloom discovers which AI tools, MCPs, and agents are running on every endpoint and which datastores they attempt to connect to.” (bloom.security/blog/bloom-cyera-data-aware-ai-security) |
| An agent’s safety settings being weakened | A content-free daily heartbeat per agent host reports the settings that weaken or switch off protection (hooks disabled, bypassPermissions, Codex approval_policy = "never", a sandbox off), and the console’s read-only Claude Compliance API integration alerts on Claude admin and configuration changes. |
“When someone changes Claude’s execution policy, like disabling permission prompts, Bloom detects it immediately and alerts your security team.” (bloom.security/anthropic-compliance-api-integration) |
| Over-permissioned MCP servers | An approved-server allow-list enforced at call time with a discovered → approved / denied lifecycle in the console, a reputation score that can refuse a low-scoring server, and an entitlement envelope of authorised tools, path prefixes and MCP servers per agent. | “Automatically scale back overpermissioned MCP servers and configurations to safe defaults” (bloom.security) |
| Claude plugins, skills and MCP servers added or changed | Rug-pull detection in the console for devices running the desktop app: a server whose transport, capability flags or launch-risk flag change after approval goes back to pending. Skill Analysis reports drift in the skill surface on the device. | “Bloom tracks when they’re introduced, flags unreviewed components, and monitors lifecycle changes.” (bloom.security/anthropic-compliance-api-integration-documentation) |
MITRE ATLAS, as documented. In our reading of vendor material against the 76 ATLAS techniques tagged Agentic AI, Bloom’s published material documents 6 of the 76: AML.T0010 AI Supply Chain Compromise, and, each with a limit on what it covers, AML.T0053 AI Agent Tool Invocation, AML.T0081 Modify AI Agent Configuration, AML.T0103 Deploy AI Agent, AML.T0109 AI Supply Chain Rug Pull and AML.T0132 Misconfigured or Publicly Exposed AI Services (read 29 October 2026). Most of Bloom’s blog is vulnerability and malware research on skills, extensions, packages and Claude; it explains attacks rather than claiming Bloom detects them, so it adds no cell. That counts what the public pages say; Bloom’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 agent action, decided before it runs, on the device. The file read, the shell command, the MCP argument and result, the model’s tool call, the prompt and the output are read where the agent runs and coached, masked or blocked there, including when the tool doing the harm passed every install check: a secret in an approved MCP call, an injected instruction in a fetched page, a deletion on a path the user never named. The same policy covers agent services through server mode, the Agent SDK, the moorai-serve sidecar, the MCP gateway and the model proxy, enforcement works with no network, the console receives no content, the code that guarantees that is MIT, and enforcing is free on a self-hosted console.
Where Bloom is stronger. Breadth of the endpoint, and acting on it. Bloom inventories and scores everything on the machine, not only its AI, blocks malicious and vulnerable packages, extensions and skills at install across the major registries and stores, analyses tools in a sandbox, and removes risky tools or fixes their configuration with a preview of who is affected: “Preview what changes and who is affected before acting” (bloom.security). Its Cyera integration ties an agent’s reach to the classification of the data it would touch. And its research team finds and discloses the marketplace flaws its product defends against: “Our team found a way to hijack any extension on Open VSX” (bloom.security/blog/extension-possession-one-click-to-take-over-every-extension-on-open-vsx). For a security team whose first problem is what is installed on its laptops, Bloom covers ground MoorAI does not.
Which to run where. The two are largely complementary: Bloom decides what may be installed and configured on the endpoint, and MoorAI decides what a running agent may do with each action. On the endpoint, Bloom if your first need is control of software arriving on the machine, including what agents install; MoorAI if your first need is the content of agent actions, with a record that holds no prompt content and code you can read. On agent services that call model APIs and MCP servers, MoorAI’s server mode, SDK, sidecar, gateway and proxy apply the same signed policy. Nothing in either’s public material says they conflict, and we have not run them together.
Questions about MoorAI and Bloom Security
Do Bloom Security and MoorAI do the same job?
They overlap on the employee endpoint but decide at different moments. Bloom inventories everything that runs on the endpoint, scores each tool’s risk, blocks malicious, vulnerable or policy-violating packages, extensions and skills at install, and removes risky tools or fixes their configuration. MoorAI runs inside the coding agent as a pre-tool hook and an MCP stdio proxy, and decides each action the agent takes, the file it reads, the command it runs and the MCP call it makes, before it runs, by what the action contains and what the user asked for.
Does Bloom Security block AI agent actions at runtime?
Bloom describes one runtime block in its public material: with its Cyera integration, when an AI tool tries to connect to a datastore Cyera labels Sensitive or above, Bloom blocks the connection. It also describes AI guardrails that define what agents can access, execute and transmit and that scale back over-permissioned MCP servers. Where the endpoint intercepts an action, and whether an action’s content is inspected, is not described in its public pages; its documentation requires a sign-in. MoorAI checks each tool call and model call against a signed policy before it runs: the threat matrix and content rules (secrets, PII, injected instructions, destructive operations), the user’s own request, and any workload profile or entitlement envelope an administrator declares.
What does Bloom Security cover that MoorAI does not?
Bloom inventories all software on the endpoint, not only AI; blocks malicious or vulnerable packages, extensions and skills at install across npm, the Chrome Web Store, Open VSX and others; analyses tools with behavioural sandboxing; removes risky tools, revokes permissions and fixes misconfiguration; blocks an AI tool’s connection to a datastore by its Cyera classification; and scans Claude artifacts and uploaded files through Anthropic’s Compliance API. MoorAI gates agent package installs by name only, scans installed IDE extensions in report-only mode, and does not uninstall software or rewrite configuration.
What data does each send to its console?
Bloom’s Claude integration retrieves every artifact Claude generates and every file users upload in order to scan them, and its onboarding guide asks for a Compliance Access Key with the user-data scope for full scanning; which fields its endpoint component sends is not public. 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 keeps content only if an administrator enables a capture tier. Its own Claude Compliance API integration is read-only and stores the Activity Feed content-free.
Is Bloom Security’s documentation or pricing public?
No. Bloom’s documentation site 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.
Bloom Security capabilities are taken from Bloom’s own published material, checked on 29 October 2026: bloom.security, its Anthropic Compliance API integration page and onboarding guide, and its blog. Bloom’s documentation site requires a sign-in and was not read. Every quoted phrase is Bloom’s. Customer quotes on Bloom’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. Bloom Security is a trademark of its owner; this page is independent and is not affiliated with or endorsed by Bloom Security. Both products change, so check specifics against current documentation.