MoorAI vs Runlayer
Last updated
Runlayer inspects agent activity in its control plane; MoorAI inspects it on the device and sends only a category, a risk level and a keyed one-way hash. Both put a hook inside the coding agent. The difference is where the content goes once the hook fires.
Runlayer is an AI control plane for the enterprise. Its core is a governed MCP gateway that sits in the request path between AI clients and MCP servers, and authenticates, authorizes, scans and logs each request. Around it sit a catalog of approved connectors, skills and plugins, identity-scoped policies tied to Okta or Entra, an OAuth broker, an LLM gateway with spend budgets, and tools for building and hosting internal MCP servers and agents. Its AI Watch package, rolled out through MDM, discovers agents, MCP servers, skills and plugins on managed devices and enforces policy through client hooks in a long list of coding agents. Scanning is done by Runlayer’s ToolGuard and AgentGuard models in the Runlayer platform, hosted by Runlayer or self-hosted in your AWS account, and Sessions record prompts, tool calls and responses.
MoorAI is on-device security for AI coding agents. It enforces through a PreToolUse hook inside the agent, an MCP stdio gateway, and a companion browser extension, and evaluates a 67-threat rule base on the machine, with optional escalation to a local model through Ollama. Prompts, files, tool calls, skills and AI output are inspected on the device. The agent is open source (MIT), so you can read the code and check what leaves the device.
Where MoorAI is different
Most of these rows follow from where inspection happens. Runlayer’s endpoint hooks send tool-call content to its platform to be scanned and recorded. MoorAI decides on the device and keeps the content there. The rest are supply-chain and enforcement controls that Runlayer’s public docs do not describe.
Scroll sideways →
| MoorAI | Runlayer | |
|---|---|---|
| Content is inspected on the device; only category, risk and a keyed one-way hash leave it | ✓on-device inspection | ✗hooks send tool inputs and outputs to Runlayer for scanning; Sessions store prompts and responses |
| Threat detection runs on the machine, with no scanning service in the loop | ✓67-threat rule base, local | ✗ToolGuard runs in the Runlayer platform, hosted or self-hosted |
| Model escalation on a local model (Ollama) | ✓opportunistic, on-device | ✗ML scanning is server-side |
| Static pre-install skill scan that never executes the skill, with results kept on the device | ✓moorai scan | ◐Detect risk-classifies skills, uploading up to 1 MB of text per file |
| MCP rug-pull detection — alerts when an approved server’s definition drifts | ✓ | —tool definitions scanned at registration; drift handling not documented |
| Rules-file integrity checks (CLAUDE.md, .cursorrules) | ✓ | — |
| Slopsquat rules for hallucinated package names | ✓ | —Enforce allow-lists npm/PyPI identities; typosquat detection not documented |
| Entitlement envelope — declared tools, paths and MCP servers per agent, alert or block on drift | ✓ | ◐Enforce blocks built-in tool categories and unlisted MCP sources; no per-path rules |
| Named lethal-trifecta detection | ✓ | ◐session-history policy conditions and AgentGuard trajectory checks; no named trifecta detector |
| Kill-on-critical — stops the agent process on a critical finding | ✓ | —blocks the call; process kill not documented |
| Personal vs corporate AI account detection | ✓ | — |
| AIBOM export | ✓ | — |
| Compliance framework mapping in the console | ✓ | ◐findings mapped to MITRE ATLAS; framework crosswalk not documented |
| Open-source endpoint agent (MIT) | ✓ | ◐CLI is Apache-2.0 on PyPI; the platform is commercial |
| Published free tier — hosted console free up to 200 users | ✓ | —no public pricing |
Where the two overlap
A lot. Both hook into the coding agent and decide before the tool runs, both find shadow AI on the endpoint through MDM, and both ship a browser extension for AI chat apps. The mechanism in each row still differs in where the content is evaluated, as the first table shows.
Scroll sideways →
| MoorAI | Runlayer | |
|---|---|---|
| Hook inside the coding agent that decides before a tool call runs | ✓ | ✓ |
| Covers Claude Code, Cursor and Codex | ✓ | ✓ |
| Scans tool output as well as input | ✓ | ✓ |
| Prompt-injection and data-exfiltration detection on tool calls | ✓ | ✓ |
| MCP server allow-list with an approval workflow | ✓ | ✓ |
| Risk analysis of skill content | ✓ | ✓ |
| Shadow AI discovery on the endpoint — agents, MCP servers, skills, plugins | ✓ | ✓ |
| Graduated policy modes, from monitor-only to block | ✓ | ✓ |
| Browser extension that can block prompts in AI chat apps | ✓ | ✓ |
| Fleet rollout through Intune and Jamf | ✓ | ✓ |
| Endpoint enforcement on macOS and Windows | ✓ | ◐docs list both; the AI Watch page says Windows blocking is in development |
| SSO for the console | ✓ | ✓ |
| Audit logs streamed to a SIEM | ✓ | ✓continuous S3 export |
| Tamper-evident audit log | ✓ | ✓ |
| Self-hosted console option | ✓Elastic License 2.0 | ✓your AWS account, ECS or EKS |
Where Runlayer covers ground MoorAI does not
Runlayer is a broader platform. Beyond guarding the endpoint, it runs the path between agents and company systems: which MCP servers exist, who may call which tool with which OAuth grant, what the calls cost, and what internal teams build on top. MoorAI does none of that. It also enforces across more agents today.
Scroll sideways →
| MoorAI | Runlayer | |
|---|---|---|
| Governed MCP gateway in the request path to company systems | ✗local stdio gateway only | ✓ |
| Company catalog of approved connectors, skills and plugins | ✗ | ✓ |
| Identity-scoped tool access — user, group, role, OAuth scope, tool arguments, session history | ◐per-agent entitlement envelope, not identity-scoped | ✓ |
| OAuth broker that holds MCP credentials centrally | ✗ | ✓ |
| Full enforcement across many agents — Cursor, VS Code, Copilot CLI, Gemini CLI, Codex, Windsurf, Goose and more | ◐full enforcement on Claude Code; Codex and Copilot CLI detection-only | ✓ |
| ML threat models, including session-trajectory analysis (ToolGuard, AgentGuard) | ◐rule base plus optional local model | ✓ |
| Full session transcripts for investigation — prompts, tool calls, responses | ✗content stays on the device by design | ✓ |
| Org-wide Claude prompt scanning through Anthropic inference hooks, no install | ✗ | ✓ |
| Visibility into hosted agents (Cursor Cloud Agents, Claude Cowork) | ✗ | ✓monitor-only |
| LLM gateway with spend budgets and usage analytics | ✗ | ✓ |
| Build, deploy and host internal MCP servers and agents | ✗ | ✓ |
Why the ✗ marks against Runlayer are few. Runlayer blocks tool calls in the agent, scans for injection and exfiltration, discovers shadow MCP servers and skills, and ships a blocking browser extension, and the tables credit all of it. The ✗ rows are about where the content is evaluated. Runlayer’s hooks and SDK send tool inputs and outputs to its platform for scanning, and its Sessions keep prompts and responses. Self-hosting keeps that data inside your AWS account, which matters, but it still leaves the developer’s machine. MoorAI evaluates on the device and sends a category, a risk level and a keyed hash.
Where MoorAI is stronger. Keeping content on the device, and the supply-chain checks around the coding agent. MoorAI inspects prompts, files, tool calls, skills and output locally, and its console never receives the content. It adds a static skill scan that never runs the skill, rug-pull drift alerts on approved MCP servers, rules-file integrity checks, slopsquat rules, an entitlement envelope with per-path limits, kill-on-critical, lethal-trifecta detection and AIBOM export. The agent is MIT-licensed, and the hosted console is free up to 200 users.
Where Runlayer is stronger. Breadth, and the path to company systems. Runlayer governs which MCP servers exist, who may call which tool under which OAuth grant, and what it costs, and it gives internal teams a place to build and publish connectors, skills and agents. It enforces in more coding agents today, adds ML scanning with session-level analysis, records full sessions for investigation, and reaches Claude.ai and hosted agents that MoorAI does not cover. MoorAI is not a sandbox, does not map an agent’s credentials or permissions, does not cover SaaS or hosted agents, and is not a network proxy.
Using both. Runlayer fits as the company’s MCP and agent control plane: catalog, identity, OAuth, gateway and spend. MoorAI fits on developer machines where the requirement is that prompt and code content is judged on the device and never sent to a central service, including your own.
Runlayer capabilities are mapped from runlayer.com and docs.runlayer.com (architecture, endpoint modes, Enforce policy, AI Watch FAQ, Detect, browser extension, ToolGuard, AgentGuard, Sessions, audit logs, policies, approvals, OAuth broker, LLM gateway, Anthropic inference hooks, deployment) as of September 2026. ◐ = partial: present but narrower than the other column. — = unconfirmed, not necessarily absent: Runlayer’s public material does not clearly document it. MoorAI marks reflect shipped capability: full enforcement is on Claude Code, with Codex and Copilot CLI detection-only; the agent runs on macOS and Windows, with Linux second-class. Runlayer is a trademark of its respective owner; this page is not affiliated with or endorsed by Runlayer, and both products change, so check specifics against current documentation.