← All blogs

The False Comfort of AI Certification

AI agents keep acting after an assessment ends. Continued autonomy needs current evidence of agent behavior and financial protection for defined failures that get through.

A ribbon of golden light passes through a fixed stone frame and continues across a changing landscape.

Enterprises will delegate entire workflows to autonomous AI agents, including work that carries financial, legal and operational consequences. Gartner predicts that by 2028, AI agents will autonomously make at least 15% of day-to-day work decisions. Delegating that authority requires a basis for trust that stays current as the AI agent acts.

A pre-deployment assessment establishes how a system performed under the conditions examined. But the enterprise is making a much larger commitment: allowing that system to keep acting on its behalf as tools, data, permissions and circumstances change.

The evidence supporting that commitment has to travel with the AI agent. Passing an assessment cannot settle the question of whether a deployment should continue operating under the same authority months later.

Why a SOC 2 for AI Agents Will Not Work

Enterprise buyers need evidence that a software vendor can be trusted with their data and operations. A SOC 2 report provides an independent assessment of relevant controls, giving security and procurement teams a common basis for evaluating vendors. For software companies, that evidence helps answer questions that can otherwise slow or block a sale.

The appeal of a “SOC 2 for AI agents” follows the same logic: establish a standard, assess the system against it and give buyers a recognizable signal of trust. But applying that model to AI agents leaves the central question unresolved: is the AI agent exercising its authority correctly in the work it is doing now?

An assessment can examine controls and how they operated over a review period. An AI agent must keep applying instructions and obligations to new situations after that period ends. The same action may be permitted for one customer and prohibited for another, depending on the contract, permissions and facts involved. A certificate cannot establish whether those conditions were satisfied in a particular interaction.

That is why a SOC 2 for AI agents will not work as the basis for continued autonomy. Enterprises need monitoring that evaluates behavior during execution and produces evidence of what happened. A standard can require those capabilities and an assessment can examine them. Companies need that evidence throughout a deployment to know whether their AI agents are following the rules and staying within the permissions they were given.

The AI Agent Keeps Moving

An AI agent’s behavior depends on more than the version of its code. The underlying model changes. Prompts get updated. Tools and permissions expand. Customers configure the same product differently, and the information flowing through it changes every day.

Even without a major product release, the conditions under which the AI agent operates can move beyond those examined during an assessment.

Imagine a patient scheduling AI agent that has been evaluated against obligations for handling patient information. During testing, it follows the expected workflow and keeps sensitive data within the permitted systems.

A month later, the AI agent has access to an additional tool. A customer has connected a new messaging service, and the AI agent now handles requests that involve sending appointment details outside the original environment. The earlier assessment may remain relevant to parts of the system, but it does not establish whether this new workflow respects the same information boundaries.

Autonomy Requires Evidence Between Assessments

As AI agents take on more responsibility, the consequences of that gap grow. An AI agent can send messages, update records, grant access, issue refunds and make commitments on behalf of a company. Each action exercises authority that the business has delegated.

An evaluation might show that a customer service AI agent shares account details only with the account holder. In production, the company needs to know whether the AI agent actually verified who was asking before sharing those details.

These are related but distinct forms of evidence. Testing demonstrates behavior under examined conditions. Runtime evidence records how the system exercised its authority in actual interactions.

Recurring assessments provide periodic updates. Between reviews, the company still needs to know what its AI agents are doing and whether they are meeting the obligations that apply to their work.

An enterprise delegating consequential work needs an answer throughout the deployment.

Risk Lives in Individual Actions

A strong aggregate success rate can conceal failures that matter disproportionately. An AI agent can handle thousands of requests correctly and still create substantial exposure through a single unauthorized action.

A collections AI agent might contact a customer outside the permitted window. An access-management AI agent might grant a permission the requester was not entitled to receive. A healthcare AI agent might send sensitive information to an unapproved destination.

The importance of those events depends on the action, the context and the obligation involved. A small formatting error and an unauthorized payment should not disappear into the same average failure rate.

This is why assurance needs to reach the level of individual actions. Companies must be able to connect an event to the authority the AI agent had, the conditions it was required to satisfy and the outcome it produced.

A certificate alone cannot establish whether a particular boundary was crossed yesterday. That requires evidence from the deployment itself.

Financial Responsibility Follows the Work

As enterprises delegate more authority, they also need a clear account of who bears the consequences when an AI agent makes a mistake.

Usage-based car insurance shows why evidence of actual behavior matters. Progressive’s Snapshot uses information about how, how much and when someone drives, alongside traditional rating factors, to personalize their insurance rate. The insurer gains a view of risk from what happens on the road.

We believe the same principle should shape insurance for autonomous AI agents. The work an AI agent performs, the problems that emerge and the way its behavior changes should inform how its risk is understood and insured. Runtime evidence can give insurers a more current and specific basis for that assessment.

Runtime evidence helps make that discussion concrete. It can show what an AI agent was authorized to do, which safeguards were operating, where failures occurred and how the company responded. That information can support an insurer’s assessment of the exposure and help reconstruct an incident if a claim follows.

Insurance can provide financial backing for defined residual risks. Its role sits alongside prevention and corrective action, giving businesses a way to transfer specified losses they do not want to retain entirely themselves.

Monitoring Must Connect Actions to Obligations

A record of an action becomes useful evidence when it includes the context needed to assess that action. Enterprises need to understand what the AI agent did, which obligations applied and whether its behavior respected those obligations.

In Moffatt v. Air Canada (2024), the airline’s chatbot incorrectly told a customer that he could claim a bereavement-fare refund after purchasing a full-price ticket. The customer relied on that information, and the tribunal held Air Canada liable for negligent misrepresentation. The chatbot’s explanation of the airline’s policy created financial consequences for the business.

Understanding an incident like this requires connecting what the chatbot said to the policy it was supposed to explain and the circumstances of the customer’s request.

Runtime monitoring should make that relationship visible. The evidence should identify the action, the applicable rule, the relevant facts and any findings. Where the available information cannot establish whether the action was permitted, the record should preserve that uncertainty.

This is the role we are building for Ollive: checking AI agent behavior against rules drawn from regulatory and contractual obligations, flagging potential problems as findings, and providing evidence that helps teams understand what occurred.

Each Finding Should Help Improve the AI Agent

A finding gives the team a potential problem to review and, if confirmed, investigate.

Investigating a finding may reveal an outdated instruction, missing context, an incorrectly configured tool or a mismatch between the AI agent’s permissions and the authority granted by the customer. The supporting evidence makes it possible to investigate the cause and recommend a specific correction.

The correction then needs to be tested. If an AI agent repeatedly misreads a contractual limit, changing the prompt is only the beginning. The team needs evidence that the revised system handles the original scenario correctly and continues to do so across relevant variations.

This creates an operating loop: observe behavior, review findings, investigate confirmed problems, implement a correction and verify the result. What teams learn from production helps them detect similar failures more reliably and improve the AI agent’s behavior.

Ollive connects to an existing observability stack, checks traces against applicable rules, flags findings with evidence, and feeds investigation, correction and verification back into the agent.
Ollive connects to the tools your agents already run on. Explore supported integrations →

We expect that loop to become essential infrastructure for autonomous work. Companies will be able to delegate more responsibility when they can demonstrate that failures are detected, understood and used to improve the system.

Trust Becomes a Condition of Delegation

As AI agents become more autonomous, enterprise buyers will need evidence that supports continued delegation. Initial evaluation results remain part of that decision, alongside a current account of the deployment’s behavior.

A useful evidence record should show the AI agent’s operating scope, the rules being checked, material exceptions and unresolved issues. It should also make changes visible, including changes to models, tools, permissions and monitoring coverage.

Completeness matters here. A dashboard showing no findings is difficult to interpret without knowing what was monitored and what remained outside scope. Confidence should come from an inspectable account of the system, including its limits.

We believe this will change how AI vendors compete. Vendors that can substantiate their AI agents’ behavior will give enterprise customers a stronger basis for granting them consequential work. Ongoing assurance will become part of the commercial proposition, supporting larger deployments and greater autonomy.

Assurance Has to Follow the AI Agent

A certification is a photograph of a moving car. It can provide a detailed, accurate view of the conditions examined at a particular point in the journey. It cannot show the next thousand miles.

Testing and recurring assessment remain necessary. They expose weaknesses, establish baselines and examine scenarios that would be too dangerous or rare to wait for in production. Continuous evidence carries that work into the operating environment, where the AI agent exercises its authority.

We are building toward enterprises that can delegate consequential workflows without requiring a person to approve every step. That future needs monitoring that operates during execution, evidence that remains current and financial protection for defined failures that get through.

A certificate can support the initial decision to deploy. An autonomous workforce needs an ongoing basis for being trusted with the work.

Take on bigger AI deployments
without taking on unlimited AI risk.