MoorAI vs Vero Security
Last updated
Both secure the AI agents people install and run, and both block an agent’s risky action before it executes. Vero is built around the organisation’s inventory of agents; MoorAI is built around each action, checked where the agent runs. Vero describes its product as follows: “Vero Security is the Agent Detection and Enforcement platform that maps every agent and stops risky and forbidden actions.” (vero.security) Its platform has four parts: “Discover every agent across your stack, automatically catalogued.”, “Analyze every agent’s risk before it ever runs.”, “Detect every action, in flight and with full context.” and “Control your policy, drafted by Vero and enforced at runtime.” (vero.security) It also reads Claude: “Vero now connects natively to Anthropic's Compliance API.” (vero.security blog, Vero + Claude) MoorAI runs where the agent runs. On employee endpoints it is a PreToolUse hook inside the coding agent (Claude Code, Codex, Copilot CLI, Gemini CLI, Cursor) and an MCP stdio proxy in front of its tool servers. On AI servers it is server mode of the same hook, @moorai/agent-sdk in a service’s own process, the moorai-serve localhost sidecar, an MCP gateway and a model proxy. 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, against a 85-threat matrix. By default the console receives only category · risk · keyed one-way hash (plus the login and hostname, which the console pseudonymises on arrival).
They differ most in what they collect and in what is public. Through the Compliance API, Vero takes “the activity stream, the directory of users, roles, and groups, and, for claude.ai organizations, the underlying chats, files, and projects”. (vero.security blog, Vero + Claude) The MoorAI console reads the same API’s Activity Feed and settings, stores them content-free and never requests chat, file, project or transcript content. Vero’s lifecycle is shown as a story: an engineer installs Claude, the agent is discovered with its unreviewed MCP servers, a posture scan finds permission checks disabled, and later a malicious skill update is blocked at the call. MoorAI does each of those steps differently, and the rows below say how.
Vero covers ground MoorAI does not. A posture fix sent to the agent’s owner and verified closed, a skill allowlist set as policy, a policy drafted for you, and risk found between agents from different vendors: “Because Vero maps the whole layer, it catches what no single-platform view ever will: a Claude-built agent sharing a data source with another vendor's agent flow, a toxic combination neither side's own tooling would surface.” (vero.security blog, Vero + Claude) Vero also runs a research team that has disclosed two Claude Code command-approval bypasses to Anthropic and a sandbox token in Mistral’s coding agent.
Three things this page does not state. (1) How Vero attaches to an agent. Vero publishes no product documentation, and its product requires a login. Where an action is detected and blocked (on the device, in the browser, at a gateway or through a provider’s API), and which agents can be blocked, is not described. Vero says “At Vero, we secure the AI agents running across our customers' environments, including those in the browser.” (vero.security blog, Mistral sandbox) The four Compliance API scopes Vero lists are read scopes, so how a Claude action is blocked is not described. (2) What Vero keeps. Which fields of the chats, files and projects are stored, and for how long, is not described. (3) Pricing. We found no public price list; Vero’s pages lead to a demo request. Every Vero statement below is quoted from Vero’s own site, and the page is named.
The core difference is the unit of control: the agent, mapped and scored across the organisation, or the single action, read before it runs.
bypassPermissions, Codex approval_policy = "never", a sandbox off), and the console raises a finding for a weakened setting, an agent in use with no MoorAI hook traffic, and a hook removed or gone stale. Its credential exposure map says, by class only, which credentials an agent on the device can reach and which it read. Neither report carries a path or a value. MoorAI does not route the fix to an owner.read:compliance_user_data, and for claude.ai organisations reads the chats, files and projects. It says “Vero holds SOC 2 Type II.” and “The integration covers Claude Platform and Claude Enterprise deployments.” (vero.security blog, Vero + Claude) The MoorAI console reads the Activity Feed and stores it content-free (keyed pseudonyms, no email address, IP address, user agent, file name or title), alerts on Claude admin and configuration changes, lists people active in Claude whose devices show no MoorAI coverage, and shows the Claude organisation’s effective settings next to MoorAI’s policy. It never requests chat, file, project or transcript content.Where MoorAI holds ground Vero does not
These rows follow from reading the content of each action before it runs, where the agent runs, and from publishing how it is done.
Scroll sideways →
| MoorAI | Vero | |
|---|---|---|
| A published enforcement point in each coding agent: Claude Code, Codex, Copilot CLI, Gemini CLI, Cursor | ✓hooks; validated end to end on Claude Code | —blocks before execution; where and how not public |
| Blocks a secret at the file read, before it enters the model’s context | ✓hooks the agent's file-reading tools | —recommended in a Vero post; not claimed as a feature |
| Masks a secret or PII span and lets the call proceed | ✓mask action | —not in public material |
| Coaching with the safer alternative, shown to the developer and the agent | ✓ | — |
| Flags a risky action aimed at something the user’s request never named | ✓intent alignment; task-bound tool calls | —not in public material |
| Reads Claude through the Compliance API without requesting chat, file, project or transcript content | ✓Activity Feed, settings, optional session metadata; content-free | ✗reads chats, files and projects for claude.ai organisations |
| 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 | —what is kept not described |
| Open source, so the data claim can be checked in code | ✓agent MIT | ✗no public source |
| Public product documentation, no demo call | ✓ | ✗none public; the product requires a login |
| 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 Vero covers ground MoorAI does not
Vero treats the agent layer as something to be mapped, scored and remediated across vendors, and adds a content view of Claude. MoorAI’s console has findings, owners and an inventory, but no remediation workflow and no cross-agent view.
Scroll sideways →
| MoorAI | Vero | |
|---|---|---|
| A posture fix sent to the agent’s owner, then verified closed | ◐findings and owners in the console; a coverage finding clears when hook traffic arrives; no routing to the owner | ✓ |
| A skill allowlist set as policy, and a skill pulled from it after a malicious update | ◐skill drift and poisoning flagged on load; MCP servers approval-gated, skills not | ✓ |
| Risk between agents from different vendors, such as two sharing a data source | ✗per-agent destination and credential maps, no cross-agent finding | ✓ |
| Policy drafted by the product from what it maps | ◐granted-vs-used report recommends removals; policy written by an administrator | ✓ |
| Claude chats, files and projects, for claude.ai organisations | ✗never requested, by design | ✓via the Compliance API |
| In-product guidance for security teams on what agent risk is and how it becomes policy | ◐coaching is for the developer at the point of use | ✓ |
Same capability, different mechanism
Both products do each of these, so the table describes how rather than scoring.
Scroll sideways →
| MoorAI does it by… | Vero does it by… | |
|---|---|---|
| Finding agents nobody registered | An on-device AI bill of materials (moorai-aibom) with a sanctioned/unsanctioned check (moorai-shadow); a console finding for an agent in use with no MoorAI hook traffic; a Compliance API coverage gap for people active in Claude whose devices show no MoorAI coverage; and an alert when an agent launches or installs another agent (#88). |
The inventory: “It enters the inventory with an owner, a credential map, and its installed skills.” (vero.security) Its stated reach: “Claude, Codex, Gemini, Cursor, OpenClaw, and whatever launches next week.” (vero.security blog, Vero + Claude) |
| Owners for agents | Agent ownership in the console: owner, purpose and approval per agent kind, MCP server and AI key at rest, with Ownerless and stale findings. A local coding agent with no explicit owner is owned by the users of the devices it runs on. | Each discovered agent gets an owner, and the posture fix goes to that owner. |
| 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 and Cursor block through their own pre-tool hooks and are not yet validated against the live agents. 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. | “And enforcement means the action is blocked before it executes, not flagged in a dashboard after the data already left.” Enforcement is opt-in: “with enforcement available as an opt-in workflow once your team is ready”. (vero.security blog, Vero + Claude) The mechanism is not public. |
| A skill that turns malicious after it was approved | Skill Analysis fingerprints every skill and instruction file an agent loads: Skill-file drift when it changed since MoorAI last saw it, Skill-file poisoning when the injection detectors fire in it, with no text sent. A destructive command the skill then asks for (#43) is judged at the tool call on its own. |
“The update carries malicious instructions: delete the production database. Vero blocks the call before it executes and pulls the skill from the allowlist.” (vero.security) |
| Claude’s Compliance API | The console reads the Activity Feed, stores it content-free, alerts on Claude admin and configuration changes, lists Claude users whose devices show no MoorAI coverage and shows the organisation’s effective settings next to MoorAI’s policy. It never requests chat, file, project or transcript content. | A full feed: “It enriches what Vero already maps with the Claude-side data points that matter: the activity stream, the directory of users, roles, and groups, and, for claude.ai organizations, the underlying chats, files, and projects.” (vero.security blog, Vero + Claude) |
MITRE ATLAS, as documented. In our reading of vendor material against the 76 ATLAS techniques tagged Agentic AI, Vero’s published material documents 5 of the 76: AML.T0053 AI Agent Tool Invocation, AML.T0081 Modify AI Agent Configuration, AML.T0083 Credentials from AI Agent Configuration, AML.T0101 Data Destruction via AI Agent Tool Invocation and AML.T0103 Deploy AI Agent, each with a limit on what it covers (read 29 October 2026). Most rest on one illustrated scenario, and Vero says enforcement is opt-in without describing how a call is intercepted. The malicious skill update is not credited as a supply-chain rug pull, because what stops it is the blocked call, not a check of the update. Vero’s research posts describe attacks and are not counted. That counts what the public pages say; Vero publishes no product documentation. The method and every quote behind the number are in MITRE ATLAS agentic-technique coverage.
Where MoorAI is stronger. What is inside each action, decided before it runs, with a record that holds no content. 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, on an employee’s machine or in an agent service, and coached, masked or blocked there. A secret is stopped at the file read, before the model sees it; a risky action aimed at something the person never asked about is flagged. Every enforcement point is documented, the agent that does it is MIT, and the console that collects the results receives no prompt, file or chat content, including from Claude’s Compliance API. Enforcing is free on a self-hosted console.
Where Vero is stronger. The agent layer as an estate to manage. Vero puts every agent in one inventory with its owner, credentials and skills, scores its configuration before it runs, sends the fix to the owner and checks it was closed, and turns the findings into a skill allowlist and a policy it drafts. It looks across vendors for agents that combine into a risk neither vendor’s tooling sees, and for Claude it reads the content as well as the activity. It also brings guidance with it: “The platform carries the guidance with it: what a skill actually is, where agent risk lives in your environment, which questions to ask, and how the answers become policy.” (vero.security blog, Vero + Claude) And it does original research on agent runtimes: “We found two exploits in Claude Code's runtime that let an attacker run commands you never approved.” (vero.security blog, Claude Code command approval) For a security team that needs to know which agents it has and who answers for each, Vero covers ground MoorAI does not.
Which to run where. The two meet on discovery, posture and blocking, and part on what they collect. Vero fits where the first need is an inventory of every agent across vendors, with owners, posture fixes, a skill allowlist and a drafted policy, and where reading Claude’s chats and files is acceptable. MoorAI fits where each action must be held to a written, signed policy before it runs, by its content and by the person’s task, in the coding agents on employees’ machines and in agent services, and where nothing an agent reads or writes should reach a console. Nothing in either’s public material says they conflict, and we have not run them together.
Questions about MoorAI and Vero Security
What is Vero Security?
Vero Security describes itself as an Agent Detection and Enforcement platform that maps every agent and stops risky and forbidden actions. It inventories the agents in an organisation with an owner, a credential map and their installed skills, runs a posture scan of each agent’s configuration and sends the fix to the owner, detects actions in flight, and enforces a policy drafted by Vero at runtime. It connects to Anthropic’s Compliance API for Claude Platform and Claude Enterprise.
Does Vero block a coding agent’s action before it runs?
Vero says enforcement means the action is blocked before it executes, and that enforcement is an opt-in workflow. Its public material does not say where the block happens, which agents it reaches or how it attaches to them; there is no public documentation, and the product requires a login. MoorAI blocks in the coding agent’s own PreToolUse hook (Claude Code, Codex, Copilot CLI, Gemini CLI, Cursor; validated end to end on Claude Code), in an MCP stdio proxy, and on AI servers through server mode, the Agent SDK, the moorai-serve sidecar, the MCP gateway and the model proxy.
What does each read from Claude’s Compliance API?
Vero ingests the activity stream, the directory of users, roles and groups, and, for claude.ai organisations, the underlying chats, files and projects; the scopes it asks for include read:compliance_user_data. The MoorAI console reads only the Activity Feed, the organisation’s effective settings and, if enabled, session metadata, stores them content-free, and never requests chat, file, project or transcript content.
Does MoorAI replace Vero Security, or the other way round?
Not cleanly. Vero is built around the organisation’s agent inventory: who owns each agent, what its configuration allows, which skills it may use, and combinations of agents across vendors, with Claude’s content read through the Compliance API. MoorAI is built around each action: the file read, command, MCP call or model call is checked against a signed policy before it runs, where the agent runs, and the console receives no content. They overlap on discovery, posture and blocking; we have not run them together.
Is Vero Security’s documentation or pricing public?
No. Vero’s site has no documentation or pricing page, its product requires a login, and its pages lead to a demo request. MoorAI’s agent is MIT and documented in its public repository, and its console is free to self-host with no user limit.
Vero capabilities are taken from Vero’s own published material, checked on 29 October 2026: vero.security and the blog posts Vero + Claude: Officially Integrated, The Commands You Approved Are Not the Ones Being Executed, Your AI Agents Are Leaking Secrets and Your Agent’s Sandbox Isn’t Private. Vero publishes no product documentation, and its product requires a login and was not read. Every quoted phrase is Vero’s. ◐ = 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 and Cursor block through their own pre-tool hooks and are not yet validated against the live agents. 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. Vero Security is a trademark of its owner; this page is independent and is not affiliated with or endorsed by Vero Security. Both products change, so check specifics against current documentation.