We Independently Audit Financial Controls. Why Wouldn't We Independently Test AI Agents?

On September 18, 2026, Anthropic and Accenture announced a multiyear initiative in which each company will commit at least $1 billion over five years — at least $2 billion in total — to expand independent evaluation of advanced AI models. As reported, the work will be led by Faculty, Accenture's specialist AI business, and covers red-teaming, alignment assessments and safeguard testing, plus a newer “embedded evaluation” model in which evaluators work inside the lab with employee-level access to observe training and deployment decisions rather than inspect a finished product from the outside.

Anthropic's own framing is careful: independent evaluators, it says, do not reduce the company's accountability but make it more verifiable, and the safety of its models remains its own responsibility. The arrangement also carries an honest weakness — the company being evaluated is funding the evaluator, and standards for what evaluators may access and how they report are still undeveloped. Anthropic has described eventual pooled or government funding across a wider ecosystem of evaluators as the intended end state. Crest.Digital has no role in this initiative; the interest here is not the partnership but the model, because it is a model enterprises already understand from audit, controls and compliance.

Every CFO and Chief Audit Executive recognizes the logic: management designs and operates the controls, but a separate line of assurance — internal audit, external audit, a compliance testing function — verifies that those controls actually work. Enterprises are now deploying AI agents that approve, route, reconcile and change records inside core systems. Yet for most of them the equivalent of that second line does not exist. The agent's builders, its operators and its only testers are frequently the same team. Crest.Digital's Agentic Risk & Continuous Assurance practice treats that as the next control gap to close, building on its earlier work on the AI agent audit-trail assurance gap and why agents need audit trails.

What Was Announced, and What Is Worth Borrowing

Three features of the announcement matter for enterprise risk teams, independent of any view on the lab itself. First, independence is being treated as a funded, standing capability, not a one-time pre-launch review. Second, access is the point: embedded evaluators can see how decisions are made, not just what the model outputs, which is the same reason internal auditors insist on system access and walkthroughs rather than management-prepared summaries. Third, the announcement openly concedes that independence has design problems — funding conflicts, undefined access rights, no reporting standard — which is exactly the territory auditor-independence rules were written to address in financial reporting.

None of this means a frontier model's safety evaluation substitutes for testing an enterprise agent. It does not. A model-level evaluation tells you how a model behaves in general; it cannot tell you how your agent, with your permissions, connected to your ledger and vendor master, behaves on a Tuesday close. That second question has no external evaluator unless the enterprise builds one.

The Self-Attestation Gap in Enterprise AI

Ask most organizations how they know an AI agent is behaving within policy and the answer is some version of self-attestation: the vendor's documentation, the implementation team's test plan, a dashboard the operating team built, or a periodic review chaired by the same function that deployed the agent. Each of these has value. None of them is independent, and none of them tests the agent as it actually runs in production against the organization's real permissions and real policies.

The pattern is familiar from financial controls. A control owner's statement that a control works is a representation; an independent test of the control is evidence. The IIA's Global Internal Audit Standards build the internal audit function around exactly this separation, and COSO's Internal Control–Integrated Framework treats ongoing and separate evaluations as distinct components of effective internal control. AI agents introduce a new class of control subject, but they do not exempt anyone from the principle.

There is also a practical reason the second line matters more for agents than for conventional software. Agents act on instructions interpreted at run time, so their behavior can drift with a prompt change, a model upgrade or a newly connected tool without any change a traditional release process would flag. Our earlier piece on agent identity and access governance made the permissions side of this argument; the independent-assurance question is the verification side. Permissions say what an agent may do. Independent testing establishes what it does.

From Model Assurance to Enterprise Agent Assurance

Translating the concept from the model layer to the enterprise layer gives a seven-link chain: Agent → Independent Control Test → Permission → Policy Compliance → Exception → Human Review → Evidence. The difference from a conventional agent-governance checklist is the second link. Testing is performed by a mechanism that is separate from the agent, its builder and its operator, and it is repeated, not run once at go-live.

The Agent is the unit under test, identified in an inventory with a named business owner. The Independent Control Test is a defined, repeatable procedure — scenario replays, boundary probes, sampled production decisions re-performed — executed outside the agent's own logic. Permission checks that what the agent can actually reach matches what was approved. Policy Compliance checks that its actions conform to the written policy or control it is supposed to implement. An Exception is any divergence, captured with a reason and a root-cause hypothesis rather than a bare flag. Human Review assigns that exception to an accountable person who decides, in line with the point we made in who is accountable when the GRC function is agent-ready. And Evidence closes the loop with a timestamped record that survives to the next audit.

This is the same execution logic used across Crest.Digital's controls work — read, test, detect exception, assign, follow up, evidence closure — pointed at a new subject. The auditor remains the decision-maker; the independent test layer does the repetitive re-performance and coordination that a small audit team cannot sustain at agent speed.

Six Independent Tests Worth Running on Every Material Agent

Organizations that already have an AI inventory can start with six tests. Each is deliberately independent of the agent's own logging and the builder's own test suite.

The sixth test is the one most often skipped, and it is the most important for independence: an agent that writes its own audit log is, in effect, marking its own homework. For the audit-trail design behind that point, see our guidance on agent audit trails.

Standing Up the Independent Layer: A Six-Step Delivery Playbook

Crest.Digital delivers this as a configurable “Risk Automation Pod” rather than a bespoke software build. The reusable stack — integration connectors, agent orchestration, a workflow and approval engine, a rules and risk-scoring engine, an evidence repository, AI logs and explainability, and role-based access — is common across engagements; the client-specific work is the data mapping, test logic, thresholds and reporting format.

One design choice deserves attention: the independent test layer should not be built by the same team, or on the same stack and credentials, as the agents it tests. Organizations can meet that standard by placing ownership of the test layer with internal audit or a second-line risk function, even where the engineering is performed by a specialist partner.

The Board Question, and Its Honest Limits

For audit committees the question is simple to ask and revealing to answer: for each AI agent that can affect financial reporting, vendor payments, access rights or regulatory filings, who other than its builders has tested it, how recently, and where is the evidence? The ISACA white paper on securing AI agents applies the same governance rigor to agent identities and action logs that organizations already apply to privileged human users, and regulators are moving in a compatible direction; the EU AI Act's regulatory framework already places conformity assessment and documentation duties on high-risk systems. Our earlier look at what internal audit should be testing in autonomous AI controls shows the same expectation emerging in other jurisdictions.

The limits deserve candor, because the Anthropic and Accenture arrangement itself surfaces them. Independence is a spectrum: an evaluator paid by the evaluated party needs safeguards, which is why audit firms operate under independence rules and why the PCAOB exists. An enterprise independent-assurance layer faces a smaller version of the same problem. Reporting lines, access rights and the handling of adverse results should be defined up front, ideally with results flowing to the audit committee rather than only to the function that owns the agent. And an independent test layer is itself software that needs governing — which is why its logs and thresholds should be inspectable by humans, not opaque.

The practical takeaway is not that every enterprise needs a $2 billion program. It is that the separation of builder and verifier, long settled in finance, is about to be applied to AI, and the organizations that already operate independent, continuous tests over their agents will be able to answer the board, the regulator and the customer with evidence rather than assurance.

Frequently Asked Questions