MoorAI vs Rig Security
Last updated
Rig decides by who is acting and what they may reach. MoorAI decides by what the action contains. Rig describes its product as “One platform to see, protect and enforce every identity, for people and AI agents alike.” (rig.security) Its endpoint sensor, Gatewatch, is “Identity-aware local enforcement for developer and AI agent activity.” (rig.security/gatewatch) MoorAI is a PreToolUse hook inside the coding agent and an MCP stdio proxy in front of the tool servers. It reads the prompt, the file read into context, the shell command and the Model Context Protocol (MCP) arguments and results, and coaches, masks or blocks on what it finds.
Both decide on the device, before a coding agent’s action runs. Gatewatch: “Five steps on the device, before the action runs.” (rig.security/gatewatch) Rig’s launch post: “It can block a risky agent action before it reaches the cloud without disrupting the person whose identity the agent borrowed.” (rig.security, Why We Started Rig) The illustrated examples on Rig’s pages are about scope: an agent approved for AWS dev and stopped at AWS production, a bulk Salesforce export, a company-wide Workday pull. MoorAI’s rules are about content: a .env read into the agent’s context, a secret in an MCP argument, a destructive command, an upload to a host the user’s request never named. MoorAI decides against a 77-threat matrix and by default sends only category · risk · keyed one-way hash.
Rig covers far more identity ground than MoorAI does. In Rig’s words, it “brings Identity Security Posture Management and Identity Threat Detection and Response together across human, machine, and AI identities” (rig.security, Why We Started Rig): one person’s accounts correlated across systems, service accounts and tokens traced to an owner, attack paths, least privilege and threat detection. MoorAI does none of that. The rows where Rig covers more ground are further down.
Three things this page does not state. (1) What Gatewatch reads inside an action. Rig publishes no product documentation (docs.rig.security does not resolve). Its Gatewatch diagram lists “Tool calls · sessions · prompts · outcomes” as inputs and a step called “AI and MCP action interpretation,” but whether that looks at the content of a command or an argument is not described, so the tables mark it unconfirmed rather than absent. (2) Which agents and operating systems Gatewatch supports. Rig names employee endpoints, Linux and Kubernetes nodes, and publishes no list of agents. (3) Pricing. We found no public price list; Rig’s pages lead to a demo request. Every Rig statement below is quoted from Rig’s own site, and the page is named.
The core difference is the axis of the decision: who is acting and what they may reach, or what the action carries.
.env in the dev repo and pastes it into an MCP call to an approved service, and another that runs an ordinary-looking command against production through a borrowed session. Rig’s published examples are of the second kind; MoorAI’s rules are written for the first. MoorAI’s nearest equivalent to an identity rule is the entitlement envelope, which bounds an agent’s tools, path prefixes and MCP servers and knows nothing about cloud identities.Where MoorAI holds ground Rig does not
These rows follow from reading the content of each action on the machine, with nothing sent anywhere to decide. Most Rig marks here are unconfirmed, because Rig publishes no product documentation.
Scroll sideways →
| MoorAI | Rig | |
|---|---|---|
| Scans the content of prompts, files read, shell commands, MCP arguments and results, and output | ✓on-device threat matrix | —not in public material |
| Blocks a secret at the file read, before it enters the model’s context | ✓hooks the agent's file-reading tools | — |
| Masks a secret or PII span and lets the call proceed | ✓mask action | —actions published: allow, block, alert |
| 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; lexical, keyed hashes | —"Intent + tool + target"; method not public |
| By default only category · risk · keyed one-way hash leave the device | ✓capture tiers are opt-in, admin-enabled | —evidence recorded for every decision; contents not public |
| Open source, so the data claim can be checked in code | ✓agent MIT | ✗proprietary, under an end-user licence agreement |
| Public product documentation, no demo call | ✓ | ✗docs.rig.security does not resolve |
| Free to start and to enforce, without talking to sales | ✓agent free; console free to 200 users | ✗no public pricing; demo-led |
Where Rig covers ground MoorAI does not
This list is longer. Rig is an identity security platform for people, non-human identities and AI agents, across identity providers, cloud, SaaS, code and the endpoint. MoorAI governs what coding agents do on endpoints, and it has no identity graph.
Scroll sideways →
| MoorAI | Rig | |
|---|---|---|
| Resolves each account, token and agent across systems to the human behind it | ✗ | ✓RICE correlation engine |
| Non-human identity security: service accounts, workloads and tokens traced to an owner | ✗ | ✓ |
| Identity posture and attack paths across identity provider, cloud, SaaS and code | ✗ | ✓ |
| Least-privilege remediation of human and machine access, with what-if analysis before a change | ✗the entitlement envelope bounds an agent's tools, not anyone's access | ✓ |
| Identity threat detection and response: scattered sign-in and privilege signals joined into one attack | ✗ | ✓ |
| Tells an agent’s activity apart from the person whose cloud session it uses | ◐knows the agent and a keyed device actor, not the cloud identity | ✓ |
| Enforcement keyed to the cloud or SaaS resource an agent reaches, such as production vs dev | ◐tools, paths, hosts and MCP servers; no cloud resource model | ✓ |
| Agentless deployment through connectors to existing systems | ✗endpoint agent required | ✓ |
| Agents for Kubernetes nodes and an Amazon Bedrock AgentCore integration | ✗ | ✓ |
Same capability, different mechanism
Both products do each of these, so the table describes how rather than scoring.
Scroll sideways →
| MoorAI does it by… | Rig does it by… | |
|---|---|---|
| Stopping a coding agent’s action before it runs | 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 sensor on the device with “OS-integrated activity capture” across “Browsers, terminals, CLIs, SDKs and MCP,” then an “Embedded local policy decision.” The decision is to allow, block locally, or alert and preserve evidence. (rig.security/gatewatch) |
| Discovering agents on devices | An on-device AI bill of materials: models, MCP servers, editor extensions, running local model servers and AI keys at rest, checked against your allow-list. | A sensor that “discovers agents running on devices, distinguishes their sessions from the user’s own activity, and enforces policy inline,” (rig.security, Why We Started Rig) tied back to the human through the identity graph. |
| Least privilege for agents | An entitlement envelope per agent: authorised tools, path prefixes and MCP servers. An action outside it is flagged as entitlement drift and alerted or blocked. A per-agent destination map records which hosts and MCP servers each agent actually reached. | Scope on the identity the agent uses, as in Rig’s example of an agent approved for dev and blocked at production, and access removal across identities: “Keep the access people use. Remove the access nobody needs.” (rig.security) |
| Evidence of a decision | A signed, content-free decision receipt per verdict (tool, category, risk, decision and one-way hashes, signed with ed25519) and a hash-chained on-device log. | “One policy, identity, and evidence plane across every agent execution environment.” (rig.security/gatewatch) What a preserved evidence record contains is not in Rig’s public material. |
MITRE ATLAS, as documented. In our reading of vendor material against the 76 ATLAS techniques tagged Agentic AI, Rig’s published material documents 2 of the 76, AML.T0053 AI Agent Tool Invocation and AML.T0103 Deploy AI Agent, both with a limit on what they cover (read 1 October 2026). That counts what the documentation says. With two product pages and no product documentation, the count reflects how little Rig has published, not a test of the product. The method and every quote behind the number are in What vendors actually document against MITRE ATLAS.
Where MoorAI is stronger. What is inside the action. The file read, the shell command, the MCP argument and result, the prompt and the output are read on the device and coached, masked or blocked there. The console receives no content, the code that guarantees that is MIT, and it is free to enforce up to 200 users.
Where Rig is stronger. Who is acting, and what they can reach. One identity graph across identity providers, cloud, SaaS and code; owners for service accounts and tokens; attack paths; least-privilege remediation with what-if analysis; identity threat detection and response; and an agent told apart from the person whose session it borrows, stopped at a resource while the person keeps working, on laptops, servers and Kubernetes nodes. If the job is identity security, Rig is the larger product and MoorAI is not one.
Which to run where. Run Rig where the question is identity: which people, service accounts and agents hold which access across your systems, and whether an agent acting through someone’s session should reach a given resource. Run MoorAI on developer machines where the question is content: what a coding agent is about to read, run or send, and where the record should hold no prompt content. The two decide on different axes. Nothing in either’s public material says they conflict on one machine, and we have not run them together.
Questions about MoorAI and Rig Security
Does Rig Security inspect the content of prompts and tool calls?
Rig’s public material does not say. Its Gatewatch page lists tool calls, sessions, prompts and outcomes as inputs and describes AI and MCP action interpretation, and its examples are about which identity and resource an agent reaches. Rig publishes no product documentation. MoorAI scans prompts, files read, shell commands, MCP arguments and results, and output on the device.
Can Rig Security block a coding agent’s action before it runs?
Yes, per Rig: Gatewatch decides on the device before the action runs, and Rig says it can block a risky agent action before it reaches the cloud without disrupting the person whose identity the agent borrowed. MoorAI blocks through a PreToolUse hook and an on-device MCP proxy once a device is enrolled in a MoorAI console.
Does MoorAI replace Rig Security, or the other way round?
No. Rig is an identity security platform that combines identity posture management and identity threat detection and response across human, machine and AI identities. MoorAI does none of that. MoorAI inspects what a coding agent’s actions contain and coaches, masks or blocks on the device. They answer different questions.
What does each send off the device?
MoorAI sends a category, a risk level and a keyed one-way hash by default, and keeps content only if an administrator enables a capture tier. Rig describes one policy, identity and evidence plane across every agent execution environment, with evidence recorded for every decision; what that evidence contains and where it is kept is not in its public material.
When did Rig Security launch, and who backs it?
Rig came out of stealth on 29 September 2026 with $12 million in seed funding, co-led by Ten Eleven Ventures and Brightmind Partners, with strategic participation from the CrowdStrike Falcon Fund and backing from security founders including Wiz co-founder Ami Luttwak.
Rig capabilities are taken from Rig’s own published material, checked on 1 October 2026: rig.security, rig.security/gatewatch, rig.security/partners, Why We Started Rig and AI Is Breaking Identity Security. The launch date and the CrowdStrike Falcon Fund are from Ten Eleven Ventures’ announcement. Rig publishes no product documentation. Every quoted phrase is Rig’s. The animated demo decisions and the environments Rig labels illustrative are interface, not claims, and are not scored. ◐ = 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 and Windows; the console is source-available under the Elastic License 2.0 and free up to 200 users. Rig Security is a trademark of its owner; this page is independent and is not affiliated with or endorsed by Rig Security. Both products change, so check specifics against current documentation.