Skip to content
MoorAI
// compliance crosswalk

One evidence trail.
Every AI framework.

ISO 42001. NIST AI RMF. EU AI Act. AIUC-1. OWASP LLM Top 10. One AI use case — the coding agents your developers run — reaches all of them at once. The frameworks ask you to manage AI risk and prove you did. MoorAI produces that proof a different way: content-free, on the device. Below, each shipped MoorAI control crosswalked to the clause, function, article and risk it actually supports — evidence without egress.

01 · See what applies
Discover the agents
Shadow-AI discovery and a live AIBOM show which agents, models and MCP servers are actually running — the real scope of your AI use.
02 · Find the overlap
One control, many clauses
A single on-device control — review before the call runs — sits in the overlap of every framework in the table below. Do it once; satisfy many.
03 · Prove it
Evidence without egress
Signed, content-free decisions and Event-Flow lineage are the audit evidence — produced on the device, where the prompt stays.
ISO 42001 NIST AI RMF EU AI Act MoorAI content-free evidence

Three frameworks that bind your organisation, one AI use case — with the OWASP LLM Top 10 as the security lens over all of it, and AIUC-1 as the certification that tests the agent itself. One content-free, on-device evidence trail sits in the overlap.

The crosswalk

Each row is a control MoorAI ships. Each column is the clause, function, article, requirement or risk it supports — the reference an auditor or governance lead can point to. This is a mapping to help assemble evidence, not a certification.

MoorAI control MoorAIships it ISO/IEC 42001AI management system NIST AI RMFGovern · Map · Measure · Manage EU AI ActArticles AIUC-1Requirements (A–F) OWASP LLM Top 102025 risks
On-device gateway — review prompts & tool-calls before they run Clause 8 · Operation / risk treatment MANAGE · risk response at the action Art 14 human oversight · Art 9 risk mgmt B006 unauthorized agent actions · D003 unsafe tool calls LLM01 Prompt Injection · LLM05 Output Handling
MCP server allow-list + per-tool argument rules Clause 8 · Annex A system security MANAGE / GOVERN · controls Art 14 oversight · Art 15 cybersecurity D003 restrict unsafe tool calls · A003 limit agent data access LLM06 Excessive Agency
Model-endpoint allow-list Clause 8 · treatment control MAP / MANAGE · boundaries Art 15 robustness & cybersecurity A003 limit agent data access · B008 deployment environment LLM03 Supply Chain · LLM10 Unbounded Use
Cryptographically signed, tamper-evident decisions Clause 9 monitoring · Annex A records GOVERN / MEASURE · documentation Art 12 record-keeping · Art 26 deployer logs E015 log AI system activity
Content-free data lineage / Event Flow Annex A data governance MAP / MEASURE · traceability Art 10 data governance · Art 12 logs A006 prevent PII leakage · E015 logging LLM02 Sensitive Info Disclosure
AIBOM — live agent / model / MCP inventory Clause 5.4 lifecycle inventory MAP · context & inventory Art 11 · technical documentation (Annex IV) E006 vendor due diligence LLM03 Supply Chain
Shadow-AI agent + app / browser discovery Clause 4 / 5.4 · scope of the AIMS MAP · establish context Art 4 AI literacy · Art 26 deployer awareness E009 monitor third-party access · E006 due diligence LLM03 Supply Chain
Rules-file poisoning detection (CLAUDE.md / .cursorrules) Clause 8 · Annex A integrity MEASURE / MANAGE · treat risk Art 15 accuracy & robustness B002 detect adversarial input LLM04 Data/Model Poisoning · LLM07 System-Prompt Leakage
Lethal-trifecta / cross-server toxic-flow detection Clause 8 · risk treatment MEASURE · measure & track risk Art 9 risk mgmt · Art 15 D003 unsafe tool calls · B006 unauthorized actions LLM01 Prompt Injection · LLM06 Excessive Agency
Per-agent assurance score Clause 9 · monitoring & measurement MEASURE · risk tracking Art 9 risk mgmt · Art 72 post-market monitoring C008 monitor AI risk categories
JIT elevation + entitlement envelope Clause 8 · Annex A access control MANAGE · risk response Art 14 human oversight B006 unauthorized actions · A003 data access LLM06 Excessive Agency
Natural-language policy authoring (device-side) Clause 5.2 policy · Clause 6 planning GOVERN · policies & procedures Art 9 risk-management system E010 AI acceptable use policy
Break-glass / offline fail-closed Clause 8 · operational control MANAGE · incident & continuity Art 15 robustness / resilience E001 AI failure plan · security breaches LLM10 Unbounded Consumption
Content-free by default — only category · risk · keyed hash leave Annex A · data governance / minimization GOVERN / MEASURE · privacy Art 10 data governance (GDPR-aligned) A006 prevent PII leakage · A004 protect IP & trade secrets LLM02 Sensitive Info Disclosure

Informational, not a certification. This page maps MoorAI's shipped controls to the referenced frameworks to help teams assemble evidence; it is not a certification, legal advice, or a conformity assessment. Clause, function and article references are indicative — verify them against each framework's current text. ISO/IEC 42001 certification is issued by accredited bodies against a full audit of your AI Management System. marks a control outside a given framework's scope.

AMTSO — the standard you grade vendors with

AMTSO sits deliberately outside the table above, because it is a different kind of document. ISO/IEC 42001, the NIST AI RMF, the EU AI Act and AIUC-1 tell your organisation what it must do; the AMTSO Guidelines for Testing of Agentic Security Products v1.0 (2 September 2026) tell a security vendor how its product should be tested and how the results should be reported. It is a testing standard, and it applies to us, not to your compliance programme. The rows above say what MoorAI does for your posture. This says how you check whether MoorAI's own claims were measured properly — and it is the standard by which you should grade every vendor in this category, MoorAI included.

// no affiliation
AMTSO has not reviewed, certified or endorsed MoorAI.
AMTSO publishes the guidelines; MoorAI graded itself against them and published the method and the numbers. Nothing on this page is an AMTSO certification, membership claim or result, and deploying MoorAI does not make your organisation AMTSO-anything. Unlike the frameworks in the crosswalk, there is no AMTSO obligation for a buyer to satisfy.
01 · What a test must describe
Classify the case
Five attack vectors, and every test case classified by attack vector, target of protection, environment type, harm type, severity against disclosed criteria, and the capability the product needs to handle it.
02 · What a test must report
A distribution, not a pass rate
Outcomes are reported as a distribution — prevented, detected but not prevented, model refusal, model recognition, missed, inconclusive — instead of collapsing into a single pass/fail number.
03 · What makes it valid
Baselines & repeats
Baseline validation: the attack must actually work with the product absent, or the case proves nothing. False positives reported separately from detection. Repeated runs, because agentic systems are non-deterministic.
// the one line that changes a buying decision
Model refusal must not be credited to the product.
Some attacks fail because the underlying model declines them on its own — no security product involved. Unless a vendor measured that share and subtracted it, their detection rate silently counts the model's refusals as their own coverage. Ask every vendor in this category for the refusal number, MoorAI included. If they cannot produce it, the headline rate is unmeasured.

AMTSO has not reviewed, certified or endorsed MoorAI. The guidelines are a published testing standard; the grading and the report are MoorAI's own, self-conducted and self-published. AMTSO and the Anti-Malware Testing Standards Organization name belong to AMTSO. Read the guidelines and check our work against them.

Go deeper on any framework

The crosswalk is the map; these are the detailed walk-throughs.