Latio Tech’s AI Security Market Report 2026 is a 51-page buyer’s map of a crowded market. Its main claim is that AI security has entered a second era, in which the thing to control is the coding agent on a developer’s machine rather than the chat tab in a browser. That is the problem MoorAI was built for, so the report is a useful frame for checking where MoorAI is strong and where it is thin.
What the report argues
The survey results set the tone. Asked for their primary AI security concern, 45% of respondents picked endpoint agents such as Claude and Codex, ahead of first-party agents, browser apps and hosted agents (p.6). The share with a budget line for AI security tools is 37%, against 8% the year before (p.5). The report doesn’t state how many people it surveyed, so these figures show a direction and can’t be read as precise measurements.
From there it describes two eras (pp.8–9). In the first, controls lived in the network proxy and the browser, and the goals were finding shadow AI, keeping sensitive data out of unapproved models, and catching prompt injection at runtime. Many of those vendors were bought by network security companies. The second era is about agents that act on the endpoint, and the report lists three outcomes for it: runtime monitoring with intent analysis, governance of skills and MCP servers (including supply-chain malware), and enforcement of what an agent is allowed to touch. On endpoint coverage the report is blunt: this year, “a platform is incomplete without one” (p.9).
It then names five things security teams want from endpoint agent security (pp.13–14): stop supply-chain attacks through skills and MCP packages, prevent agents from doing damage with a user’s own credentials, stop indirect prompt injection hidden in content the agent reads, understand an agent’s blast radius, and let employees adopt approved AI tools safely.
For how a product plugs in, the report compares three integration points (p.15). A network proxy works with most agents but can’t see permissions or local system access. An endpoint agent sees deeply into the device but handles SaaS and first-party AI apps poorly. Hooks and gateways see the session and can change what goes into the agent’s context, but not every agent platform offers hooks, and they can’t change device settings. The report’s advice is to combine all three.
Two more points matter for buyers. On intent-based detection, the authors say their hands-on testing found that “many runtime detection engines are not as powerful as promised” (p.26), and they tell readers to test for themselves. On direction, they see large platforms racing to add endpoint agents while endpoint specialists spread into browser and SaaS (p.18), with the two markets converging (p.43). Their 2027 prediction is that “The ‘Hosted Endpoint’ will be the 2027 AI security focus” (p.32), meaning agents running on platforms like Agentcore and Foundry.
One note on reading the vendor pages: every vendor was offered a spotlight page written by the Latio team (p.33). The report doesn’t list sponsors, so the spotlights are best read as product descriptions rather than comparative test results.
Where MoorAI sits in the report’s map
Of the three integration points, MoorAI is a hooks-and-gateway product. It enforces through a PreToolUse hook inside the agent and an MCP stdio gateway in front of tool servers. A companion browser extension guards 8 chat apps on the same device, which reaches part of the first-era browser surface on that machine. MoorAI is not a network proxy, and it is not a full endpoint sensor.
The report also lays emerging endpoint vendors along a spectrum (p.20), from broad device-management tools on one side to products built around agent behaviour on the other. MoorAI sits at the agent-behaviour end. It inspects what crosses into and out of the agent: prompts, files and context the agent reads, retrieved web, RAG and memory content, tool and MCP calls, skills and rules files, and the agent’s output. Those crossings are checked against a 67-threat rule base, with escalation to a local model through Ollama for ambiguous cases when one is available. The agent runs first-class on macOS and Windows; Linux support is second-class.
MoorAI against the five use cases
This table is our own assessment against the report’s five use cases. “Partial” means MoorAI does real work on the problem but leaves a gap a buyer should plan for.
| Use case | Status | What MoorAI does | What is missing |
|---|---|---|---|
| Supply chain | Partial | moorai scan checks skill and agent artifacts on the device before install. MCP servers go through an allow-list with approval, and a server that changes silently is flagged. Rules files such as CLAUDE.md and .cursorrules are checked for tampering, and typosquatted names are caught by rule. | The scan is static. It never runs the skill, so there is no sandboxed execution to watch what a skill fetches or spawns. |
| Unintended damage | Partial | Destructive commands are coached, alerted on or blocked by policy. The alert and block levels provide a human approval step, and a critical finding can terminate the agent, not just deny one call. | Full enforcement is on Claude Code only. Codex and Copilot CLI are detection-only, and Claude Desktop is covered through the MCP proxy alone. |
| Indirect injection | Partial | Named rules for indirect and second-order injection, RAG and memory poisoning, and invisible or obfuscated text, applied as the data enters the agent. | Same limit: the ability to stop the resulting action depends on the agent exposing a hook. |
| Blast radius | Partial | An entitlement envelope where you declare the tools, paths and MCP servers an agent may use, with alert or block on drift. Excessive-agency and lethal-trifecta detection (private data, untrusted input and an outbound channel in the same agent). | MoorAI does not map an agent’s credentials, file-system reach or permissions for you. The envelope is what you declare. |
| Adoption governance | Covered | Discovery of agents, AI desktop apps, browser extensions and MCP servers on the device. Managed versus unmanaged agents, personal versus corporate accounts by email domain, AIBOM export, and fleet policy from the management console. | Covers what is on the device. Agents that run in SaaS or on hosted platforms are out of scope. |
Where the report’s framing pushes back
Several of the report’s arguments count against MoorAI, and a buyer should weigh them.
Hooks only reach agents that offer them
The report lists this as the main weakness of the hooks approach (p.15), and it applies directly. MoorAI enforces fully on Claude Code. Codex and Copilot CLI are detection-only, and Claude Desktop is covered only through the MCP proxy. If your developers mostly use an agent without a usable hook, MoorAI tells you what happened more often than it stops it.
No full endpoint sensor
The report treats agent-based endpoint deployment as the long-term goal (p.16), and its endpoint-leader definition rewards mapping permissions, folder structures and approved commands (p.49). MoorAI runs on the device and inventories AI tooling, but it doesn’t change device settings, doesn’t map credentials, and is not an EDR or MDM replacement.
Static scanning where the report favours detonation
The report argues that static analysis gets weaker as skills pull in scripts and external content, and highlights running skills in a controlled environment to watch their behaviour (p.24). moorai scan is static by design and never executes the skill. The runtime hook still sees what the agent does with a skill later, but only after it is installed.
Buyers are consolidating
If large platforms are adding endpoint agents and the markets are converging (pp.18, 43), many teams will want AI coverage from a vendor they already pay. MoorAI is a single-purpose tool. It sits next to an EDR, DLP or CNAPP product and doesn’t replace any of them.
The hosted-agent prediction
MoorAI doesn’t cover SaaS or hosted agents. If the report’s 2027 prediction holds (p.32) and more agent work moves to hosted platforms, the share of agent activity MoorAI can see gets smaller. It also isn’t a sandbox or a network/SASE proxy, so it doesn’t fill those roles either.
The criterion the report leaves out
The report’s buying advice centres on your priorities, your existing stack, whether you want an endpoint specialist or a broad platform, and how much runtime control you need (p.31). One question never appears on that list: where does the content go? Privacy and self-hosting aren’t raised as buyer criteria, and open source comes up as a source of malware rather than as something you can audit (pp.13, 21). On-device analysis appears in two vendor spotlights (pp.36–37), described in terms of speed, offline operation and data boundaries, but never as a question to ask every vendor.
For some buyers this question decides the purchase. A coding-agent session carries source code, credentials in config files, and sometimes customer data. A security product that inspects those sessions in its own cloud creates another copy of that content, held by another company, under another contract. Teams with regulated data, sensitive IP or works-council constraints often can’t accept that, whatever the detection quality.
MoorAI’s answer is a design choice. Content is inspected on the device, and only the category, the risk level and a keyed one-way hash leave it. The agent is open source under MIT, so you can read the code and check what it sends. The management console is free up to 200 users hosted, or self-hosted under the Elastic License 2.0.
Keeping content on the device is a privacy property. It says nothing about detection quality, which you still have to test. It also has a cost: because MoorAI doesn’t keep prompts or tool arguments, its audit trail can’t be used for verbatim forensics. If you need the full text of a session, the agent platform’s own logging has to supply it.
Test it the way the report recommends
The report’s advice to test runtime detection yourself (p.26) applies to MoorAI too. Our public benchmark exists for that. The corpora and harness are at github.com/gitayg/agentic-security-benchmark under Apache-2.0, and you can run any product against them, MoorAI included. How we test explains the method.
Whichever vendor you evaluate, a few checks map directly onto the five use cases:
- Supply chain: give it a skill that ships a script with a hidden payload, and see whether the gate catches it before install or only once the script runs.
- Unintended damage: ask the agent to run a destructive command, and note whether the product blocks it, asks a human, or only logs it. Repeat on each agent your teams use.
- Indirect injection: plant an instruction in a README or web page the agent reads, and check whether the resulting tool call is stopped.
- Blast radius: have the agent reach outside the paths and servers you declared, and see whether drift is reported.
- Detection claims: ask for a false-positive rate on benign developer traffic, and for how many attacks the model would have refused on its own. A detection rate without those two numbers is hard to interpret.
The AI Security Market Report 2026 is Latio Tech’s work, and its findings, use cases and predictions are theirs. Latio did not evaluate MoorAI, and the report does not mention it. The mapping of MoorAI onto the report’s framework, including every status in the table above, is our own assessment. Page numbers refer to the report PDF.
Short quotes from Latio Tech’s “AI Security Market Report 2026” are attributed with page numbers; everything else summarises the report in our words. MoorAI is on-device, open-source (MIT) security for AI coding agents. See also: The layer above the model, Choosing an agentic security vendor, and shadow-agent discovery.