Your auditor will ask about AI agents.
Here is the evidence.
You already hold SOC 2 and ISO/IEC 27001, perhaps ISO/IEC 42001, and the EU AI Act may reach you as a deployer. Those frameworks ask for access control, logging, monitoring and data-loss prevention, and your existing controls answer them for people and services. A coding agent runs on a developer's device with that developer's access, and decides for itself which files to read, which commands to run and which MCP tools to call. Those decisions do not appear in your identity logs or your DLP console as agent decisions, so the frameworks you hold do not cover them by themselves. MoorAI checks each agent action on the device before it runs and produces the evidence for each framework, content-free.
Everything on this page is what ships today in the MoorAI console v0.99.0 and agent v1.41.0; the ATT&CK figures are pinned to agent v1.41.0.
Why now
Since December 2025 the payment card industry, ISO and OT security guidance have each addressed AI systems directly. Each is a dated reference your auditors and customers can hold AI agents to.
The four questions
Whatever the framework, the AI agent part of the audit comes down to four questions. Each answer below names the evidence and where in MoorAI you get it.
What these signals prove. Alerts, heartbeats and allow-trail records reach the console with the tenant install token, which an agent on the device can read. The console labels the checks built on them Evidence (token-authenticated): they record what the console was told, not what a device key signed. A heartbeat proves the hook ran, not that it decided every call. The sequence numbers catch an agent that deletes alerts without also rewinding the counter.
Framework by framework
For each framework: what your auditor will ask, the evidence MoorAI gives you, and the control ids the console's report for that framework maps. Each report (Compliance view, exported as HTML or JSON) fills its controls with live counts for your tenant: prompts reviewed and blocked, policy alerts logged, devices monitored, threat detectors, average device posture. The console also reports against NIST CSF 2.0 and the CSA AI Controls Matrix.
- Who can change what the AI agents are allowed to do, and is each change logged?
- How do you restrict what data leaves through an AI agent?
- How are AI agent security events monitored and evaluated?
- Console sign-in by password or SSO (OIDC or SAML), per-device install tokens and tenant isolation; policy changes in the hash-chained governance log.
- Review on the device before the call runs; only category, risk and a keyed hash leave it.
- A central alert log by severity, a 0–100 posture score per device, weekly reports and SIEM streaming.
CC6.1CC6.6CC6.7CC6.8CC7.2CC7.3C1.1- Is AI agent use inside the ISMS scope, and where is its logging and monitoring?
- What prevents data leaking through an AI agent?
- How do you know how each device's AI tooling is configured?
- A content-free audit of policy events per device, a central alert log, device telemetry and weekly reports.
- On-device DLP that checks prompts, file reads and tool calls for secrets and personal data before they reach the agent.
- A per-device AI bill of materials and posture score; stored secrets encrypted with AES-256-GCM.
A.5.15A.5.7A.8.12A.8.15A.8.16A.8.24A.8.9- Which AI systems are inside the AIMS scope, and who owns each one?
- How is AI system operation monitored?
- How is responsible use enforced, not only written down?
- The fleet and runtime AIBOM, and agent ownership: owner, purpose and approval per agent, MCP server and AI key, with ownerless and stale findings.
- Every prompt and tool call reviewed on the device; alerts logged centrally by severity.
- A per-tenant usage policy enforced at the point of use.
A.6.2.2A.6.2.4A.7.4A.8.3A.9.2A.10.4- Do you hold an inventory of the AI in use, including what staff installed themselves?
- Which policies govern AI use, and how are they enforced?
- How do you measure security and privacy risk while the AI is in use?
- A shadow-AI inventory per device and the AI bill of materials as the context map.
- A signed per-tenant policy (disabled, alert, notify or block per detector) enforced on every prompt and tool call.
- Detection of prompt injection, jailbreaks, destructive commands and data leakage on the device; posture and weekly reporting.
GOVERN-1.2 · partialGOVERN-1.6MAP-1.1 · partialMEASURE-2.7MEASURE-2.10MANAGE-4.1 · partial- Are records of AI use kept automatically, and can you export them?
- How does a person stay in control of what the AI does?
- What do you do about robustness and cybersecurity?
- Automatic, content-free records of each AI-use event per tenant, retained and exportable.
- Coach, mask, ask or block at the moment of use, with a signed justification where the policy asks for one.
- Prompt-injection, poisoning and destructive-command detection on the device.
Art.9Art.12Art.14Art.15Art.26 · partial- Which agent actions are restricted, and how is an unsafe tool call stopped?
- Is AI system activity logged?
- How is personal data kept out of what the agent sends?
- Tool-call and MCP argument checks before the call runs, an MCP server allow-list, and an entitlement envelope per agent.
- The content-free alert log and, opt-in, the allow trail.
- On-device DLP; only content-free signals leave the device.
A003 · partialA004 · partialA006A008 · partialB002B005B006 · partialB007 · partialB009 · partialB010 · partialC007 · partialC008D003 · partialE004 · partialE006 · partialE009 · partialE010 · partialE015 · partialF001 · partialThe console's AIUC-1 report and evidence pack cover 24 requirements of the Q4 2026 release (15 October 2026): the 19 above, and five third-party testing requirements (A009, B001, C010, D004, E018) as not applicable, because an accredited body tests the agent itself. MoorAI is not AIUC-1 certified, AIUC has not reviewed the mapping, and the pack is evidence toward a requirement, not a conformity claim.
- How does your AI agent deployment address prompt injection and excessive agency?
- Which of the ten risks are covered, and which only in part?
- A coverage report per list, counted against all ten items; a control whose every credit is bounded reads partial, never covered.
- An OWASP LLM Top 10 posture assessment graded pass, warn or fail from your tenant's live signals, with a specific fix per item.
LLM01–LLM10ASI01–ASI10MCP01–MCP10- Which adversary techniques against AI agents would you detect, and where do they show up?
- What is not covered?
- A MITRE ATLAS coverage report counted against every top-level technique in the release, not only the ones MoorAI credits; every SIEM event carries the rule's primary ATLAS id and the full list.
- ATT&CK v20 credits in the agent's 85-rule base: 49 rules credit a technique and the other 36 state why they have none. Of the 71 techniques an AI agent can perform or be aimed at, agent v1.41.0 covers 2, covers 56 in part (9 bounded by design, 47 open gap) and leaves 13 uncovered, each listed on the ATT&CK coverage page.
AML.T… (ATLAS)The console has no ATT&CK report. Every SIEM event (schema 7) carries the detection's ATT&CK v20 ids next to its ATLAS ids; the credits live in the agent's rule base.
Forrester's AEGIS groups the guardrails for agentic AI into six domains, and its theme is securing intent, not just actions. The full framework is a Forrester report for its clients. This block maps MoorAI by domain only and uses no AEGIS control ids; the ids below are the console's own, one per domain.
AEGIS-GRCGovernance, risk and complianceimplemented- Under which policy do the agents run, who changed it, and can you show that for the audit window?
- Policies signed with your tenant's ed25519 key and verified on the device; policy and settings changes in the hash-chained governance log.
- The runtime AIBOM: which agent used which model, MCP server and tool.
- An AEGIS evidence pack from the console, sealed with a signed manifest.
AEGIS-IAMIdentity and access managementpartial- Who owns each agent, what can it reach, and does it use only what it needs?
- Agent ownership: owner, purpose and approval per agent, MCP server and AI key.
- Granted-vs-used right-sizing, the MCP server approval gate and device-key binding.
- Business actions (money, bulk data, identity, destructive, delegation) that a signed policy sets to ask or block before they run; in Claude Code, a held call can go to an approver group in the console.
- Agent identities: one id per agent per device or workload, linked to an Entra Agent ID or Okta agent id, with a finding when a de-provisioned agent is seen again.
Gap. MoorAI issues no credentials to agent identities, so there is no credential lifecycle for them.
AEGIS-DATAData security and privacypartial- What stops sensitive data leaving through an agent, and what does the security tool itself collect?
- On-device DLP on prompts, tool arguments and model requests, with masking.
- Content-free alerts: category, risk, decision and a keyed hash, never the matched text.
Gap. No purpose-bounded data access: MoorAI does not limit which data an agent may use for which purpose.
AEGIS-APPSECApplication security and DevSecOpsimplemented- How are model calls, MCP servers and tool definitions protected against injection and tampering?
- The model proxy; the MCP gateway and guard, with drift blocking and a fresh tool listing before a call judged against a stale one.
- Prompt-injection detection; the SDK and sidecar for your own AI apps.
AEGIS-THREATThreat management and security operationsimplemented- Do agent detections reach the SOC, mapped to the techniques it already tracks, and can you trace an incident back?
- Alerts to the SIEM, mapped to ATT&CK v20 and MITRE ATLAS; the living-off-the-AI detectors.
- context.tree forensics and the patient-zero lookup: which session took in a given file.
AEGIS-ZTZero Trust architecturepartial- Is each agent action checked, and what happens when the check cannot decide?
- A check before every agent action; egress rules per binary, host and path.
- Windows MXC containment by policy; a fail mode the administrator chooses per surface.
Gap. Outside MXC, the agent runs as the same user as the developer: MoorAI is governance there, not a sandbox.
MoorAI checks each risky action against the task the user stated. It flags an upload, deletion, credential read or MCP write aimed at something the user never mentioned (rule #64, report-only by default, with an opt-in on-device model second opinion).
Limit. The matching is by names and labels. It catches an agent going somewhere the user never pointed it, not a wrong reason for going somewhere the user named.
AEGIS-GRCAEGIS-IAM · partialAEGIS-DATA · partialAEGIS-APPSECAEGIS-THREATAEGIS-ZT · partialMapped by domain from Forrester's public description of AEGIS; not a Forrester assessment or endorsement. Sources: AEGIS framework and Introducing AEGIS, forrester.com.
ISO/IEC 27090 is guidance on understanding, detecting and mitigating the security threats specific to AI systems throughout their life cycle, with data poisoning and model theft among its examples. It complements ISO/IEC 27001 and 27002 and is written for organizations of every type and size that develop or use AI systems. The text is sold by ISO. This block maps MoorAI by threat family only and uses no clause numbers; the ids below are the console's own, one per family.
ISO27090-INJECTPrompt injection, direct and indirectimplemented- How do you stop instructions in a prompt, a file, a web page or a tool result from steering the agent?
- Direct (rule #2) and indirect (#3) prompt injection, checked on the device in everything the agent reads (files, web pages, tool output and MCP results) and in prompts written by an event or a server pipeline.
- Second-order injection (#40): a role-spoofing directive planted in data the agent reads, such as a forged SYSTEM line or a note to the AI that names a tool, is caught at every tool-result stage.
Default. A prompt a person types is not scanned by default (promptScan: "untrusted"); prompts from events or a pipeline, and everything the agent reads, are. promptScan: "all" scans typed prompts too.
ISO27090-POISONData and retrieval poisoning at use timepartial- How do you keep poisoned documents and memories out of what the agent retrieves?
- Knowledge-base and RAG poisoning (#21) and memory poisoning (#22) rules on the content the agent takes in.
- Scan-before-embed: content an application is about to write to a vector store is checked first, through the SDK, the sidecar and the vector-store tools the MCP gateway recognises; reported by default, blocked by policy.
- Provenance checks: a price, policy, payment or authority claim from an author the application marks untrusted or unknown is reported, held or blocked by policy before it is indexed, and two retrieved passages that give the same item different values raise conflicting facts.
Gap. A forged fact from an author marked trusted, or from one the application does not label, is not detected unless a passage retrieved beside it contradicts it.
ISO27090-DISCLOSESensitive data and instruction disclosureimplemented- What stops secrets, personal data or the system's own instructions leaking through the agent?
- On-device DLP on prompts, file reads, tool arguments and model requests, with masking.
- System-prompt extraction attempts (#51) and system-prompt or instruction leakage in the model's output (#52).
ISO27090-AGENCYMisuse of agent capabilitiesimplemented- How do you limit what an agent does with the access it holds?
- A check before every agent action: commands, file access, tool calls and MCP calls.
- Business actions (money, bulk data, identity, destructive, delegation) that a signed policy sets to ask or block before they run.
- The MCP server approval gate, and egress rules per binary, host and path.
ISO27090-SUPPLYAI supply chain (models, tools, extensions)partial- How do you vet the models, MCP servers, tools and extensions the agents use?
- Pre-install checks on an MCP server from its registry metadata and manifests, without downloading or running it, and a pre-install gate for skills and agent files.
- Tool-drift blocking: in drift-block mode, a call to an MCP tool whose definition changed or vanished since approval is refused, judged against a fresh listing.
- The fleet and runtime AIBOM: which agents, models, MCP servers and editor AI extensions are configured and used.
- Model files (pickle and PyTorch, Keras, TensorFlow, ONNX, GGUF, SafeTensors) scanned without loading them, for the models an agent downloads and, when turned on, the local model stores on the daily posture run.
Gap. The model-file scan is static: a backdoor triggered by input, or trojaned weights, is not detected.
ISO27090-EXTRACTModel theft and extractionnot applicableModel theft works through queries to wherever the model is hosted. That is outside an on-device agent guardrail: it belongs to the model host, with access control, rate limits and query monitoring on the model's API.
ISO27090-EVASIONTraining-time poisoning and evasion of the model itselfnot applicablePoisoned training data and inputs crafted to evade the model act on how the model was built and how it classifies. That is outside an on-device agent guardrail: it belongs to the model builder, with training-data provenance and robustness testing.
ISO27090-INJECTISO27090-POISON · partialISO27090-DISCLOSEISO27090-AGENCYISO27090-SUPPLY · partialISO27090-EXTRACT · not applicableISO27090-EVASION · not applicableMapped by threat family from ISO's public description of ISO/IEC 27090; not a clause-level mapping, an ISO assessment or a certification. Source: ISO/IEC 27090, Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems, in the Standards Council of Canada catalogue. Earlier drafts were titled Guidance for addressing security threats to artificial intelligence systems.
The evidence, item by item
What each piece of evidence shows, and where you get it.
Scroll sideways →
| Evidence | What it shows | Where you get it |
|---|---|---|
| Per-framework compliance reports | Each control the console maps for a framework, with live counts for your tenant at the time you generate it. A mapping for self-assessment, not a certification or an audit attestation. | Compliance view; export as HTML or JSON |
| Content-free lineage export | From MoorAI’s alert records: which data class (personal data, health data, secret, source, regulated) moved through which agent, at what risk, under which policy and decision. Fields: tenant, time, category, data class, risk, agent, decision, policy id, actor hash, content hash, rule id. | Lineage CSV or JSON, for a SIEM or GRC tool, with a time window |
| Signed policies the device verifies | The policy is signed with your tenant's ed25519 key. The device pins that key and learns a new one only from a newer policy that the pinned key signed. Rotation runs with a cutover window. | Policy view; each key rotation is in the governance log |
| Numbered alerts with gap detection | A per-device sequence number on every alert. Findings: alerts missing from a device, a counter reset, alerts missing for a session, and a run of alerts sent without a number. | Inventory → Coverage integrity |
| Coverage integrity | Daily hook heartbeats per agent; findings for an agent used with no hook traffic, a hook removed or stale, a weakened agent setting, and an agent version MoorAI has not been tested with. | Inventory → Coverage integrity; findings reach the SIEM |
| Fail-mode posture per surface | For each device, whether the coding-agent hook, model proxy, MCP gateway and Inference hooks fail open or closed, and whether the setting came from the administrator, the policy or the default. A surface that fails open while the policy asks for closed is flagged. | Inventory and Coverage → Fail mode column |
| Allow trail (opt-in) | One content-free record per tool call the agent was allowed to make: tool, capability tags, MCP server, basis, with its own sequence number. Never an argument, a command or a path. | Installs → Allow trail; Timeline per session; optional SIEM forward |
| Browser Guard findings | Prompts typed into the web AI chat sites listed under Shadow AI below, checked before they are sent: a coach banner, or in block mode a high-severity send stopped. A finding can reach the console as a content-free alert: category, risk, the site's host and a keyed hash. | The MoorAI Browser Guard extension for Chrome and Edge; its alerts in the Timeline |
| Runtime AIBOM | Which agent used which model, MCP server and tool, how often and on which devices. | Compliance view → Runtime AIBOM; CSV |
| Right-sizing | What each agent can reach on each device against what it used over 30 or 90 days, with a recommendation per unused grant and a previewed apply-as-policy that never widens a list. | Compliance view → Granted vs used; CSV |
| Ownership | An owner, a purpose and an approval state for each agent, MCP server and AI key; ownerless and stale findings. Every change is in the governance log. | Compliance view → Agent ownership |
| context.tree proofs | A per-session Merkle tree (RFC 6962) of content-free leaves for everything that entered the agent's context. Every record carries the root; the console re-verifies it; an injection alert names the leaf behind it; a file's SHA-256 finds every session that took it in. | Session → Context tab; Patient zero in the Timeline; moorai-context-proof on the device |
| Governance log | Console changes such as policy, settings, ownership and key rotation, as hash-chained records: an edit, deletion or reorder of a past entry breaks the chain. The export carries its own verification. | Governance export and verify |
| AI use trust packet | A live, content-free summary of AI use for a customer's vendor-risk team: agents, models and MCP servers in use, controls enforced, coverage, drift and the framework controls MoorAI maps to. | Compliance → AI use trust packet; an expiring, revocable share link |
Shadow AI: whatever account the agent is signed into
MoorAI's hook runs inside the agent on the device, so it checks an agent's actions the same way whether the developer signed it into a corporate subscription or a personal one. The console records the account an agent CLI is signed into (Claude Code's account, Copilot's GitHub login) as a keyed pseudonym and flags accounts outside your corporate domains. From agent v1.31 the device sends the Claude account only as a keyed pseudonym with its domain class (corporate, personal or unknown), never the address or the domain. An agent on an enrolled device that MoorAI's hook is not registered in is listed in the coverage report, so the gap is visible rather than silent.
Shadow AI also lives in the browser. Where the MoorAI Browser Guard extension is installed (Chrome and Edge), it reviews the prompt typed into ChatGPT, Claude, Copilot, Gemini, Perplexity, Le Chat, DeepSeek and Grok on the web before it is sent, whichever account is signed in. It runs locally with a subset of the agent's detectors, coaches, or in block mode stops a high-severity send, and can send the console a content-free signal. It covers only those sites and only typed text: a file uploaded to the chat is not checked.
The evidence pack: one bundle per framework and audit window
The console builds an evidence pack for one framework over one audit window of up to 366 days: Compliance → Evidence pack, pick the framework and the dates, Generate, Download. You hand the bundle to your auditor, and the auditor checks it without access to your console.
VERIFY.txt: OpenSSL 3 or later, the bundle and your tenant's public policy key, nothing else. Check the key in the bundle against the one your devices pin.Frameworks: every framework the console maps: SOC 2, ISO/IEC 27001, ISO/IEC 42001, NIST AI RMF, NIST CSF, CSA AICM, EU AI Act, OWASP LLM, OWASP Agentic, OWASP MCP, MITRE ATLAS, Forrester AEGIS, ISO/IEC 27090 and AIUC-1. For GRC tools: GET /api/evidence-pack returns the same bundle, as a zip or as JSON with the exact files. It takes a signed-in console session; the console has no API keys for this, so scheduled collection by a GRC platform needs a session.
What the pack proves. The signature proves the bundle is the one your console produced and that nothing in it changed afterwards. A pack is evidence for your audit, not a certification.
Control by control
The same ground from the other side: each row is a control MoorAI ships, each column the clause, function, article, requirement or risk it supports. These columns are this page's indicative mapping; the ids in the framework sections above are the ones the console's own reports use.
| 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 and app 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 | — |
| Fail mode per surface · 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 (plus login and hostname, pseudonymised on arrival) 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 |
SOC 2 and ISO/IEC 27001: the console's mapping, control by control
The two frameworks most organisations already hold. Each row is a control id the console's report maps, the evidence it describes, and the live counts the report fills in.
Scroll sideways →
| Control | Evidence in the console's report | Live counts |
|---|---|---|
| SOC 2 · Trust Services Criteria | ||
| CC6.1 | Console sign-in by password or SSO (OIDC or SAML); devices bound by per-device install tokens. | Admin authentication · tenant isolation |
| CC6.6 | Every prompt reviewed on the device before it reaches the agent; DLP blocks secrets and personal data. | Prompts reviewed · prompts blocked · threat detectors |
| CC6.7 | Only redacted metadata leaves the device, never prompt content; each device is bound to its tenant. | Audited events |
| CC6.8 | SSO client secrets and stored keys encrypted with AES-256-GCM; sessions HMAC-signed. | Secrets encryption |
| CC7.2 | Policy alerts logged centrally by severity; per-policy email and weekly summary reports. | Policy alerts logged · devices monitored |
| CC7.3 | Triage by threat, category and risk; a 0–100 posture score per device. | Average device posture |
| C1.1 | On-device DLP for secrets, API keys, personal data, card and IBAN numbers, plus content categories. | Threat detectors · content categories |
| ISO/IEC 27001:2022 · Annex A | ||
| A.5.15 | Admin-only console (password or SSO); tenant isolation enforced on every API call. | Admin authentication · tenant isolation |
| A.5.7 | AI-security threat detectors and content categories, managed centrally by policy. | Threat detectors · content categories |
| A.8.12 | On-device DLP reviews every prompt and blocks secrets and personal data before they reach the AI. | Prompts reviewed · prompts blocked |
| A.8.15 | A content-free, redacted audit of policy events per device and tenant. | Audited events |
| A.8.16 | A central alert log, device telemetry and weekly reports. | Policy alerts logged · devices monitored |
| A.8.24 | AES-256-GCM for stored secrets; HMAC-signed sessions. | Secrets encryption |
| A.8.9 | A per-device AI bill of materials, a 0–100 posture score and risky-extension flagging. | Average device posture · devices monitored |
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. Use it to grade every vendor in this category, MoorAI included.
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.
Per-framework walk-throughs
Each page maps MoorAI’s controls to one framework in detail.
Frequently asked questions
What will an auditor ask about AI agents?
Four questions, whatever the framework: which AI agents run on your devices, under which policy, what they were stopped from doing, and how you know the control was on for the whole period. MoorAI answers them with the fleet and runtime AIBOM, signed policies the device verifies, content-free alert records and the lineage export, and coverage-integrity findings built on daily hook heartbeats and numbered alerts.
Which frameworks does the MoorAI console report against?
The console generates a report per framework, filled with live counts for your tenant: SOC 2, ISO/IEC 27001:2022 Annex A, ISO/IEC 42001, the NIST AI RMF, NIST CSF 2.0, the CSA AI Controls Matrix, the EU AI Act, the OWASP LLM Top 10 (coverage and a posture assessment), the OWASP Agentic Top 10, the OWASP MCP Top 10, MITRE ATLAS, Forrester AEGIS, mapped by domain, ISO/IEC 27090, mapped by threat family, and AIUC-1. It has no ATT&CK report; ATT&CK credits live in the agent's rule base, and every SIEM event carries the detection's ATT&CK ids.
How do we show the AI agent control was on for the whole audit period?
With coverage integrity. The MoorAI hook sends a daily heartbeat per agent, and the console raises a finding when an agent was used with no hook traffic, when the hook is removed or stale, or when an agent setting is weakened. Every alert carries a per-device sequence number, so a gap or a counter reset is a finding too. These signals arrive with the tenant install token, so the console labels them evidence (token-authenticated), not device-signed.
Does MoorAI make my organization SOC 2, ISO 42001 or EU AI Act compliant?
No. Compliance is an organizational outcome, not a product feature, and MoorAI is not a certification. MoorAI provides content-free technical controls and the evidence that they operated. You still need your own management system, policies and, where applicable, an accredited auditor or conformity assessment.