TL;DR. AIUC-1 is the AI agent certification standard maintained by the Artificial Intelligence Underwriting Company, which raised a $40 million Series A on September 15, 2026. A certificate means the agent, as scoped, survived 1,000 to 5,000 red-team scenarios and an auditor found evidence for the standard's controls; it is valid for a year, retested quarterly. Runtime enforcement is a different instrument: a gate that decides each tool call as it happens. The standard's own evidence templates draw the line (D003 wants authorization before tool execution and a per-call log, B006.3 wants pre-execution policy hooks, A003.3 wants permissions scoped to subtasks), so the certificate audits whether such a gate exists. A September 2026 evaluation puts numbers on the gate's shape: a role ceiling closes 27.9 percent of the standing-credential attack surface, task scoping closes 84.4 percent, and the residual concentrates in one coarse permission, database_read.
AIUC-1 had a busy week. On September 15 the company behind it announced a $40 million Series A led by Ribbit Capital, bringing its total raised to $55 million, and said the money would take its audit and insurance work from applications up to the frontier models themselves. On September 17 Sierra joined the certified list alongside Cursor, Fin, ElevenLabs, Harvey, UiPath and KPMG, and the standard's homepage stamped its Q3 update with the same date. If you sell an agent into an enterprise, a security reviewer is going to ask about it soon. If you run agents against production systems, the question that matters is narrower: what does the certificate actually tell you about the next tool call?
What a certificate attests, and when
The certification process has four steps, and the first one bounds everything that follows. Scoping fixes which agent or system is being certified, its deployment context and its "agent configuration and interface bounds", and locks the standard version for one year. Evals run 1,000 to 5,000 scenarios against that configuration: jailbreaks, prompt injection, data leakage, hallucinations and unsafe tool calls. An accredited auditor (Schellman and Coalfire are named) reviews policy, operational and technical controls across the six domains. Then a certificate and a 50-plus page audit report are issued, valid for one year, with quarterly retests on the locked standard version.
Three properties follow from that shape. The certificate belongs to a configuration, and the scoping document is where that configuration is written down. The evidence is sampled: a few thousand scenarios per cycle against an agent that may make that many tool calls before lunch. And the cadence is quarterly, while the things that change an agent's behavior (a model update from the provider, a new tool definition on an MCP server, a permission somebody widened to unblock a workflow) change on no schedule at all. None of this is a criticism of the audit. It is what an audit is. SOC 2 has the same shape and nobody expects a SOC 2 report to reject a malicious request at 3 a.m. The badge is a property of the product at a point in time, inside stated bounds, plus a finding that the vendor operates certain controls. Neither part is a decision about the call your agent is about to make.
The standard already asks for a runtime gate
The interesting part of AIUC-1 for engineers is the evidence templates: the concrete artifacts an auditor accepts as proof. They read like a specification for the runtime layer.
Requirement D003, "Restrict unsafe tool calls", is mandatory for automation agents. Its first evidence item, D003.1, is code or configuration showing "authz checks before tool execution", tool allowlists and parameter validation. D003.2 is rate limits and circuit breakers on tool usage. D003.3 is a tool call log that captures "the originating MCP server, tool name, tool version, input parameters, and timestamps per invocation". D003.4 is human approval for sensitive operations. D004 then requires an expert third party to test tool calls at least every three months, which is the audit checking that the gate does what the evidence says.
Requirement B006, "Prevent unauthorized AI agent actions", goes further into the runtime. B006.1 accepts an MCP server allowlist and service-level authorization. B006.3 accepts "pre-execution authorization hooks that verify runtime tool calls against defined policy before execution proceeds", sandboxes with credential restrictions, and "monitoring MCP tool definitions for unauthorized changes after initial approval". That last clause is the standard acknowledging that the thing certified in Q1 can be quietly redefined by a server in Q2, which is the MCP instructions problem in audit language.
Requirement A003, "Limit AI agent data access", is where permissions get task-shaped. A003.1 wants "session scoping configuration limiting data access per session" and "scoping functions rejecting out-of-scope queries". A003.3 wants "just-in-time permissions scoped to specific subtasks", prevention of "silent inheritance of elevated permissions from orchestrators or parent agents", and a segregation-of-duties matrix for conflicting permission combinations. E015 wants logs of "processes, actions, and agent outputs".
Put those together and the division of labor is explicit. The gate decides each call: scope it to the task, check it against policy before execution, refuse forbidden combinations, log it with enough fields to reconstruct what happened. The certificate audits that the gate exists, produces the artifacts, and holds up under adversarial testing. A vendor that shows an auditor an allowlist has passed D003.1; the customer whose data sits behind it still depends on the allowlist being enforced on the call that matters.
Which shape of gate closes the surface, in numbers
Enforcement at the call is expensive to get right, so it helps to know which parts carry the weight. On September 14, 2026, Halil Burak Noyan posted an end-to-end evaluation of a three-source permission architecture for enterprise agents. The setup is a 600-prompt synthetic dataset over a six-department company policy, a 15-permission taxonomy where every permission maps to a deployable credential and carries a risk tier, and a metric that weights each removed permission by its tier. A "grant everything" baseline scores 31 severity-weighted units per task.
What each instrument sees. The certificate samples the agent a few times a year; the gate sees every call. Bar values from arXiv:2609.15422, Table 3.
The three sources are a per-department role ceiling, a classifier that reads the task description and predicts the permission set it needs, and a small set of policy-derived prohibitions on permission pairs (the "lethal trifecta" pattern: private data plus untrusted content plus an outbound channel). From the paper's Table 3:
- The role ceiling alone, which is what a role-based service account gives you, closes 27.9 percent of the severity-weighted surface.
- Adding the task-scoped classifier closes 84.4 percent, which is 78.3 percent of what a role-scoped deployment still carries.
- The prohibition layer adds nothing measurable on top of a precise classifier, because no forbidden pair reaches it. With the classifier bypassed entirely it trims 11.5 to 13.6 percent off three departments' ceilings.
The ratio between the first two numbers is the paper's argument for task granularity: enterprises settled for role-based access because re-provisioning a human per task was impractical, and an agent's task arrives as text, so the scoping decision becomes a classifier inference. The fine-tuned 355-million-parameter encoder that makes that decision matched a frontier model on macro-F1 (0.881 against 0.886) with higher precision (0.897 against 0.842), so the trusted component does not have to grow with the agent it supervises.
The prohibition result decides where enforcement has to sit. Applied statically, before the task starts, to a role ceiling that legitimately holds both halves of a forbidden pair, the rules blocked 6 percent of Engineering tasks, 22.2 percent of Security tasks and 31.1 percent of Data and Analytics tasks, and 56 of the 57 blocked tasks never invoked both halves. Blocking the second permission only when it is actually invoked after the first removes that cost in principle, so the paper's conclusion is that the ceiling and the classifier belong at provisioning and the prohibitions at runtime. It also states plainly that the runtime mode is designed and not evaluated, and that every friction number inherits a synthetic dataset and a 100-record test split. Treat the ratios as the finding and the decimals as noise.
database_read is where the residual lives
One detail from the paper matters more to database teams than the headline percentages. At the recommended configuration, three permissions accounted for 58 percent of all over-grant events, and database_read alone accounted for 25 percent. Weighted by risk tier, database_read carried 34 percent of the residual overshoot. The ceiling-fallback friction was caused entirely by database_read and file_read_uploaded. The author's diagnosis is that above roughly 0.89 macro-precision the classifier is no longer the limiting factor; the taxonomy is. A single label conflates reads with very different risk, and the proposed next step is to split database_read into sensitivity-qualified variants.
That is the point where an access-control paper and a database problem meet. "Read access to the database" is a credential, not a policy. The policy a reviewer actually wants to enforce is about which tables hold personal data, which columns are restricted, which view is the sanctioned one and which is a stale copy, and whether the join the agent is about to run reconstructs something no single table exposes. Postgres will let you express some of that with roles, row-level security and column grants, and read-only access alone does not make an agent safe because none of those primitives know what the data means. A runtime gate that wants a finer decision than database_read needs the meaning of the schema in front of it at decision time: entity, sensitivity, lineage, and who validated the classification. Without that, the gate degrades to the coarse permission the paper found at the center of the residual.
What to ask for, on each side of the badge
If you are the buyer, ask for the audit report, and in it for the D003 and A003.3 evidence rather than the summary. Ask for the scoping document's agent configuration and interface bounds, and check that your deployment sits inside them; a certificate for a support agent scoped to a CRM says little about the same product wired to your warehouse over MCP. The AIUC-1 Q2 2026 update added MCP security and agent permissions to the standard, so anything certified on an earlier version was not tested against those controls until it recertified.
If you are the builder, build the gate the evidence templates describe and let the certificate be the audit of it: authorization per tool call, permissions scoped to the task rather than the service account, forbidden combinations enforced when the second half is invoked, and a per-call log with the originating server, tool, version, parameters and timestamp. That log is the same artifact Article 12 of the EU AI Act asks high-risk systems to keep, and the same one an agent security gateway has to produce to be worth deploying. One gate, three audiences.
The category is consolidating around this split: in the same fortnight, Mem0's gateway separated connecting a tool from granting it and AIUC raised to audit the models underneath. Prevention at the call and attestation of the process are becoming two funded layers, and the standard reads as if written by people who expect you to have both.
Where Datapace fits
Datapace is building the context layer between your databases and your AI: resolved meaning validated by the people who own the data, the workload evidence beside it (cost, performance, usage and freshness, lineage), and a policy gate over what an agent may do and access, served over MCP. The gap the paper found at database_read is the gap that layer exists to close: a gate can only scope a query as finely as it understands the schema behind it. If your agents touch production databases and a security review is coming, start with how to give an AI agent safe access to a production database, or book a call.
A certificate is a good thing to have and a bad thing to mistake for a control. AIUC-1's authors seem to know this, which is why the evidence they accept for the security and reliability domains is, almost line for line, a description of a runtime gate. Get the gate right, keep its logs, and the audit becomes the easy part.
Sources
- AIUC, AIUC-1 Certification homepage, Q3 update dated September 17, 2026 (six domains, four-step process, scenario counts, quarterly retests, one-year validity, certified companies, Q2 2026 update on MCP security and agent permissions).
- SiliconANGLE, AI agent certification startup AIUC raises $40M to begin auditing frontier models, September 15, 2026 (Series A, Ribbit Capital, $55 million total, frontier model audits).
- AIUC-1 Standard, B. Security, D. Reliability, E. Accountability and Evidence (requirement text and evidence templates A003.1, A003.3, B006.1, B006.3, D003.1 to D003.4, D004, E009, E015).
- Halil Burak Noyan, Empirical Evaluation of Task-Based Permission Scoping Architecture for AI Agents, arXiv:2609.15422, September 14, 2026 (Tables 1, 3, 5 and 6; Sections 4.2, 6.5 and 7).