AI agents are moving into the operating structure of businesses. In McKinsey’s August 2026 research, 40% of respondents at organizations with more than $1 billion in annual revenue reported scaling AI agents, up from 27% the previous year. These systems are increasingly being deployed within business functions, rather than used only as individual productivity tools.
The infrastructure for governing that work is developing less evenly. Deloitte’s 2026 research, covering 3,235 business and technology leaders across 24 countries, found that only 21% of respondents reported a mature governance model for agentic AI. The practical challenge includes defining which decisions agents can make, monitoring their behavior, and preserving a record of their actions.
Businesses already have a mechanism for some of the financial consequences of professional mistakes. Professional liability insurance protects service businesses against covered losses arising from errors, negligence, and malpractice. Underwriting that exposure requires understanding the work, the obligations attached to it, and the circumstances in which a mistake becomes a financial loss. Delegating work to an agent creates a new measurement problem inside that familiar insurance problem.
The spec defines how to record an AI agent’s assigned role, the obligations governing its work, what it did, and what happened afterward. It defines how those pieces of evidence should connect so engineering, legal, business, and insurance teams can review the same interaction with its context intact.
In practice, a team using CRMS documents the agent’s authority, maps the applicable obligations, defines how behavior is evaluated and reviewed, and retains the evidence behind each finding. That record supports decisions about agent risk while making missing information and unresolved questions visible.
A warranty promise, from conversation to evidence
Consider a hypothetical customer-support agent authorized to explain warranty coverage. It can confirm repairs covered by the active policy, but an exception requires approval. A customer asks about a repair that the policy excludes.
The agent retrieves the policy and replies, “Yes, this repair is covered. Go ahead and book it.” The customer authorizes the work because of that assurance. The tools executed successfully and the response was fluent, so a dashboard tracking latency and task completion could record a successful interaction.
A CRMS evidence record would bring the following facts together:
- Role and authority: The agent may explain the warranty and confirm eligible repairs. It needs approval to promise coverage outside the policy.
- Applicable obligation: Coverage statements must match the warranty terms that apply to this customer, unless a valid exception has been approved. The record links to the active policy version and its exclusion.
- Observed behavior: The conversation trace preserves the customer’s request, the retrieved policy, and the exact turn promising coverage. The agent and policy versions are retained with the interaction.
- Finding: The promise conflicts with the policy exclusion. The reviewer checks the approval record to establish whether an authorized exception existed; missing approval evidence remains an unresolved question.
- Known outcome: In this example, the customer relied on the statement and authorized the repair. Evidence supporting that reliance, such as the customer’s confirmation or booking record, belongs alongside the conversation.
- Still to establish: Whether an exception was approved, whether the statement was corrected, what costs the customer incurred, and whether the business reimbursed them or faced a claim. Insurance coverage would require a separate assessment under the relevant policy.
The finding identifies a potentially unsupported coverage promise for review. Connecting it to authority, reliance, and the eventual outcome lets the business investigate what happened and assess the resulting exposure without treating every incorrect answer as an established legal liability.
What existing AI governance and security frameworks already provide, and where the gap remains
Businesses are not starting from zero. Existing frameworks provide substantial foundations for governing AI, securing systems, and evaluating their behavior.
They also serve different purposes. A management-system standard, a risk framework, a security taxonomy, an assurance report and quarterly audits should not be treated as interchangeable certifications.
| Framework or assurance approach | Its contribution | How CRMS builds on that foundation |
|---|---|---|
| NIST AI RMF | Organizes AI risk management around governance, context, measurement, and treatment. Its guidance explicitly addresses legal risks and third-party rights. | Connects those objectives to a role-specific record of obligations, production findings, and consequences. |
| ISO/IEC 42001 | Defines requirements for establishing, maintaining, and improving an organizational AI management system. | Structures operational evidence that can support the organization’s management and review processes. |
| SOC 2 | Provides assurance over controls within a defined scope against applicable trust-services criteria. Type II examinations address operating effectiveness over a period. | Supplies detailed records of agent behavior and interventions that may support relevant control evidence. |
| OWASP AI guidance | Identifies technical risks such as prompt injection, excessive agency, sensitive-information disclosure, and misinformation. | Connects technical findings to the obligations and potential consequences of the agent’s assigned work. |
These approaches already recognize many relevant risks. The practical question is how consistently an implementation can reconstruct the evidence when an agent crosses a boundary.
The warranty example shows the record CRMS specifies: the applicable obligation, policy and agent versions, the agent’s statement, its authority, any intervention, and the customer’s outcome. Keeping those connections explicit gives reviewers a shared basis for distinguishing supported conclusions from disputed or unknown facts.
Responsibility, liability, and risk are different
Clear measurement starts with clear terminology.
Responsibility describes assigned duties and ownership: what the agent is authorized to do and which people or organizations must supervise, approve, or respond.
Liability describes legal accountability under applicable law or contract. A monitoring result can identify evidence relevant to liability; it does not itself decide a legal claim.
Risk describes the possibility and severity of an adverse outcome. Here, financial risk concerns the losses or expenses that may arise from agent behavior, including consequences that never become an adjudicated liability.
Financial exposure describes the potential losses and costs being considered. Insurance coverage is a further question, governed by a particular policy.
CRMS connects these concepts without collapsing them:
A failure is not automatically a legal violation. A violation is not automatically a claim. A claim is not automatically an insured loss. Those distinctions determine what evidence must be collected and what conclusions it can support.
The role is the starting point
Two agents using the same model can create very different exposure. Consider the same example of a customer support agent.
One answers internal documentation questions. Another communicates with customers, explains a policy coverage, and authorizes repairs.
Their risk depends on the work they perform, the authority they hold, the people who rely on them, and the obligations governing the interaction.
CRMS therefore starts with an agent in a defined operational role, rather than treating the model as the complete unit of assessment.
The initial scope is an individual agent’s role and its interactions with people, tools, and business systems. Where workflows involve multiple agents, the record must identify handoffs and dependencies; an assessment of one agent should not be presented as assurance over the whole workflow.
Three sources of exposure
CRMS organizes analysis around three sources of obligations. They can overlap, and each must be tied to the relevant entity, activity, jurisdiction, and facts.
1. Legal requirements: what does the law require?
Statutory and regulatory obligations can apply to an agent’s work even when the relevant law does not mention AI. Depending on the activity, these can include consumer protection, privacy, discrimination, intellectual-property, and sector-specific requirements.
Consider an agent contacting consumers about debt. Regulation F restricts communications by covered debt collectors at unusual or known inconvenient times. Subject to applicable exceptions, times before 8 a.m. and after 9 p.m. in the consumer’s location are presumed inconvenient when the collector lacks contrary information. Known consumer preferences also matter.
A useful check requires more than “do not contact customers too early.” It needs to establish whether the rule applies, the relevant location and time, known preferences, and any applicable exception.
The obligation record must preserve the source, interpretation, effective date, and facts required for evaluation.
It must also distinguish potential consequences. An investigation, corrective action, and monetary penalty are different outcomes. Public enforcement and private claims are different pathways. A single “regulatory risk” score obscures those differences.
2. Contractual commitments: what has the business agreed to?
Contracts define obligations between particular parties. They may include service levels, warranties, confidentiality duties, approval requirements, and indemnities.
For the customer support agent described above, the first question is what coverage the business actually promised. A separate agreement between the AI provider and the deploying business may allocate responsibility for failures in the service.
CRMS retains both relationships. It identifies who owes the obligation, to whom, and under which agreement.
It also distinguishes obligations from provisions affecting remedies or allocation of loss. Liability caps, exclusions, notice requirements, and indemnities can change the financial consequences of an incident, but their effect depends on the agreement and applicable law.
A missed service commitment, an unauthorized payment, and a promise of reimbursement are different events. They require different evidence and should not automatically be assigned the same financial consequence.
3. Duties beyond contract: what duties arise independently of an agreement?
An organization may face claims based on duties that do not depend on an express contractual promise. Depending on jurisdiction and circumstances, these can include negligence, negligent misrepresentation, and professional duties.
The Air Canada chatbot dispute illustrates why the surrounding facts matter. In Moffatt v. Air Canada, the British Columbia Civil Resolution Tribunal found negligent misrepresentation after a customer relied on incorrect chatbot information about bereavement fares. It awarded C$650.88 in damages, plus interest and fees.
The useful record extends beyond “the answer was wrong.” It includes the representation, the source information, the context, the customer’s reliance, and the connection to the loss.
Historical cases can help identify relevant factual patterns, including cases involving humans doing similar work. Their interpretation must preserve jurisdiction, procedural status, and the distinction between allegations and findings.
CRMS records the evidence needed for that review. Legal conclusions remain subject to the applicable law and facts.
Operational authority applies across all three
Businesses also define internal boundaries: refund ceilings, tool permissions, approval paths, escalation rules, and product scope.
These are operational requirements. Some implement legal or contractual duties; others are safeguards chosen by the business.
An agent authorized to issue refunds up to $100 might execute a $500 refund, promise one without executing it, or fail to escalate a request. Those are three distinct findings.
An API credential may permit an action that the agent’s assigned role does not authorize. Language can also create exposure without a tool call.
CRMS links operational boundaries to their underlying obligations where that relationship exists. A boundary violation remains an operational finding until the evidence supports a more specific conclusion.
What the CRMS spec contains
CRMS defines five connected artifacts. Together, they establish the context for evaluation and the record needed for review.
| Artifact | Required content | Customer support agent example |
|---|---|---|
| Role and Authority Record | Duties, permitted actions, approval limits, prohibited behavior, escalation responsibilities, and accountable owners. | Explain coverage; obtain approval for exceptions. |
| Obligation Map | Sources, obligated entities, applicability, interpretations, versions, effective dates, and required evidence. | Connect a coverage statement to the applicable warranty and customer circumstances. |
| Monitoring and Review Procedure | Evaluation methods, sampling, classifications, review ownership, detector performance, and treatment of uncertainty. | Examine unsupported coverage statements and review ambiguous findings. |
| Incident and Escalation Procedure | Severity, response owners, deadlines, containment, remediation, and closure criteria. | Escalate an unsupported promise and determine whether the customer has acted. |
| Evidence File | Relevant traces, source versions, evaluation results, approvals, review decisions, interventions, and known outcomes. | Preserve the statement, policy, approval state, correction, and customer response. |
Each artifact needs an owner, version, and update trigger.
The Evidence File separates what was directly observed from what was inferred or established through review. Its access and retention requirements must reflect the sensitivity of the underlying information.
A complete record is not an instruction to retain every conversation indefinitely. It is a requirement to preserve the evidence necessary for the stated purpose under appropriate access, privacy, and retention rules.
How an obligation becomes a measurable check
An obligation becomes evaluable when its applicability, interpretation, required facts, and decision logic are explicit.
For the same customer support agent example, a check might ask whether a positive coverage statement was supported by the active policy and known customer facts, or by a valid exception approval.
The evaluation needs a reproducible sequence:
- Identify applicability. Which entity, customer, activity, and policy are involved?
- Extract relevant facts. What was requested, represented, approved, and executed?
- Apply the encoded requirement. Does the evidence satisfy the conditions of the check?
- Preserve uncertainty. Is information missing, conflicting, or unreliable?
- Record the result. Retain the source, versions, evidence references, evaluation method, and review status.
Language models can extract facts from conversations. Deterministic logic can evaluate explicit conditions. Formal methods can verify properties of that logic.
Each contributes a different kind of assurance. Mechanically checking a rule does not establish that the legal interpretation is correct or that extracted facts are complete.
Results must therefore distinguish satisfied, violated, indeterminate, and not applicable relative to the encoded check. A finding against a check is not automatically a finding of legal liability.
The assessment also needs to distinguish failures of the agent from failures of the measurement system. Missing telemetry, extraction errors, and outdated policies can all change a result.
A trace becomes useful risk evidence when its connection to a specific obligation is inspectable.
How Control, Detect, and Protect work together
CRMS organizes runtime risk management into three coordinated functions.
| Function | Responsibility | Example |
|---|---|---|
| Control | Establish the preventive requirements and operating configuration. | Define coverage sources, approval rules, and authorization limits. |
| Detect | Evaluate behavior and identify departures from applicable requirements. | Identify a coverage promise unsupported by the active policy. |
| Protect | Intervene during the workflow when a defined trigger is met. | Hold the response, require approval, or block an unauthorized action. |
The boundary between them is operational. Control establishes how the system should operate. Detect determines what the evidence indicates. Protect acts on that finding within the workflow.
Detection after an event is different from preventing it. A blocked action is also not proof that a loss would otherwise have occurred.
Implementations must measure missed findings, false alarms, intervention latency, availability, overrides, and escalation outcomes.
The functions also create feedback loops. Repeated interventions may justify a stronger preventive restriction. An overly broad restriction may be replaced by narrower authority with targeted runtime review, where evidence supports the change.
Those changes need accountable owners, approval, version history, and subsequent evaluation.
Why the governance record keeps changing
Three clocks change an agent’s risk.
The world’s clock changes obligations: laws, legal interpretations, contracts, and business policies.
The agent’s clock changes behavior: models, prompts, tools, permissions, and retrieval sources.
The traffic’s clock changes exposure: users, requests, languages, jurisdictions, and patterns of reliance.
A review conducted under one combination cannot automatically describe another.
CRMS ties findings and review records to the relevant versions and observation period. Material changes trigger reassessment; overdue reviews remain visible.
For the customer support agent, a policy revision can make a previously correct response wrong. A new tool can expand what the agent can execute. A new customer population can introduce requirements absent from earlier traffic.
The governance record must preserve those changes and their effects on prior conclusions.
What can a million sessions tell us?
A million sessions can reveal substantial information about observed behavior. The value depends on what those sessions contain, what the detector can recognize, and whether the operating conditions remain comparable.
Three problems require different treatment.
Recurring failures may appear frequently enough to estimate their rate within relevant production activity.
Boundary failures emerge from combinations of legitimate requests, incomplete facts, conflicting instructions, or unusual circumstances. They may be poorly represented in ordinary traffic.
Catastrophic outcomes concern severity and concentration: how far a failure can propagate and how much loss it can create.
These are not fixed slices of a risk distribution. Boundary failures are not necessarily rare. Catastrophic describes an outcome’s scale, rather than the intent of the person who triggered it.
Observed and assessed evidence answer different questions
Observed evidence comes from production activity. It records the population examined, eligible opportunities, detection method, and findings. Unclear cases remain unknown rather than being forced into confident classifications.
Assessed evidence comes from constructed scenarios. It tests boundary conditions, adversarial behavior, and situations that ordinary traffic has not supplied.
CRMS keeps their results separate.
An agent failing 20% of a deliberately difficult test suite has failed 20% of that test distribution. Estimating production frequency requires evidence about how often those conditions actually occur.
Assessments can expose a weakness. Production observations help characterize its occurrence. Neither substitutes for the other.
Rare failures can remain invisible
Consider a hypothetical failure probability of one in a million sessions.
Assuming independent sessions, a constant probability, and perfect detection:
P(no failures) = (1 − 10−6)1,000,000 ≈ 36.8%
An agent with that failure probability would produce a clean million-session sample more than one-third of the time.
For a hypothetical one-in-ten-million failure, the probability of observing none in a million sessions is approximately 90.5%.
Real deployments add uncertainty: sessions can be correlated, detectors can miss events, and system changes can invalidate the assumption of a stable probability.
The denominator must also match the opportunity for failure. A million conversations containing only a few hundred repair authorizations provide a much smaller sample for estimating unauthorized-repair risk.
A million sessions is a sample size. Its meaning depends on the exposure and the measurement process.
Catastrophic risk needs a separate analysis
A severe loss can begin with an ordinary request.
A shared policy error can generate unsupported promises across thousands of conversations. A faulty permission configuration can affect multiple deployments. A retrieval change can expose the same sensitive information repeatedly.
The relevant questions include:
- How many interactions or customers share the failure condition?
- How quickly can it be detected and contained?
- Which tools, policies, or data sources create common dependencies?
- What loss severity is plausible under defined stress scenarios?
Average per-session rates do not answer those questions. CRMS’s evidence structure supports analysis of propagation, common causes, intervention delays, and concentration.
Critical Agent Vulnerabilities: describing failures in the context of the job
A technical label such as “hallucination” identifies a broad behavior. Reviewers also need a precise description of the operational failure.
CRMS uses Critical Agent Vulnerabilities, or CAVs, to describe material failure modes in the context of an agent’s role.
A CAV record identifies:
- The role and operating conditions involved.
- The relevant obligation or authority boundary.
- The triggering conditions and failure behavior.
- The evidence required to reproduce or recognize it.
- The affected parties and potential consequence pathways.
- Detection, prevention, and intervention options.
- Validation status, known limitations, and applicable versions.
For the customer support agent, a CAV could describe an unsupported commitment to cover an excluded repair without required exception approval.
That description is more actionable than “incorrect answer.” It identifies the source requirement, authority boundary, behavior, and evidence needed for review.
CAVs can map to existing technical taxonomies and governance requirements. Their criticality depends on severity, reach, detectability, and the effectiveness of safeguards—not simply whether the behavior is novel.
A reusable CAV record supports consistent testing and incident comparison. It does not establish that every occurrence creates liability or the same amount of loss.
How behavioral evidence supports financial risk assessment
Behavioral evidence becomes financially useful when it connects relevant exposure opportunities, failure frequency, and consequences.
An illustrative decomposition is:
E[LT] = ∑i Ni(T) × pi × qi × μi
Here, Ni(T) represents eligible exposure opportunities over a defined period; pi is the probability of the specified failure under the controls in place; qi is the probability that the failure produces a financial consequence; and μi is the expected size of that consequence.
This decomposition explains the information needed; it is not a calibrated insurance rating formula. Event definitions and loss attribution must prevent double-counting.
Production telemetry can inform exposure and observed failure frequency. Reviewed incidents can establish what happened after a finding. Claims experience and relevant loss analogues help connect conduct to financial consequences and severity.
For the customer support agent, an unsupported statement might be corrected before reliance, lead to reimbursement, or become part of a wider dispute. The same behavioral label can lead to different outcomes.
Measurement quality also matters. False positives can inflate apparent exposure. False negatives can hide it. A change in detector sensitivity can look like a change in agent risk.
Rates therefore need consistent definitions, relevant denominators, version history, and uncertainty estimates.
Expected loss is only part of insurance pricing. Coverage depends on policy terms, limits, retentions, and exclusions. Pricing also reflects uncertainty, expenses, and capital requirements.
The detector’s failure rate is an input to analysis. It is not a premium with a dollar sign attached.
Where Ollive fits
Ollive is building the connection between agent behavior, applicable obligations, and financial consequences.
Ollive’s runtime risk layer built using CRMS examines agent logs and traces for behavior that may create legal, regulatory, or contractual exposure. CRMS structures the surrounding evidence: the assigned role, the obligation being evaluated, the finding, the intervention, and the known outcome.
This structure serves several decisions.
Engineering teams need to understand and correct the failure. Business owners need to decide what authority to delegate. Legal teams need facts tied to relevant obligations. Insurance underwriters need evidence about exposure, safeguards, and potential losses.
Those teams should not have to reconstruct different versions of the same incident from disconnected records. CRMS provides a common basis for that work while preserving the boundaries between technical evaluation, legal judgment, and insurance decisions.
The agent workforce will be defined by how much responsibility businesses delegate. Governing that delegation requires a record of what agents are authorized to do, whether they stay within those boundaries, and what happens when they do not.
An agent can take on the work. The business still needs a way to measure and manage the risk.
Implement CRMS at your company
See how CRMS connects your AI agents’ responsibilities to measurable obligations, runtime evidence, and potential financial exposure. Bring a workflow and explore how Ollive can help your team identify gaps, investigate findings, and prioritize action.
Book a demo with the Ollive team
Frequently Asked Questions
Where should we start with CRMS?
Start with one agent performing a clearly defined job, such as resolving customer support requests. Document what it may do, which decisions require approval, and when it must escalate. Then identify the obligations that matter most for that workflow and the evidence needed to evaluate them.
What do we need to bring to an implementation discussion?
Bring a description of the workflow, relevant policies or contractual commitments, the agent’s permissions, and representative interaction traces. Include any existing approval and escalation procedures. You do not need a complete governance program to begin; identifying missing information is part of defining the implementation.
How do we decide which obligations to measure first?
Prioritize obligations where a failure could have a meaningful consequence and where the behavior can be observed. For a customer support agent, these might include refund limits, restrictions on customer information, or promises that require approval. For each obligation, define the required evidence, the check, and who reviews an uncertain result.
What will CRMS help our team understand?
CRMS helps your team connect what an agent was authorized to do with what it actually did. Its records support questions such as: Which obligation applied? What evidence supports the finding? Did anyone intervene? What happened afterward? That context helps teams prioritize remediation and distinguish a behavioral failure from a potential financial consequence.
How does CRMS fit into our existing tools and processes?
Use CRMS to structure evidence from your existing logs, evaluations, policies, and incident processes. The five artifacts connect the agent’s role and authority, applicable obligations, monitoring procedures, escalation responsibilities, and supporting evidence. Implementation should establish how those records stay connected and who maintains them.
How do we know whether the implementation is working?
Agree on success criteria before starting. Assess whether important obligations have usable checks, findings can be traced to supporting evidence, uncertain cases reach the right reviewer, and corrective actions are completed. Review missed failures and false alarms alongside detected findings. Revisit the assessment when policies, permissions, models, or traffic change.