AIUC-1 Exam Content and Domain Breakdown

AI agents don't just generate text and hand it back to a human for review. They read files, call tools, post to client portals, and kick off workflows on their own. A hallucination in a chat window is embarrassing. A hallucination that an agent acts on, turning a wrong fact into a posted transaction or a client-facing message, is a different category of problem.

So why doesn't SOC 2 cover how a specific agent behaves when a prompt is malicious, a document is malformed, or a user asks it to act outside its scope? It covers a lot, but it was built to assess a vendor's general service organization controls, not the specific attack surface an autonomous agent exposes when it's handed a malicious prompt or an authorization boundary it wasn't supposed to cross. ISO 42001 has the same gap in a different place: it certifies the AI management system wrapped around an agent, the governance, the documentation, the oversight structure, but it says nothing about how that agent behaves when someone actually tries to break it. None of these frameworks were built with an acting system in mind.

Fieldguide's July 2026 analysis stated that a vendor's SOC 2 report tells you about the company's controls, but it doesn't tell you what happens when a prompt is malicious, a document is malformed, or a user asks the agent to step outside its scope. That's the coverage gap, and the reason a domain structure built around agent-specific threat categories, rather than organizational governance categories, had to exist. Everything that follows in this piece is really an answer to that gap. NIST AI RMF and the NIST Cyber AI Profile (IR 8596, draft 2025) offer risk-management guidance but provide no direct certification path.

AIUC-1's origins

AIUC-1 is a certification standard launched in 2025 by the Artificial Intelligence Underwriting Company, a venture-backed startup that came out of stealth that July with a $15 million seed round led by Nat Friedman at NFDG. That combination, underwriting instincts plus frontier-lab experience plus evaluation methodology, appears in how the standard is structured.

Development involved Orrick, Stanford, the Cloud Security Alliance, MIT, and MITRE, and the standard is backed by a consortium of more than 250 Fortune 500 security leaders What to Make of AIUC-1, a New AI Agent Certification. It's positioned as the first standard built for AI agents specifically, meaning autonomous systems that act inside business workflows, not AI models generally and not AI governance programs in the abstract.

Structurally, the framework contains 51 requirements and 130 controls, split into 65 mandatory and 65 optional, spread across six risk pillars. Those controls map to MITRE ATLAS and the OWASP Top 10 for Agentic Applications, which gives the standard a grounded threat taxonomy instead of a set of abstract principles.

One governance detail is worth sitting with. AIUC accredits its own auditors. That's different from ISO 42001, which relies on independently accredited certification bodies, different from SOC 2, which sits under the AICPA, and different from NIST frameworks, which come from a federal agency. It's a distinction organizations should weigh when they decide how much authority to assign the certificate. AIUC has tried to build in a counterweight: the standard is backed through Lloyd's of London, and AIUC argues the insurance layer creates a financial incentive against inflating certifications, since underwriters have skin in the game if a certified agent fails. AIUC-1 was co-founded by Rune Kvist (CEO, an early Anthropic hire), Brandon Wang (a Thiel Fellow with a background in consumer underwriting), and Rajiv Dattani (a former McKinsey partner and former COO of METR). AIUC-1 operationalizes ISO 42001, NIST AI RMF, MITRE ATLAS, and OWASP Top 10 into a single agent-specific certification. The standard is refreshed quarterly, a cadence faster than SOC 2, ISO 42001, or almost any other compliance framework.

The six domains dividing the AI agent risk landscape

Six pillars: Security, Safety, Reliability, Accountability, Data & Privacy, and Society. These aren't arbitrary buckets stitched together for coverage's sake. Each one corresponds to a distinct failure mode that agentic systems introduce. Security addresses what an agent does when an external attacker comes at it. Safety and Reliability address what the agent does to its own outputs, whether they're harmful and whether they're accurate. Accountability addresses organizational responsibility once something goes wrong. Society and Data & Privacy address effects that ripple outward, beyond the individual deployment.

Three of the six, Security, Safety, and Reliability, require adversarial testing that no amount of documentation can substitute for. The other three can be partially satisfied through policy and evidence review. That's not a small technicality. An April 2026 analysis from zeltser.com flagged Safety (Domain C) and Society (Domain F) specifically as judgment-based categories where documentation alone can technically check the box What to Make of AIUC-1, a New AI Agent Certification. The certificate tells you a floor was met. What it doesn't automatically tell you is how rigorously that floor was tested, and that's a signal buyers need to go looking for themselves.

The 51 requirements spread across all six domains, and the split between 65 mandatory and 65 optional controls gives organizations some flexibility in how they satisfy each requirement, while a non-negotiable floor still enforces the minimum that every organization must meet. Each domain tests something specific, targets particular threats, and exists because that particular risk exists for agents in a way it never quite did for earlier software.

What the Safety domain tests

Safety asks one question at its core: does this agent produce harmful outputs, and was it tested against that possibility before anyone deployed it? The domain covers harmful output prevention, pre-deployment testing protocols, and a risk taxonomy the vendor has to build and maintain.

Notice what can't satisfy this domain. A policy statement saying "our agent will not produce harmful content" proves nothing on its own. Safety can only be confirmed through adversarial testing, scenarios built specifically to try to elicit the harmful output, run before deployment, not promises made about behavior. Zeltser.com's April 2026 analysis flagged Safety as one of the domains where buyers need to look past the certificate itself and ask what testing actually happened, because certification claims alone cannot confirm it What to Make of AIUC-1, a New AI Agent Certification.

The risk taxonomy requirement deserves a second look too. It's not a generic risk register pulled off a shelf. Vendors have to categorize and document the specific types of risk their agent poses given its actual deployment context, a meaningfully harder task than filling out a template.

Think about audit, healthcare, or financial services. A harmful output from an agent in those settings isn't a bad chatbot response somebody screenshots and complains about. It's a workpaper. It's a reported figure that ends up in a filing. It's a client communication that carries the firm's professional liability on its face. The stakes of "harmful" scale with what the output touches.

Security domain: prompt injection, adversarial robustness, and boundary enforcement

Security covers three threat categories that map cleanly onto how agents actually get attacked: prompt injection defense, adversarial robustness, and prevention of unauthorized agent actions. Prompt injection is the one getting the most attention industry-wide right now, and for good reason: a malicious instruction embedded in a document, a data feed, or even an innocuous-looking user message can redirect an agent's next steps without the agent ever "knowing" it's been compromised. Adversarial robustness is closely related but distinct, whether the agent holds its intended behavior when someone is actively trying to break it, not just when conditions are normal. Unauthorized agent actions is the boundary-enforcement piece: even when an attacker manages to manipulate the agent, does it still refuse to take actions outside its approved scope?

Policy can't satisfy this domain either. A prompt injection attack doesn't check whether the vendor has a written policy against it before executing. Only testing against real adversarial inputs reveals whether a defense actually holds.

Scale matters here too. UiPath's certification in March 2026 involved more than 2,000 technical evaluations alongside a full audit of its AI policies and technical guardrails, and it was the Security domain's adversarial testing requirements that drove that evaluation's size UiPath Achieves AIUC-1 Certification | UiPath. For firms in audit, mortgage banking, or healthcare, whose agents routinely ingest documents and data feeds that could carry adversarial content (a malformed filing, a manipulated spreadsheet, an instruction hidden in a comment field), this domain isn't theoretical. It's the one closest to their daily attack surface. And because the threat landscape for agentic systems moves fast, the quarterly retesting cadence applies with particular force here: a static annual certification would likely be outdated within months. The OWASP Top 10 for Agentic Applications and MITRE ATLAS are the threat libraries AIUC-1 maps its security controls against, giving the domain a grounded threat taxonomy rather than abstract principles.

Reliability domain: hallucination prevention and the limits of what an agent should do

Reliability covers two things: hallucination prevention and tool call restrictions. Simple enough on paper, but the stakes shift the moment an agent, rather than a chatbot, is the one hallucinating.

A hallucination in a conversational interface produces a wrong sentence a human reads and (hopefully) catches. A hallucination inside an agentic workflow becomes an action before anyone reviews it: a drafted tickmark, a posted client request, a variance flagged that was never actually there. The error propagates into consequential work before a human ever gets a chance to intervene.

Tool call restrictions are about keeping the agent inside its lane. The requirement is that agents operate within clearly defined tool-use boundaries, not calling APIs, not touching data sources, not executing operations that fall outside what they've been authorized to do. This differs from Safety, which asks whether an output is harmful. Reliability asks a narrower, more mechanical question: is the output accurate, and did the agent stay inside its operational lane while producing it?

Fieldguide's July 2026 analysis offers a concrete picture of why this domain exists at all. An agent that reads a trial balance, matches it against bank feeds, flags a variance, drafts a tickmark, and posts a client request is executing a chain of consequential actions, any one of which can go wrong in ways a policy document cannot catch. Reliability controls act as the technical backstop in that chain, not a substitute for human review, catching failure before it compounds. Buyers evaluating a certification should ask specifically what hallucination-prevention controls were tested and at what error rate, since the domain mandates controls exist but says less about how well those controls actually perform in a given vendor's deployment.

Accountability domain: what happens when an AI agent fails and who is responsible

Accountability covers three requirements: documented and tested AI failure response plans, vendor due diligence on the AI components an agent depends on, and AI disclosure to customers. Each addresses a different moment in the lifecycle of a failure, before it happens, during the vendor's own upstream dependencies, and in the ongoing relationship with the client relying on the agent's output.

Professional standards don't shift responsibility onto the AI tool itself. Fieldguide's July 2026 analysis states that engagement teams remain accountable for AI-assisted work and its documentation, and Accountability controls exist precisely so a firm can demonstrate it exercised appropriate oversight rather than simply trusting the tool. That's a meaningful distinction for anyone assuming certification transfers liability. It fails to transfer liability.

Vendor due diligence matters especially for vendors building on top of third-party models or components, since the certification has to account for the entire dependency chain, not just the interface a customer sees. And AI disclosure is where accountability meets trust directly: a client whose data is being processed by an agent has a real interest in knowing that fact, and this domain turns that interest into a testable control instead of something left to a vendor's discretion. For accounting and advisory firms specifically, Accountability is where AIUC-1 addresses professional liability most directly. It asks whether a vendor has built the infrastructure to respond when something breaks, a different question from whether the vendor tried to prevent breakage in the first place, and for firms like Pease Bell, a Cleveland-based CPA and advisory practice that provides audit, assurance, and tax advisory services to businesses and institutions, that distinction shapes how they evaluate any AI tool entering a client engagement.

Data and Privacy domain: PII handling, cross-customer isolation, and IP protection

PII leakage prevents an agent from exposing personal information through its outputs, its logs, or any downstream action it takes. IP protection is the mirror image on the proprietary side, keeping client confidential information from leaking through model outputs or third-party integrations the agent touches.

Cross-customer isolation is the one with no real precedent in traditional software. An agent's context window, its retrieval mechanism, or the data it was fine-tuned on could, without explicit design and testing to prevent it, blend information across customers who were never supposed to share anything. That's a fundamentally new failure mode multi-tenant agentic platforms introduce, one traditional access-control thinking doesn't fully anticipate.

The regulatory weight here is substantial. AIUC-1 maps more than 30 EU AI Act articles to auditable requirements, and most of that mapping lands inside the Data & Privacy domain, giving organizations a practical route toward demonstrating EU AI Act alignment through the certification itself. For organizations bound by HIPAA, state privacy statutes, or client confidentiality obligations, this is the most directly regulated corner of the whole standard, converting general data-protection principles into controls tested at the level of the individual agent. Buyers in audit and advisory should look specifically at cross-customer isolation controls: an agent handling engagement data for several clients on a shared platform has to demonstrate, not merely assert, that one client's data cannot influence what another client sees. Data & Privacy covers three specific risk areas.

Society domain: guardrails against misuse at scale and systemic harm

Society covers guardrails against cyber exploitation, broader system misuse, and threats that rise to the level of national security, and it's the domain built to catch harm that scales well beyond any single deployment. This isn't about an agent failing the person using it. It's about an agent being turned into a weapon: generating disinformation at volume, enabling fraud at scale, or being manipulated into serving an exploitation campaign.

This domain is harder to pin down than Security or Safety, because prompt injection has a clean technical pass or fail. Society doesn't. Assessing whether an agent could enable societal harm requires evaluators to make judgment calls about edge cases and second-order effects that resist the kind of adversarial test you can run and log a result from. That's exactly the weakness zeltser.com's April 2026 analysis flagged: Society (Domain F) is one of the categories where documentation alone can technically satisfy the requirement, a structural gap buyers ought to probe rather than take on faith.

For financial services and audit firms, the sharpest version of this risk looks like agents enabling fraud at scale, generating financial content that misleads, or being manipulated into producing outputs that move markets or distort regulatory processes. AIUC-1 has no standard definition of "AI agent," which means vendors get to decide what falls inside their certified scope, creating a scope problem. A narrow scope can quietly exclude exactly the deployment contexts where Society-domain risk runs highest. A certificate that looks comprehensive on its face might simply have been drawn around a smaller circle than the risk actually occupies.

The quarterly update cadence and its effect on certificate meaning over time

AIUC-1 refreshes every quarter, a pace faster than SOC 2, faster than ISO 42001, faster than almost anything else in this space. That's not a minor operational detail. It changes what a certificate actually represents at any given moment.

The January 2026 update alone modified 26 requirements and added more than 40 voice-specific requirements, a single quarterly cycle that meaningfully changed what certification demands. Which raises an obvious question for anyone evaluating a vendor's badge: a certificate issued in the first quarter of a year reflects a different, earlier version of the standard than one issued in the third quarter of that same year. Buyers need to confirm which version of the standard a given certificate actually reflects, not just whether the word "certified" appears somewhere on a vendor's site.

That combination, a year-long validity period sitting on top of quarterly technical checkpoints, is the mechanism that keeps AIUC-1 from becoming a snapshot frozen at the moment of initial audit. A standard covering systems that evolve this fast probably has to move at this pace or risk irrelevance within a year. Whether quarterly is fast enough is a fair question to keep asking, but it's a considerably tighter loop than anything the compliance world has run on before. Technical testing is required at least every 3 months to keep the certificate valid, and an AIUC-1 certificate is valid for 12 months.