MoorAI vs Noma Security
Last updated
This is the closest architectural comparison we draw, so it starts with what Noma gets right. Noma Security is a funded enterprise AI-security platform: in July 2025 it “today announced it has raised $100 million in Series B funding”, and “The round was led by Evolution Equity Partners” (noma.security press release). It ships a real coding-agent product. Noma publishes open-source, Apache-2.0 guardrails plugins that hook the same coding agents MoorAI hooks: Claude Code, Codex, Cursor and GitHub Copilot. In Noma’s own words the plugins “hook into each agent framework’s native extension points” (github.com/Noma-Security/noma-marketplace), and its product page says “For Claude Code and Cursor, Noma enforces through the agent’s native hook mechanism: before and after tool calls, before and after shell commands.” (noma.security/solutions/coding-assistant-security) Both work at the same layer, so the comparison comes down to the data model underneath the hook.
The divergence is where evaluation runs and what leaves the machine. The open-source part of Noma is the thin hook client. By its own documentation the plugins “stream hook events to the Noma backend for policy evaluation, returning enforcement decisions to the agent”, so that “every prompt, shell command, MCP call, and file access your agent makes is evaluated by the Noma AIDR platform in real time”, and they require a Noma API key (github.com/Noma-Security/noma-marketplace). Noma states its data rule plainly: “only fields required for policy evaluation leave the machine, with secret-looking values masked”. That backend can be Noma’s or the customer’s: Noma offers “Support for both on-prem and SaaS deployments ensuring your unique requirements are met so that no model, training data or security events leave your environment.” (noma.security/solutions/coding-assistant-security) MoorAI evaluates on the developer’s own machine. By default only category · risk · keyed one-way hash (HMAC-SHA-256; plus the login and hostname, which the console pseudonymises on arrival) leave the device; the prompt, the command and the file content do not. Because the detector is open source (MIT), that guarantee is auditable rather than taken on the vendor’s word.
And MoorAI publishes its detection numbers, misses included. We found no detection rate, recall or precision figure in the Noma pages read for this comparison; its material describes capabilities and scale. MoorAI’s README reports its prompt-attack detectors on a locked test half that detector work never sees: 38 of 44 (86.4%) caught deterministically at 100% precision on that half, and a 3.32% false-positive rate (20 of 602) on a separate benign corpus built with hard negatives. The same README calls the 13.6-point gap to the tuning half the overfit margin. Those are MoorAI’s own measurements, from scripts in its repository, and the README says the durable control is the action layer that blocks the tool call, not prompt detection.
Three things this page does not state. (1) Where a given customer’s hook events are evaluated. The plugin’s default endpoint is Noma’s API, and Noma also offers on-prem deployment, so the answer depends on the deployment. (2) How well Noma detects. We found no published figure, so no row scores it. (3) Anything from Noma’s product documentation. Beyond the plugin READMEs on GitHub we read none; every Noma statement below is quoted from Noma’s own site or GitHub, and the page is named.
Where MoorAI goes deeper
Same hook, different underneath: on the device, content-free, with a detector you can read and published numbers for what it catches and what it gets wrong. Several Noma rows are marked — unconfirmed, not absent, because Noma’s backend is proprietary and its public material does not document these either way.
Scroll sideways →
| MoorAI | Noma Security | |
|---|---|---|
| Detection runs on the developer’s device, with no backend in the decision | ✓on-device evaluation | ✗hook events streamed to the Noma backend for evaluation (their README) |
| Content-free by construction — prompt / command / file content never leaves the device | ✓content-free by architecture | ✗fields needed for evaluation leave; secret-looking values masked first |
| Only category · risk · keyed one-way hash (plus login and hostname, pseudonymised on arrival) leave the device | ✓redacted signals only, HMAC-SHA-256 | ✗evaluates events in the backend, SaaS or on-prem |
| The detector itself is open source — the content-free claim is checkable | ✓MIT detector, readable interceptor | ◐plugin Apache-2.0, but the evaluating backend is proprietary |
| Published detection rates, with the false-positive rate beside them | ✓38 of 44 on a locked test half; 20 of 602 benign flagged | —none found in the pages read |
| Runs standalone with no account, no API key, no console to stand up | ✓coaches with no account; enforcing needs a console, free self-hosted | ✗plugin requires a Noma API key |
| Keeps deciding with no network connection | ✓no network in the decision; MOORAI_OFFLINE_MODE keeps enforcing without a token | ✗with no network the plugin exits without a decision (their README) |
| Blocks a secret being read into context, decided on the device | ✓per-tool arg rule at read time, on-device | ◐protects file reads, but the decision is made in the backend |
| Flags a risky action aimed at something the user’s request never named | ✓intent alignment; lexical, keyed hashes | —scope violations detected; method not public |
| Stops a typosquatted or hallucinated package name at install | ✓slopsquatting gate, name only, offline | —unconfirmed |
| On-device OCR of image inputs (macOS Vision + Windows OCR) | ✓on-device OCR | —unconfirmed |
| Content-free browser GenAI prompt interception (on-device extension) | ✓on-device extension, 8 GenAI web apps | —unconfirmed |
| On-device semantic second opinion — opt-in, no vendor-cloud egress | ✓opt-in, local model on the loopback interface | ✗evaluation in the Noma backend by design |
| Cryptographically signed, tamper-evident decisions carrying in-toto / SLSA attestation | ✓ed25519 receipt per decision; in-toto export | —unconfirmed |
Where the two meet head-on
Noma is not marked absent here. It ships open-source hooks for the same coding agents, and at the coding-agent surface the two products meet directly. Expect substantial overlap if you evaluate both.
Scroll sideways →
| MoorAI | Noma Security | |
|---|---|---|
| Native hooks in front of Claude Code, Codex, Cursor and GitHub Copilot | ✓validated end to end on Claude Code; the others not yet against the live agents | ✓guardrails plugins for all four |
| Pre-execution review of shell commands and tool calls (before / after) | ✓ | ✓ |
| MCP tool-call mediation and server access controls | ✓ | ✓ |
| Allow / block / ask on risky agent actions (injection, data leak, shell exec) | ✓ | ✓ |
| Sensitive-data (PII / PCI / secrets) detection on the coding-agent path | ✓ | ✓ |
| Masks a secret or PII span inline and lets the call proceed | ✓mask action; built from the hooks reference, not yet observed in a live session | ✓inline masking |
| Coding agents running headless, in CI or in the cloud | ✓server mode; one live claude -p run proven, Actions and Agent SDK not yet watched end to end | ✓desktop, CLI and cloud sessions |
| Cross-platform: macOS, Windows and Linux | ✓ | ✓ |
| MDM / managed-settings fleet rollout (Intune, Jamf) | ✓ | ✓ |
| OWASP LLM Top 10 / MITRE ATLAS threat framing | ✓ | ✓ |
Where Noma Security covers more ground
Most of Noma’s weight sits here. Noma is a funded enterprise platform, and the coding-agent hooks are one product in a suite. If the requirement is a central governance plane across all of an organisation’s AI, not just the coding agents on a laptop, that is Noma’s product, and MoorAI does not attempt it.
Scroll sideways →
| MoorAI | Noma Security | |
|---|---|---|
| One platform across endpoint, SaaS and homegrown agents | ✗coding-agent scope only | ✓unified enterprise platform |
| AI-SPM — AI asset discovery & posture management | ✗not attempted | ✓AI-SPM product |
| Fleet-wide discovery of coding assistants & MCP servers via EDR, with no new install | ◐on-device AI bill of materials, not fleet-EDR | ✓CrowdStrike EDR integration |
| MCP server supply-chain scanning (unpinned versions, excess permissions, CVEs) | ◐reputation score and an on-device package scan | ✓scans approved MCP servers |
| Identity-aware policy keyed to IdP users and groups, down to individual tools and actions | ◐per-device policy and an entitlement envelope per agent; no IdP groups | ✓ |
| Session-level correlation, such as an injection now and secret exfiltration later | ◐a confused-deputy pivot detector per actor; not yet tuned on production data | ✓Contextual Policies |
| Claude Code and Cowork sessions that run in Anthropic’s cloud | ✗hooks on machines MoorAI is installed on | ✓organization-level hooks, gateways or APIs |
| Continuous AI red teaming of AI apps & agents | ◐a local policy self-test (moorai-redteam), not a service | ✓AI Red Teaming product |
| Runtime detection & response across the AI estate (AI-DR) | ◐on-device AI-DR for agents on endpoints, the model proxy and the MCP gateway; not estate-wide | ✓AI-DR product |
| Enterprise compliance badges (ISO 27001, SOC 2, HIPAA) | ✗open-source project, no vendor attestations | ✓ISO 27001 · SOC 2 · HIPAA badges on its site |
| Funded vendor with enterprise support & account management | ✗community open source | ✓$100M Series B, Technical Account Managers |
MITRE ATLAS, as documented. In our reading of vendor material against the 76 ATLAS techniques tagged Agentic AI, Noma Security’s published material documents 20 of the 76 (read 1 October 2026), 10 of them with a limit the vendor states. Noma documents the same native-hook path for Claude Code and Cursor that MoorAI uses, so most of its coding-agent cells are first-party claims; several others are posture or inventory findings rather than runtime blocks. That counts what the documentation says, not a test of the product. The method and every quote behind the number are in MITRE ATLAS agentic-technique coverage.
Where MoorAI is stronger. Content-free evidence you can audit, at the coding agent. Both products hook the same agents, so the difference is what happens after the hook fires. Noma’s plugin sends the event to its backend to be judged; MoorAI judges it on the machine and, by default, only category · risk · keyed one-way hash (plus the login and hostname, which the console pseudonymises on arrival) leave. Because the detector is MIT, you can check the content-free claim in the code. The two exceptions are documented: an administrator can turn on a capture tier that stores the matched text it was enabled to collect, and on a platform whose OS cannot read an image locally a pasted screenshot can go to your own AI provider for text extraction, disclosed before it runs, never to us. MoorAI keeps deciding with no network, hooks Gemini CLI as well, runs in CI and containers through server mode, and publishes its detection numbers with the false-positive rate printed beside them.
Where Noma Security is stronger. The enterprise plane across all of your AI. Noma is a funded platform whose coding-agent hooks are one module beside AI-SPM, Agent Access Control, AI Red Teaming and AI-DR. It discovers agents across a fleet through EDR or MDM with nothing new to install, scans MCP servers for supply-chain risk, keys policy to IdP users and groups down to individual tools and actions, correlates a whole session so an injection followed later by exfiltration is visible, reaches Claude Code and Cowork sessions that run in Anthropic’s cloud, and detects agents signed in with personal accounts. It covers SaaS and homegrown agents as well as coding agents, deploys as SaaS or on-prem, rolls out through Cursor Enterprise or MDM, shows ISO 27001, SOC 2 and HIPAA badges, and comes with the support of a vendor that raised a $100M Series B. MoorAI does none of the estate-wide work; it ships a single, focused, on-device tier for the coding agent.
Choosing between them. They overlap more than most pairs on this site, so the choice is real. Pick Noma if you need one control plane governing every kind of agent across the organisation, with fleet discovery, identity-aware policy, red teaming and runtime response, and you are comfortable that coding-agent events are evaluated in a backend, Noma’s or your own on-prem deployment. Pick MoorAI where the requirement is that the coding agent is governed on the developer’s own machine, the evidence an auditor reads contains no one’s prompt content at all, the tool decides offline and coaches with no account, and the detector, along with the numbers for what it catches, is open enough to check yourself.
Questions about MoorAI and Noma Security
Does Noma Security evaluate coding-agent hooks on the device?
No, per its plugin README: the plugins stream hook events to the Noma backend for policy evaluation and return the decision to the agent, sending only the fields required for evaluation, with secret-looking values masked. The backend can be Noma’s SaaS or an on-prem deployment. MoorAI evaluates on the device and sends a category, a risk level and a keyed one-way hash (plus the login and hostname, which the console pseudonymises on arrival) by default.
Which coding agents does Noma Security hook?
Noma’s marketplace lists guardrails plugins for Claude Code, Codex, Cursor and GitHub Copilot, and its product page says it enforces through the native hooks of Claude Code and Cursor. MoorAI hooks Claude Code, validated end to end, and Codex CLI, Copilot CLI, Gemini CLI and Cursor, which are not yet validated against the live agents.
What happens when the Noma backend cannot be reached?
Noma’s README says any failure, including no key or no network, exits without a decision and leaves the agent’s default behaviour in place. MoorAI decides on the device, so a lost network does not remove the decision; like Noma’s plugins, its hooks fail open by default if the hook itself crashes or times out, and an administrator can set them to fail closed in the signed policy.
Does MoorAI replace Noma Security, or the other way round?
At the coding agent they overlap heavily: both hook the same agents and block, mask or ask on what they see. Beyond it they do not. Noma also covers SaaS and homegrown agents, AI-SPM, red teaming and AI-DR across an organisation, which MoorAI does not attempt. MoorAI differs in deciding on the device and sending no content by default.
Noma Security capabilities are taken from Noma’s own published material, checked on 1 October 2026: github.com/Noma-Security/noma-marketplace, Coding Assistant Security, Endpoint Agents, AI-SPM, AI Red Teaming, Noma Brings Agent Security to Every Employee Endpoint and Noma’s Series B announcement. Every quoted phrase is Noma’s. Analyst mentions on Noma’s pages are not used. ◐ = partial — present but narrower or differently sited than the other column. — = unconfirmed, not necessarily absent: it marks a capability Noma’s public material does not clearly document, and because the Noma backend is proprietary it cannot be verified either way. MoorAI marks reflect shipped capability: hook enforcement is validated end to end on Claude Code; Codex, Copilot CLI, Gemini CLI and Cursor block through their own pre-tool hooks and are not yet validated against the live agents. MoorAI’s detection figures are its own, from its README, and were not produced by a third party. 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. Noma Security is a trademark of its owner; this page is independent and is not affiliated with or endorsed by Noma Security. Both products change, so check specifics against current documentation.