Frequently asked questions

Yes — it supports your obligations, without claiming to certify them. The EU AI Act expects organizations to know how AI is used, keep records, and apply human oversight. MoorAI produces content-free usage records — which rule fired, the risk level and a keyed one-way hash per event (plus the login and hostname, which the console pseudonymises on arrival) — plus a control-mapping to the frameworks auditors reference (NIST AI RMF, ISO/IEC 42001, OWASP LLM Top 10, MITRE ATLAS). Its coach / alert / block / require-justification flow is human-oversight enforcement at the point of use. That gives you evidence and an audit trail that support and evidence EU AI Act obligations — MoorAI does not certify, guarantee, or by itself make you compliant, and it is not legal advice. It's control-mapping and records, not certification.

MoorAI is runtime guardrails for AI agents, apps and APIs: coding agents such as Claude Code, Codex, Copilot CLI, Gemini CLI and Cursor, Agent SDK services, any agent framework through a localhost sidecar, remote MCP servers through an MCP gateway, and model API calls through a model proxy. On the developer's machine, it checks prompts, file reads, shell commands and MCP tool calls before they reach the model or run, and shows what it flagged and the safer way. On a device enrolled in a management console (free self-hosted, no user limit) it enforces per policy: coach, alert, block, require a justification or end the agent session. Without enrollment it coaches only and sends nothing anywhere. On an enrolled device the console receives only a category, a risk level and a keyed one-way hash (plus the login and hostname, which the console pseudonymises on arrival), never the prompt, the file or the matched text. Enforcement is validated on Claude Code; the other agents block through their own pre-tool hooks and are not yet validated end to end against the live agents. The community agent is free and open source (MIT).

Where the check happens. Many tools in this space sit in the network, the browser or the cloud, or inspect content by sending it to their own service. MoorAI checks the action itself (a file read, a shell command, an MCP tool call or a model call) where the agent runs, and by default only content-free signals leave the machine. Your security team gets the check without sending source code or secrets to another vendor, MoorAI included. It goes deepest on coding agents and MCP, and the same engine runs in servers and Kubernetes: as Agent SDK hooks, the moorai-serve sidecar, an MCP gateway and a model proxy.

On a machine where the user is an admin, no user-space tool can honestly promise “cannot”. MoorAI separates what it prevents from what it detects, and tests each.

Prevented:

• The policy is an ed25519-signed envelope, verified against a public key in the root-owned /etc/moorai folder. A policy the agent writes itself does not verify, and revoked keys and rollback to an older policy are refused.
• A device latched into fail-closed mode, by MDM or offline mode, keeps enforcing when the enrollment token is removed.
• On an enrolled device, when Claude Code runs with permission prompts bypassed, an action MoorAI would ask about is denied instead.
• On servers and in CI, the hooks sit in Claude Code’s system-wide managed settings, which a repository cannot switch off, and a MOORAI_* setting in a user, project or local settings file is refused and raised as a Critical alert.

Detected: on a laptop, where the hook runs as the user, removing it or weakening a setting is detected, not prevented. A daily, content-free coverage heartbeat reports hooks disabled, the MoorAI hook removed or stale, bypass mode on by default and a sandbox off, and the console raises “agent active, no MoorAI hook traffic”.

About 250 automated tests target tampering: for example, a forged policy is rejected, and deleting MoorAI’s local state does not downgrade the device.

For AI apps, services and APIs, run MoorAI out of the agent’s reach. The moorai-serve sidecar, the MCP gateway and the model proxy run in their own container (ghcr.io/gitayg/moorai-server, as a non-root user), so the agent process cannot edit their policy or files. When the workload’s outbound traffic is restricted so model and MCP calls must go through the model proxy and gateway, the agent cannot route around them. That restriction is your own network policy. See Run it as a sidecar and tamper resistance.

Run curl -fsSL https://raw.githubusercontent.com/gitayg/moorai/main/scripts/install.sh | sh. It installs MoorAI to ~/.moorai and registers its Claude Code hooks; it needs git and Node 18 or later, and no account. For other agents, run node ~/.moorai/cli/moorai-agent-hook.mjs codex install, or copilot, gemini or cursor. The desktop app for macOS and Windows and the Linux package are on the download page. Step by step: quick start.

It can. Depending on the tool and the plan, anything sent to an AI service may be stored, reviewed by humans, or used to train the model — which can surface it to other users as answers. Free and personal accounts are the biggest risk. MoorAI catches sensitive company material before it's sent: with no account it shows you what it caught and the safer way, and on a device enrolled in a MoorAI console it can block the prompt so it never reaches a service that could keep or leak it.

Three steps. First, the prompt is reviewed on the device — checked locally against policy, a 85-threat matrix plus content rules — and the console never receives the prompt unless an administrator turns on a capture tier. Second, MoorAI acts on it: with no account it coaches; on a device enrolled in the console it coaches, alerts, requires sign-off or blocks, per policy, per tenant, per device. Third, the central web console shows posture, device inventory, alerts, and compliance, built from redacted metadata only.

The console never receives your prompts, code or files unless an administrator turns on a capture tier. It receives which rule fired, the risk level and a keyed one-way hash (plus the login and hostname, which the console pseudonymises on arrival), and it pseudonymises the AI-tool account emails a device reports the same way. Teams get posture and compliance without seeing what anyone typed.

Not where the agent runs unattended. In server mode, for CI jobs and containers, MoorAI’s hooks sit in Claude Code’s managed settings, which only managed settings can disable, and a MOORAI_* value that a repository’s settings file sets is refused and reported as tampering. With the Agent SDK the checks run inside your service’s process, and a localhost sidecar and a local MCP gateway serve other agent loops and remote MCP servers. On a developer laptop the hook runs as the user, so the user, or an agent acting as the user, can remove it. That is detected, not prevented: from an enrolled device’s daily posture heartbeat the console flags an agent in use with no MoorAI hook traffic, a weakened setting, or a hook removed or gone stale.

MoorAI is designed to sit in front of the AI agents teams already use, including Claude, Codex, and GitHub Copilot. Depth differs by agent. On Claude Code, MoorAI hooks the agent's PreToolUse path, where blocking is validated end to end, so it actively blocks a file read or an MCP tool call that would pull secrets or PII into the model's context. Codex, Copilot CLI, Gemini CLI and Cursor get the same checks through their own pre-tool hooks, and the adapters return a real deny; they are tested against each vendor's documented hook payloads and have not yet been run end to end against the live agents. On Codex the hook blocks once the user has trusted it in Codex, and a confirmation becomes a deny because Codex hooks cannot prompt. Prompt-stage review works across all of them. Blocking applies on devices enrolled in a MoorAI console; without enrollment the same checks coach instead.

Most guardrails only look at what a person types. A coding agent also reads files on its own, and a single .env can carry a dozen live credentials straight into the model's context without anyone typing a character. MoorAI hooks the agent's Read tool, plus conservative file-reading Bash, and inspects mcp__* tool-call arguments, so that content is checked before it becomes context. It runs on-device, reports content-free, and by default fails open — if the check can't run, work continues, unless an administrator has set it to fail closed. This is governance, not a sandbox: it's built to stop mistakes and give you an accurate record, not to contain a determined attacker with local code execution.

By default, no. Review happens on the device and content stays there — that's the key difference from cloud DLP: MoorAI keeps the actual prompts and conversations local, and only redacted metadata is shared upstream. Three exceptions you control: an administrator can enable a capture tier, which stores the matched text it was turned on to collect; in the desktop app, where the operating system cannot read an image, a pasted image can be sent to Anthropic’s API with an Anthropic API key already on the device, direct from the device and never through MoorAI; and an administrator can turn on a model second opinion whose provider setting sends the text of an ambiguous scan to Anthropic’s API the same way, when no local model answers.

The community agent runs with no account required and coaches: it shows what it flagged and the safer way, and never blocks. Enrolled in the management server's console (free self-hosted, no user limit), it enforces policy: block, sign-off, session kill. It's open source under MIT, for macOS, Windows and Linux, with a desktop app for macOS and Windows (Rust + a Tauri native host and webview detection core). Centralized fleet management — a multi-tenant console, SSO, and compliance reporting — is a separate MoorAI management server, source-available under the Elastic License 2.0.

The community agent is open source under MIT and runs with no account required, coaching on every risky action. The code is on GitHub. The centralized management server is a separate product, source-available under the Elastic License 2.0, which is not an open-source licence.

Never. MoorAI reads only the account name/identity for reporting, and never the credential.

Yes — set your corporate email domains and any agent account on another domain is flagged as personal.

Yes. MoorAI’s MCP proxy scans each server’s tool listing for injected instructions, invisible characters and descriptions that ask the model to read or send a credential file; it flags servers whose launch config pipes remote code to a shell; and a tool whose description or schema changed since approval is reported, or removed and refused when the policy blocks drift. More: MCP security.

Yes, through the moorai-serve sidecar: your loop sends each tool call to POST /v1/tool-call on 127.0.0.1:8790 before running it and does what the answer says. A stdlib-only Python client with LangGraph and CrewAI examples is in the repository; those examples have not been executed. The model proxy also judges the tool calls in the model’s response, whether or not the framework asks.

Yes, through the model proxy. A local OpenAI-compatible server (Ollama, LM Studio, llama.cpp server or vLLM) is a route to its loopback /v1 endpoint, and every tool call in the model’s response is decided before the framework receives it. It is tested against a fake local server only, and Ollama’s native API is not parsed.

No. For HTTPS it sees a CONNECT tunnel and judges host and port only, so method and path rules apply to plain HTTP. The SNI and Host inside the tunnel are not checked, so domain fronting through an allowed CDN host passes.