AI Assurance Report Structure and Deliverables

AI agents that call APIs, touch enterprise data, and take action on their own don't fit the assurance models built for traditional software. AIUC-1, a certification standard from the Artificial Intelligence Underwriting Company, is an attempt to build a new model specifically for that gap, and understanding its structure, its audit mechanics, and its deliverable is the only way to know what a vendor is actually claiming when they show you a certificate.

Traditional software runs on logic someone wrote down in advance. An AI agent doesn't work that way. It reads context, decides what tool to call, and acts, often with a human somewhere downstream who never sees the intermediate steps. That gap between "what the software was told to do" and "what the agent actually did" is where a new category of risk lives: prompt injection, unauthorized tool calls, data bleeding across tenants, hallucinated outputs that trigger something real in the world, like a wrong refund or a bad medical suggestion passed along as fact.

SOC 2 was never built to answer whether an agent resists a jailbreak attempt. It attests to controls at the organizational level, so it can tell you a service organization has decent access management and change control, but it says nothing about how a specific model behaves when someone tries to manipulate it. AIUC-1 was built to close that specific hole. It was developed with input from Orrick, MITRE, the Cloud Security Alliance, Stanford, MIT, and a group of enterprise security leaders, and it publishes crosswalks to ISO 42001, the NIST AI Risk Management Framework, the EU AI Act, MITRE ATLAS, and both the OWASP Top 10 for LLM Applications and the newer OWASP Top 10 for Agentic Applications. The company emerged from stealth in 2025 with a reported substantial seed round backed by Nat Friedman, with Stanford professor Sanmi Koyejo and former Google Cloud CISO Phil Venables advising. Early certified organizations include Cursor, Fin, ElevenLabs, Harvey, UiPath, and KPMG, which is worth noting because it signals uptake among both product companies and professional services firms that have their own liability exposure to think about.

The six control domains the standard covers

AIUC-1 organizes more than 50 controls across six domains, and reading any audit report without understanding these six is like reading a financial statement without knowing what a balance sheet is supposed to balance.

Data and Privacy governs what the agent can reach: which systems, which records, and how the standard prevents cross-customer exposure, PII leakage, or an agent accidentally handing over credentials it shouldn't have touched in the first place.

Security covers adversarial robustness and input filtering, aimed at stopping unauthorized agent actions before they happen. This domain maps directly to the MITRE ATLAS threat taxonomy and the OWASP Top 10 for Agentic Applications, so the testing here isn't improvised; it's built against a known catalog of attack patterns.

Safety deals with risk taxonomy and pre-deployment testing, the work of catching harmful or out-of-scope outputs before an agent ships. Reliability is a related but distinct concern: preventing hallucinated outputs and restricting the agent from making tool calls that aren't safe given its current context.

Accountability is the paperwork domain, though calling it just paperwork undersells it. It covers AI failure plans, assigned ownership, acceptable use policy, activity logging, and vendor due diligence requirements, the kind of documentation that answers "who is responsible when this breaks" before it breaks. Society rounds things out by addressing cyber misuse, catastrophic misuse scenarios, and the ethical and downstream consequences of decisions an AI system makes on someone's behalf.

None of these six domains are written as principles to aspire to. Each has defined controls and evaluation criteria, which means the framework is built to produce testable, auditable requirements rather than language a vendor can wave at during a sales call. And the standard doesn't sit still: recent quarterly cycles have added requirements around MCP and A2A protocol security, agent identity, and agent access management, which tells you the standard is being revised as fast as the agent architectures it's trying to cover.

How the audit process works (governance review and adversarial testing together)

The structural feature that separates AIUC-1 from a typical compliance audit is that certification requires both a governance review and adversarial technical testing of the agent itself. A policy binder alone will not get a vendor a certificate.

The governance component looks familiar to anyone who has sat through a SOC 2 audit. Auditors review documented controls, policies, and procedures across all six domains, checking for assigned ownership, an acceptable use policy, AI failure plans, vendor due diligence records, and evidence that activity logging actually happens and actually gets reviewed.

The adversarial component is where AIUC-1 diverges from a standard attestation. Something has to actually try to break the agent, and the results of that attempt become part of the evidence record, not a side note. Testing includes prompt injection attempts, jailbreak scenarios, probes designed to leak data across tenant boundaries, unauthorized tool call attempts, and stress tests meant to see whether the agent hallucinates under pressure. The adversarial testing component is designed to produce findings that change the product, not merely document it, a meaningful distinction from a compliance exercise that ends with a checkbox.

Audits are performed by third-party firms accredited by AIUC, and Schellman is the first organization to hold that accreditation. Between the annual audits, quarterly technical retests keep running, a cadence that exists because agent architectures change fast enough that an annual check alone would leave long windows where nobody's really looking.

AIUC-1 doesn't define what counts as an "AI agent."" The vendor decides which agent or system is in scope and which tools and integrations get tested. That's not necessarily a flaw, but it does mean the scope of any given certificate is set by the party being certified, not by an external definition, and that's worth remembering the next time someone hands over a report.

What an AIUC-1 report contains as a deliverable

The deliverable itself is where AIUC-1 earns its distinction from a SOC 2 opinion. A SOC 2 report describes organizational control design and, in a Type 2, whether those controls operated effectively over a period. An AIUC-1 report is about behavior: what a specific agent did when someone tried to make it misbehave.

The report documents findings against each of the six domains, combining governance assessment results with adversarial test outcomes in the same record. It includes what was tested, how it was tested, and what came out of it, meaning gaps found, guardrails added in response, and whatever residual risk remains after the fixes. Certification status attaches to the specific agent or system that was in scope, not to the organization as a whole, and the report should include evidence that the auditing firm holds current accreditation from AIUC.

What does the report actually certify? That the named agent met the defined controls across all six domains at the time of the audit, that adversarial testing happened and got documented, and that quarterly retests are scheduled going forward. That point determines an outcome: quarterly retests are scheduled going forward, unlike a SOC 2 Type 1, which covers a one-time snapshot. It's built with a refresh cycle baked in.

What it doesn't certify matters just as much. A certificate covers the named agent and nothing outside that defined scope. It's not a substitute for the organizational controls that ISO 42001 or SOC 2 address, and it doesn't mean compliance with any specific regulation, even though AIUC-1 crosswalks to the EU AI Act and the NIST AI RMF. Because of the quarterly refresh model, anyone reviewing a certificate should check which quarterly cycle it reflects. A certificate issued eight months ago describes an agent that may have changed considerably since.

How AIUC-1 relates to SOC 2, ISO 42001, and the NIST AI RMF, and where the gaps remain

The cleanest way to sort these frameworks is to ask what question each one is actually answering. SOC 2 asks whether the service organization has sound controls, an organizational-level question. ISO 42001 asks whether the organization runs a functioning AI management system, which is a governance and process question. AIUC-1 asks something narrower and more specific: does this particular agent behave safely and securely under real, adversarial conditions? The NIST AI RMF, along with the draft NIST Cyber AI Profile (IR 8596) released in 2025, offers risk management guidance but no direct certification path at all.

SOC 2 and AIUC-1 aren't competitors; they coexist, because they answer different questions. A vendor with a clean SOC 2 report has told you nothing about whether their agent resists prompt injection or invents a policy answer under pressure. That's simply outside what a SOC 2 audit looks at.

ISO 42001 is the trickier comparison, and the one most often conflated with AIUC-1 by people skimming both. ISO 42001 certifies a management system, the organizational scaffolding around how AI gets developed and governed. AIUC-1 certifies a specific agent's behavior. AIUC's own published crosswalk is candid about where the two diverge: full gaps exist at several ISO 42001 clauses, including interested parties, AI objectives and planning, internal awareness and training, responsible AI development objectives, and customer expectations, with only partial coverage of AI system impact assessment. An organization holding an AIUC-1 certificate has not thereby met ISO 42001. Those are two separate accomplishments that happen to rhyme.

The accreditation model also invites closer examination. ISO 42001 runs through accredited certification bodies external to the standard itself. SOC 2 sits under AICPA governance. NIST carries the weight of a federal agency behind it. AIUC-1, by contrast, is accredited by AIUC itself, so the certificate's authority currently rests on AIUC's own governance rather than an outside standards body. It amounts to a different trust model than the other three, and buyers should know the difference going in.

Combine that with the scope discretion mentioned earlier, where the vendor decides what counts as the agent under test, and a picture emerges of a standard still finding its footing on definitional questions even as its technical testing methodology matures quickly. For organizations already holding a SOC 2 report, working with an advisor who understands both attestation frameworks helps clarify exactly what an AIUC-1 deliverable adds to what's already on file, and what it doesn't.

What organizations should verify when they receive or review an AIUC-1 report

Start with scope. Which specific agent or system got certified, what tools and integrations were included, and just as important, what got explicitly excluded? A certificate that covers a customer-support chatbot says nothing about a separate agent handling internal document retrieval.

Check the audit cycle next. Confirm which quarterly period the certificate reflects and whether retests have run since issuance. Because of the refresh model, a certificate that looked current at signing might already be a quarter or two stale by the time it lands on a procurement desk.

Read the adversarial testing results directly, not just the governance section. The whole differentiator of AIUC-1 is the technical testing record, so a report that documents policy compliance but skips the adversarial outcomes should raise a question, not settle one. Verify the auditor's accreditation too. Schellman was first, but as the accredited auditor list grows, confirming current accreditation status is a five-minute check worth doing every time.

Look for residual risks in the findings. Adversarial testing exists to surface gaps, so a report showing zero findings anywhere deserves more scrutiny about how deep the testing actually went, not less. And remember what the certificate doesn't cover: pair it with the vendor's SOC 2 status, ISO 42001 status if applicable, and whatever regulatory documentation actually applies to the deployment in question. For financial services, healthcare, or mortgage banking specifically, AIUC-1's crosswalks to the EU AI Act and NIST AI RMF are a starting point for mapping findings against sector risk, not a finish line. Industry-specific regulatory obligations still need their own separate review. An advisor experienced in both SOC examinations and the newer AI assurance standards is positioned to help sort through where an AIUC-1 report actually lands relative to everything else in a vendor's assurance file, and what's still missing.