// moorai vs hush security

MoorAI vs Hush Security

Last updated 2026-10-28

Hush decides who an agent is, whose permissions it carries and which credential it gets. MoorAI decides by what the agent’s action contains. Hush describes its product as follows: “Hush gives every agent its own identity and delegated permissions. Every action centrally governed, scoped to the task, and revoked when done.” (hush.security) Its enforcement point for tool calls is a gateway: “The Hush MCP Identity Gateway intercepts every tool call in transit, evaluates it against access rules, applies consent workflows where required, and logs the result.” (Hush docs, Identity Gateway overview) MoorAI is runtime security for AI agents on endpoints and AI servers: a PreToolUse hook inside the coding agent and an MCP stdio proxy in front of its tool servers on employee machines, and, for agents that run as production services, server mode of the hook, an in-process SDK, a localhost sidecar, an MCP gateway and a model proxy. 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 can stop a tool call before it runs, on different evidence. Hush’s gateway checks three things: whether the user is assigned to the application, whether the tool is allowed, and whether the agent’s MCP client is on the application’s allowlist. Its defaults go by the kind of tool: “Write tools can modify data and default to Consent - the user must approve each call before it executes.” and “Destructive tools can delete or irreversibly alter data and default to Block - they cannot be used unless the policy is explicitly changed.” (Hush docs, Identity Gateway overview) MoorAI’s rules go by content: a .env read into the agent’s context, a secret in an MCP argument, an injected instruction in a tool result, an upload to a host the user’s request never named. MoorAI decides against a 85-threat matrix and by default sends only category · risk · keyed one-way hash (plus the login and hostname, which the console pseudonymises on arrival).

Hush covers agent identity and access, which MoorAI does not. From Hush’s own funding announcement: “Every agent is enrolled in a central registry, stripped of standing credentials and granted scoped just-in-time (JIT) permissions at runtime – every action logged, with a centralized kill switch when needed.” (hush.security, Series A release) Every agent has a named owner: “Mandatory human ownership – no agent exists in the directory without an accountable owner attached” (hush.security, Agent Identity Governance). The same platform discovers and governs the secrets, service accounts and certificates behind those agents. MoorAI records an owner for each agent kind and bounds what each agent may touch, but it issues no credentials and brokers no access. The rows where Hush covers more ground are further down.

Hush says plainly which half it works on. Its CEO’s post: “Most of the security conversation is about agent behavior: guardrails, prompt injection, what the model is allowed to say.” It calls that real but half the problem, and puts Hush on the other half, the identity every agent runs on. (hush.security blog, AI Agents Don’t Have a Behavior Problem) That half is where MoorAI does not work, and the content of what an agent reads, runs and sends is where Hush does not. Every Hush statement below is quoted from Hush’s own site or documentation, and the page is named.

The core difference is what the decision is keyed to: the identity and permissions behind a call, or what the call carries.

01What does each decide on?

Hush resolves access from two identities at once, the agent’s and the user’s: “The solution is what we call an effective access policy: an access decision resolved from the combination of the agent’s verified identity and the authenticated user’s identity claims.” (hush.security blog, Introducing Effective Access Policies) Its home page puts it this way: “Hush combines the agent's approved boundaries with the permissions of the human it is acting for, then enforces the result per action.” (hush.security) The question it answers is whether this agent, acting for this person, may use this tool on this resource. MoorAI’s question is whether this command, file, argument or result carries a secret, PII, an injected instruction, a destructive operation, or a target the user’s own request never named. Consider an approved agent, acting for a user who may read the repository, that reads a .env and pastes its key into a call to a tool the user may also use. Every identity check passes; MoorAI’s rules are written for that call. Now consider an agent tricked into querying another region’s customer data: Hush’s effective access bounds it to what the user may see, and MoorAI has no model of the user’s data permissions.

02Which tool calls does each see?

Hush sees the calls routed to it. “No code changes. Route traffic through Hush and access is secured at runtime, without modifying your agents, your servers, or the way they already connect.” (hush.security/platform) Its docs state the edge of that: “An agent connecting to an MCP server directly bypasses every control: no access policy, no consent workflow, no audit trail.” (Hush docs, Applications) Hush’s material describes MCP tool calls and brokered credentials; it does not describe a coding agent’s built-in shell commands or file reads. MoorAI sits in the agent’s own process, so it sees the built-in tools as well as MCP: the shell command, the file read and written, the fetched page, the MCP call. It has its own remote MCP gateway too (moorai-mcp-gateway), which checks the content of each call. The difference is measurable: against a 12-action malicious set, MoorAI’s MCP proxy refused all 12 while enforcing, yet only 4 of the 12 travel over MCP at all; the other eight reach the machine through the agent’s built-in tools, where the hook is the control. Hush decides at a gateway the agent connects to; MoorAI decides where the agent runs, on the machine or in the service, before the call leaves it.

03Where are the credentials?

Hush keeps them off the agent: “Hush brokers short-lived credentials at runtime, scoped to the action and gone when the task ends. No long-lived keys in dotfiles, IDE configs, or agent memory.” (hush.security) For workloads it builds, its SDK requires two identities before anything is issued: “Two things must be true simultaneously before credentials are issued: the workload must be attested, and a human must be authenticated.” (Hush docs, Effective Identity via SDK and User Claims) MoorAI issues no credentials. It watches the ones that exist: it fingerprints local secret values as keyed one-way hashes and blocks a command or tool call that carries one out, verbatim or encoded (base64, hex, percent-encoding, reversed and more). Its model proxy and MCP gateway can hold the real key behind a placeholder (opt-in), swapping it in only on the route the placeholder is bound to, and the key itself stays as long-lived as it was.

04What is recorded, and where?

Hush logs each call at its gateway: “Every tool call through the gateway produces a structured log entry: the user, the agent, the application, the tool, the outcome, and the timestamp.” (Hush docs, Identity Gateway overview) The gateway runs in Hush’s cloud or in yours: “Hosted by Hush runs the gateway as a managed service in a region you pick - there is nothing to install, and Hush operates and upgrades it.” On-prem, it runs in your own Kubernetes cluster. (Hush docs, Identity Gateway Deployment) Its trust page states: “Privacy-first - No customer code or payload data is stored on Hush Cloud.” (Hush docs, Trust, Security and Compliance) MoorAI’s console receives which rule fired, the risk and a keyed hash, plus the login and hostname, which the console pseudonymises on arrival. Each verdict also gets a signed, content-free decision receipt on the device.

✓ yes ◐ partial — unconfirmed ✗ no

Where MoorAI holds ground Hush does not

These rows follow from reading the content of each action inside the agent, on the machine or in the service. Most Hush marks here are unconfirmed: its public material does not describe content inspection either way.

	MoorAI	Hush
Scans the content of prompts, files read, shell commands, MCP arguments and results, and output	✓on-device threat matrix	—decisions keyed to user, tool and client
Governs a coding agent’s built-in shell commands and file reads, not only its MCP calls	✓PreToolUse hook	—material describes MCP calls through the gateway
Blocks a secret at the file read, before it enters the model’s context	✓hooks the agent's file-reading tools	—
Detects prompt injection in what comes back into the agent	✓command output, MCP results, fetched pages	—Hush calls it the other half of the problem
Masks a secret or PII span and lets the call proceed	✓mask action	—actions published: allow, consent, block
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	—
Decides in the agent’s own process, on the developer’s machine or in an Agent SDK service	✓	✗at a gateway, hosted by Hush or on-prem Kubernetes
Open source, so the data claim can be checked in code	✓agent MIT	✗no platform source published; Helm charts, Terraform provider and agent skills are on GitHub
Free to enforce with no cap on agents or users	✓console free self-hosted, no user limit	◐free for the first 25 agents

Where Hush covers ground MoorAI does not

This list is longer. Hush is an identity and access platform for AI agents and the non-human identities they run on, across cloud, SaaS, Kubernetes and managed endpoints. MoorAI governs what AI agents do, on endpoints and on AI servers, and it issues no identities or credentials.

	MoorAI	Hush
A registry of agents, each with its own identity and a mandatory human owner	◐owner, purpose and approval per agent kind, MCP server and AI key	✓
Short-lived credentials brokered per task in place of an agent’s static keys	✗issues no credentials; opt-in placeholders hide a real key behind its proxy	✓
Permissions resolved from the agent’s identity and the user’s identity-provider claims together	✗	✓effective access
One switch that revokes an agent’s access everywhere	◐kills a running session on a critical finding; no credential to revoke	✓central kill switch
Discovers agents and MCP servers on cloud agent platforms, in SaaS and in Kubernetes	✗on-device inventory only	✓
Discovers agents without installing anything on the developer’s machine	✗endpoint agent required	✓cluster sensor, cloud and SaaS APIs, an MDM script
Non-human identity security: secrets, service accounts and certificates found at runtime, owned and replaced with identity-based access	✗	✓
Cloud roles and permissions behind each identity across AWS, GCP and Azure	✗	✓Entitlements
A request queue for a user whose agent cannot reach an application	✗approvals cover held calls, not access requests	✓User Requests

Same capability, different mechanism

Both products do each of these, so the table describes how rather than scoring.

	MoorAI does it by…	Hush does it by…
Stopping a tool call 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, and `moorai-mcp-gateway` sits in front of remote MCP servers. Blocking applies once the device is enrolled in a MoorAI console.	The MCP Identity Gateway, which an agent reaches at its own endpoint instead of the tool’s. It checks the user’s assignment, the tool’s policy and the agent’s client: “The Agents tab on each application defines which MCP client types can connect - Claude Desktop, Claude Code, Cursor, and others.” (Hush docs) Its release notes for July 2026: “Hush AI Gateway moves into Beta this release.”
Asking a person before a call runs	An ask verdict holds the call for sign-off on an enrolled device. Just-in-time approval routing (Claude Code) sends selected held calls to an approver group: the call is denied at once with a request id, and the identical call is allowed only after an approve grant arrives inside the signed policy.	Consent by default on every write tool, approved by the user whose agent is acting, plus a request queue for access a user does not yet have. “Allow, block, or require approval on any action. No static keys to steal, nothing to install.” (hush.security, Agent Identity Governance)
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. The console’s granted vs used view lists the grants each agent never used and can narrow the policy to what was used.	Effective access, which scopes the agent to the user it acts for, plus per-tool policy at the gateway and, for cloud identities, “Hush Entitlements provides visibility into cloud roles, policies, and permissions across AWS, GCP, and Azure.” (hush.security blog, You Found the Agent)
Discovering agents	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.	Passive discovery: “Hush detects agents and MCP servers active in your environment through runtime observation and API integration - without requiring you to register anything manually.” (Hush docs, Discovery) In clusters, a sensor that “observes at the operating system level. Applications are not modified, nothing needs an SDK, and no traffic routes through it.” (hush.security blog, Agents Should Show Up in Inventories) On laptops, in Beta: “Hush can now discover AI agents and coding tools installed directly on any endpoint managed by the organization's MDM.” (Hush release notes, September 2026)
Agents that call other agents	Sub-agent and A2A oversight: records each delegation, scans the delegated prompt for injection, and applies the parent’s entitlement envelope to the child.	Agent-to-agent connections in the inventory: “Discovery surfaces these relationships so that the chain of delegation is visible and the human origin of any action can be traced.” (Hush docs, Identity Gateway overview)
Evidence of what an agent did	A signed, content-free decision receipt per verdict (tool, category, risk, decision and one-way hashes, signed with ed25519), a hash-chained on-device log, and `moorai-trace` to rebuild the action chain from it.	A gateway log entry per tool call naming the user, agent, application, tool and outcome, with session IDs that group one agent session’s calls.

MITRE ATLAS, as documented. In our reading of vendor material against the 76 ATLAS techniques tagged Agentic AI, Hush’s published material documents 9 of the 76, all nine with a limit on what they cover (read 28 October 2026): AML.T0053 AI Agent Tool Invocation, AML.T0086 Exfiltration via AI Agent Tool Invocation and AML.T0101 Data Destruction via AI Agent Tool Invocation at its gateway; AML.T0083 Credentials from AI Agent Configuration and AML.T0085 Data from AI Services through brokered, user-scoped credentials; and AML.T0103 Deploy AI Agent, AML.T0118 Autonomous AI Agent Communication, AML.T0132 Misconfigured or Publicly Exposed AI Services and AML.T0010 AI Supply Chain Compromise in its discovery inventory. 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. What is inside the action. 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 a production agent service, and coached, masked or blocked there, including the coding agent’s built-in tools that never pass through an MCP gateway. In a service, a high-impact tool call is held to the person’s task and the service to its declared workload profile. The console receives no content, the code that guarantees that is MIT, and enforcing is free on a self-hosted console.

Where Hush is stronger. Who the agent is, and what it is allowed to hold. A registry in which every agent has an owner; credentials brokered for the task and gone when it ends, so an agent has no standing key to leak; access resolved from both the agent and the user it acts for; one switch to cut an agent off; discovery across cloud agent platforms, SaaS, Kubernetes and managed endpoints; and the secrets, service accounts and cloud permissions underneath. In Hush’s words: “When each agent has a single verified identity, revoking it cuts off all access instantly, everywhere, in one action.” (hush.security blog, AI Agents Don’t Have a Behavior Problem) If the job is agent identity and access, Hush is the product and MoorAI is not one.

Which to run where. Run Hush where the question is identity: which agents exist, who owns them, which credentials and permissions they hold, and whether an agent acting for this person should reach this application at all. Run MoorAI on the AI agents themselves, on employee endpoints and on AI servers (server mode in CI jobs and containers, the Agent SDK, the moorai-serve sidecar, the MCP gateway and the model proxy), where the question is content: what an agent is about to read, run or send, and where the record should hold no prompt content. A coding agent can use Hush’s gateway for its MCP applications while MoorAI’s hook checks every call before it leaves the machine. The two decide on different evidence. Nothing in either’s public material says they conflict, and we have not run them together.

Questions about MoorAI and Hush Security

Does Hush Security inspect the content of prompts and tool calls?

Hush’s public material does not say it does. Its MCP Identity Gateway decides on whether the user is assigned to the application, whether the tool is classed read, write or destructive, and whether the MCP client is on the allowlist, and its CEO calls guardrails and prompt injection the other half of the problem. MoorAI scans prompts, files read, shell commands, MCP arguments and results, and output where the agent runs, on the device or on an AI server.

Can Hush Security block an agent’s tool call before it runs?

Yes, for the MCP tool calls an agent sends through its gateway: read tools are allowed, write tools wait for the user’s consent and destructive tools are blocked by default, each adjustable per tool. Hush’s docs say an agent connecting to an MCP server directly bypasses every control, and the gateway entered Beta in July 2026. MoorAI blocks in the agent’s own process through a PreToolUse hook and an MCP proxy once a device is enrolled in a MoorAI console. On AI servers it decides in server mode, in the Agent SDK, at the moorai-serve sidecar, and at its MCP gateway and model proxy.

Does MoorAI give AI agents their own identities and credentials?

No. MoorAI’s console records an owner, a purpose and an approval state for each agent kind, MCP server and AI key, and each agent’s tools, paths and MCP servers can be bounded by an entitlement envelope, but MoorAI issues no credentials and brokers no access. Hush registers each agent with a mandatory human owner and brokers short-lived credentials scoped to the task in place of static keys.

Are Hush Security and MoorAI alternatives to each other?

Mostly not. Hush decides whether an agent, acting for this user, may reach this tool and with which credential, and keeps the credential off the agent. MoorAI decides whether what an agent’s command, file read, MCP call or model call carries is safe, where the agent runs, on an endpoint or an AI server. Hush’s gateway sees the MCP traffic routed to it; MoorAI sees a coding agent’s own shell, file and MCP calls, and a service’s tool calls through its SDK, sidecar, gateway and proxy. We have not run them together.

What does each cost?

Hush has a free tier for the first 25 agents and 50 access policies, with no credit card or sales call; we found no public price beyond it. The MoorAI agent is free and MIT licensed, the console is free to self-host with no user limit, and it is paid when MoorAI hosts it.

Hush Security capabilities are taken from Hush’s own published material, checked on 28 October 2026: hush.security, hush.security/platform, Agent Identity Governance, Hush Free, the Series A release on Hush’s site, the blog posts Introducing Effective Access Policies, Agents Should Show Up in Inventories, AI Agents Don’t Have a Behavior Problem and You Found the Agent, and the documentation pages Identity Gateway overview, Applications, Discovery, Identity Gateway Deployment, Effective Identity via SDK and User Claims, Trust, Security and Compliance and the release notes for July and September 2026. Hush’s documentation is public and rendered by JavaScript. Every quoted phrase is Hush’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. Hush Security is a trademark of its owner; this page is independent and is not affiliated with or endorsed by Hush Security. Both products change, so check specifics against current documentation.

See how MoorAI works → MoorAI vs Rig Security → MoorAI vs Runlayer → Compare MoorAI vs the field → GitHub ↗