This week’s releases, MoorAI agent v1.14 and v1.15 and console v0.85 and v0.86, answer three questions a security team asks once agents do real work: what happens when the check cannot answer, which agent actions are business decisions, and what an attacker does with the AI already on a machine. Each section says what the control does, why it matters, and where it stops.
Fail mode: the administrator decides
Any check sometimes cannot reach a verdict: its engine throws, it runs past its decision budget, or it cannot read the input. In MoorAI, what happens next is an administrator’s setting, per surface: the coding-agent hook, the model proxy, the MCP guard and gateway, and the Inference hooks server each fail open or fail closed.
The setting lives in the signed console policy or the root-owned machine config, never in a file the agent can write. Every fail-closed refusal raises a content-free FAIL_CLOSED alert, and the console’s Inventory and Coverage views show each device’s effective mode, flagged when it fails open against a policy that asks for closed. An operator-signed break-glass marker can turn a hook’s fail-closed deny back into an allow, so a hook fault cannot lock a fleet out. Malformed hook input never crashes the hook: a number is judged as text, and an object in a judged field is unreadable, denied when the hook fails closed.
Why it matters. Open or closed is an availability decision, and it belongs to the people accountable for it. A developer laptop can live with an unchecked call; an engineering workstation next to a controller should not.
Limit. On the coding-agent hook only the pre-tool check fails closed; post-tool scans, prompt checks and logging still fail open.
Business actions and the Industrial / OT preset
A refund, a password reset and a dropped table look alike to a tool-call check. The model proxy classes plain function calls by the words in their name: money (issue_refund), bulk data, identity (reset_password), destructive (drop_table) and delegation. Lookups such as get_refund_status are not classed. Each class alerts by default, a signed policy sets it to allow, ask or block, and alerts carry the class and function name, never an argument. The proxy also judges an application’s own system prompt like any request content; a signed policy can make personal-data findings there report-only, but never secrets.
The console’s Policy view edits the classes and the fail mode. The Regulated preset asks before money, identity and destructive changes, blocks bulk export and fails closed. The Industrial / OT preset, for agents that can reach controllers, safety systems or the historian, blocks register, coil, setpoint, controller and safety-system writes by tool name (modbus_write*, set_setpoint*, sis_* and more), asks before historian writes and alarm acknowledgement, fails closed, and lists on its card what it cannot stop.
Why it matters. Agents in finance, support and operations act on money, accounts and plant, so the control has to know which action is which, not only which text is sensitive. More in Treat AI as critical infrastructure.
Limit. Classes come from function names, so purge_cache counts as destructive, and an OT write made through a shell (mbpoll, a pymodbus script) is not recognized.
Living off the AI
An implant driven by a language model does not have to bring its own. It can live off the AI already on the device: drive the user’s AI coding CLI from a process it injected into, call a local model server directly, or steal AI keys and call a provider from its own process. Four detectors answer those moves.
- An AI coding CLI started by an unexpected program. A Windows system host, an Office app, a script host or an image in a temp folder as the CLI’s parent raises a High alert or, by policy, blocks the session’s tool calls. A terminal or IDE counts as normal only when its name and install path both match. The Regulated and Industrial / OT presets block.
- Decoy AI keys. Opt-in, by signed policy: never-issued keys go into new files that key harvesters sweep and no tool loads, and an existing file is never touched. A decoy in a command or a model-proxy request is denied, and one in a tool’s output reported, always as Critical.
- A local model server reachable without MoorAI. Once a day, listening sockets are matched to runtimes such as Ollama, LM Studio, llama.cpp and vLLM. A server counts as behind MoorAI only when it listens on loopback alone and a connection from the scan is refused.
- An unknown program calling an AI provider API. The same daily sample names the process behind each provider connection. A tool counts as known only when the executable path the OS reports is in that product’s install location, or on macOS it carries the vendor’s code signature;
nodeandpythonare judged by the program they run.
Alerts carry class names, ports, provider names and counts, never a path, a command line or a key. The console shows exposed model servers, unknown AI callers and decoy counts in Inventory, and a plain-language switch for each detector in the Policy view.
Why it matters. These moves use tools the organization already approved, so a list of allowed applications sees nothing unusual. The signal is who started the tool, which process holds the connection, and whether a key nobody issued turns up.
Limit. Windows paths are tested on canned data only, a custom command server behind TLS is not identified, a same-user process installing into the user’s own folders cannot be told apart from the real tool, decoys are seen only when used through MoorAI, and Gemini API traffic cannot be attributed today.
Evidence integrity
Each alert carries a per-device sequence number, so the console can see alerts that never arrived. A number is taken under a per-user lock and handed out only once the new chain head is on disk, so two alerts never share one and a crash never repeats or restarts the count. A process that cannot take the lock in time sends its alert unnumbered instead. The console reports a run of unnumbered alerts as its own low-severity finding, “Alerts sent without a sequence number”: a few are parallel hook calls losing the lock, a run is a lock held or planted on the device.
Why it matters. Missing-alert and counter-reset findings are only as reliable as the numbers under them; a number handed out twice reads as a counter reset an investigator has to rule out.
Limit. On an unmanaged device the counters are user files, so they catch an agent that deletes queued alerts, not one that also rewinds them.
Free tools and resources
- Permission right-sizer. Paste a Claude Code, Codex, Gemini CLI, Cursor or MCP config and get the risky grants ranked by severity and a tighter config, with the reason for each change. It runs in your browser; the config never leaves the page.
- Glossary. 82 terms, among them fail open / fail closed, AI detection and response and permission right-sizing.
- Anthropic Inference Hooks: what they see and what they don’t. A buyer’s guide and a checklist for choosing a hook server, with matching rows in the Zscaler comparison.
Limit. The right-sizer reads one file at a time, and agents merge several settings files, so a rule in another file can change the picture.
Sources
- Agent. MoorAI on GitHub, README sections “Fail open or fail closed: the administrator decides”, “Living off the AI: four detectors”, and the model proxy’s “Operator context” and “Business actions”.
- Console. Console README sections “Policy fields: business actions, function names, fail mode”, “Living-off-the-AI detections” and “Policy presets: Industrial / OT”.
See also: Capabilities, MoorAI for Endpoints and the console.