AIUC-1 is a certification standard for AI agents, published by the Artificial Intelligence Underwriting Company. It is the newest of the three frameworks buyers now ask about alongside ISO/IEC 42001 and the NIST AI RMF — and the only one of the three that combines an audit of your organisational controls with adversarial testing of the agent itself, repeated quarterly. As of the Q3 2026 release it carries mandatory requirements written specifically for code-generating agents. Below: what the standard actually is, how it is structured, and which of its requirements MoorAI's content-free, on-device controls bear on. MoorAI is not AIUC-1 certified — this is a mapping to help you assemble evidence, nothing more.
Worth being precise about, because the shape is unusual and it is easy to mistake for either a voluntary framework or an ISO-style multi-stakeholder standard. It is neither.
Is it adopted? Enough to matter, not enough to be table stakes. The clearest datapoint for this audience is Cursor, which published its AIUC-1 certification on 13 August 2026 after an audit by Schellman and two rounds of adversarial testing across several thousand scenarios — a coding-agent vendor, certified against the coding-agent requirements. UiPath and ElevenLabs have also announced certification. That is a short list, and you should read it as an early-adopter list rather than an industry norm.
Requirements are lettered by pillar and numbered within it — A001, B010, D003 — and each decomposes into numbered controls (A008.1 through A008.5, for instance). Every requirement is marked Mandatory or Optional, and scoped to the capabilities it applies to: Universal, Code-generation, Automation, Text-generation, Voice-generation, Image-generation, External-facing. Counts below are active requirements; two further requirements (E007, E014) are marked retired.
AIUC publishes crosswalks to both, and positions AIUC-1 as complementary rather than competing. In its own words, certification against AIUC-1 “incorporates the majority of controls from ISO 42001” and “translates ISO's management system approach into concrete, auditable requirements”, extending it with third-party testing of things like hallucinations and jailbreak attempts. Against NIST it is blunter still: “AIUC-1 operationalizes the NIST AI RMF”, translating high-level actions into specific, auditable controls. The practical reading: ISO 42001 asks whether you run a management system, the NIST AI RMF gives you a structure for deciding what to manage, and AIUC-1 asks whether the agent actually withstands being attacked. They stack; they do not substitute. AIUC also publishes crosswalks to the EU AI Act, MITRE ATLAS, the OWASP LLM Top 10, OWASP AIVSS, the OWASP Agentic Top 10, the IBM AI Risk Atlas, the Cisco AI Security & Safety framework and the CSA AICM.
Only requirements MoorAI's shipped mechanisms genuinely speak to are listed — the standard has 51, and MoorAI is relevant to a minority of them. Requirement titles and descriptions are as published by AIUC; the right-hand column is what MoorAI actually does. Where the fit is partial, it says so. This is not a certification, an audit, or evidence that any requirement is met — an accredited auditor decides that, not a vendor page.
| AIUC-1 requirementpillar · id · application | What it asks foras published by AIUC | MoorAI mechanismwhat actually does it |
|---|---|---|
| A008 Prevent leakage of credentials and secrets mandatory code-generation | Detect and prevent leakage of secrets in AI system inputs, outputs, logs and credential storage. Control A008.1 asks for secrets detection over user prompts and pasted content by pattern-matching or entropy; A008.2 asks for scanning of generated code artifacts before they are written. | Content-free on-device detection over the prompt at PreToolUse and over tool output at PostToolUse. Matching happens on the endpoint; only category, risk and a keyed one-way hash leave the machine — which answers A008 for inputs, outputs and logs at once, since the log never contains the secret either. |
| B010 Promote secure patterns in generated code mandatory code-generation | Safeguards that promote secure patterns and prevent known vulnerabilities in generated code — secure defaults for common web vulnerability classes, for authentication and authorization, and against dependency risks such as wildcard versions or non-existent packages. | Partial. MoorAI inspects and can block the written artifact at PostToolUse, which addresses the detection half. It does not steer generation — the system-prompt and scaffolding controls B010 also contemplates sit with whoever builds the agent, not with MoorAI. |
| B006 Prevent unauthorized AI agent actions mandatory automation | Safeguards preventing AI agents from performing actions beyond intended scope and authorized privileges. | PreToolUse enforcement on Claude Code — coach, alert or block before the call runs — behind the MCP proxy, with a server allow-list and per-tool argument rules, plus JIT elevation so a privileged step gets a scoped, time-boxed grant instead of standing permission. |
| D003 Restrict unsafe tool calls mandatory automation | Safeguards or technical controls preventing tool calls from executing unauthorized actions, accessing restricted information, or making decisions beyond their intended scope. | The MCP proxy is a single chokepoint every tool call passes through, so “beyond intended scope” is a decision taken at the call rather than reconstructed afterwards. Lethal-trifecta / toxic-flow detection catches the cross-server case a per-call rule misses. |
| B002 Detect adversarial input optional universal | Monitoring capabilities to detect and enable responding to adversarial inputs and prompt injection attempts. | On-device detection of prompt injection and of rules-file poisoning in CLAUDE.md and .cursorrules — the injection vector specific to coding agents, where the payload sits in a file the agent reads rather than in the prompt a human typed. |
| A006 Prevent PII leakage mandatory universal | Safeguards to prevent personal data leakage through AI outputs and logs. | Content-free by default. Only category, risk and a keyed one-way hash ever leave the device, so the governance record cannot itself become the leak. The “and logs” half of A006 is the one most tooling fails, because inspecting content means storing it. |
| A003 Limit AI agent data access mandatory universal | Safeguards limiting AI agent data access based on task, user role, agent role and context. | MCP server allow-list and model-endpoint allow-list bound which tools and which inference endpoints an agent may reach; the entitlement envelope and per-agent assurance score make that bound depend on the agent rather than being uniform. |
| E015 Log AI system activity mandatory universal | Maintain logs of AI system processes, actions and agent outputs where permitted, to support incident investigation, auditing, and explanation of AI system behaviour. | Cryptographically signed, tamper-evident decision records — what was allowed or blocked, under which policy, on which device. The “where permitted” caveat in E015 is doing real work in regulated environments; a content-free record is permitted in more places than a transcript. |
| E006 Conduct vendor due diligence mandatory universal | Vet the vendors in the AI system's supply chain. | Partial. The AIBOM and shadow-AI discovery tell you which agents, models and MCP servers are actually running — the inventory the diligence is performed against. The diligence itself remains a process you run. |
| E010 Establish AI acceptable use policy mandatory universal | Establish and implement an AI acceptable use policy. | Natural-language policy authoring compiled to device-side enforcement. Most organisations can evidence the “establish” half with a document; the “implement” half is what a per-action decision on the endpoint actually demonstrates. |
| E001 AI failure plan for security breaches mandatory universal | A documented AI failure plan for privacy and security breaches, with accountable owners and established notification and remediation. | Partial. Break-glass / offline fail-closed is the technical half of the response — the enforced state when the plan is invoked or the device loses contact. The plan, the owners and the notification paths are organisational and are not something a tool supplies. |
Stated plainly, because a mapping page that only lists hits is not useful for planning an audit.
Informational, not a certification. This page maps MoorAI's shipped controls to AIUC-1 requirements to help teams assemble evidence; it is not a certification, legal advice, or a conformity assessment. AIUC-1 certificates are issued by the Artificial Intelligence Underwriting Company on the basis of an accredited auditor's report and evals from an accredited technical testing body — not on the basis of any tool a company deploys. Partial marks a requirement MoorAI addresses only in part.
AIUC-1 is one of several frameworks the same evidence trail reaches. The crosswalk shows all of them side by side.