How Ollive’s ARMS protocol connects an AI agent’s role, obligations and behavior to measurable financial exposure.
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 gap includes practical requirements: 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. But insurance requires a description of the work, the obligations attached to it and the circumstances in which something going wrong becomes a financial loss. Delegating work to an agent creates a new measurement problem inside that familiar insurance problem.
Consider a hypothetical customer-support agent. It retrieves a warranty policy, tells a customer that an expensive repair is covered and closes the conversation. The response is fluent. The tools executed successfully. The customer received an answer.
But the policy does not cover that repair, and the customer authorizes the work because of what the agent said.
The workflow succeeded technically while potentially creating a financial obligation. A dashboard tracking latency, task completion and customer satisfaction could miss the most consequential part of the interaction.
This is the problem Ollive’s Agent Risk Management Specification (ARMS) is designed to address: how to define the boundaries of an agent’s role, measure its behavior against those boundaries and build evidence that can support the pricing of its financial risk.
What does financial-liability risk mean for an AI agent?
For this purpose, AI agent risk means the possibility that an agent’s outputs, actions or omissions create financial exposure for the organizations building or deploying it.
That definition is deliberately narrower than “anything undesirable an AI system might do.” It requires a connection between behavior and consequence: a misleading statement that someone relies on, an unauthorized commitment, a missed legal obligation or a disclosure that creates a claim.
The analytical chain is:
Applicable obligation → agent behavior → affected party → potential claim or enforcement action → financial consequence.
Not every incorrect answer completes that chain. A detected failure is not automatically an established legal violation, and a violation is not automatically a claim or an insured loss. Those distinctions are essential to credible measurement.
The relevant unit is also more specific than a model. Two agents using the same foundation model can have very different exposure. One answers internal documentation questions. Another communicates with patients, makes representations about benefits and changes account records.
Their risk depends on the work they perform, the authority they hold, the people who rely on them and the obligations governing the interaction.
The model is a component. The role is the context in which liability becomes measurable.
Where can AI agent liability emerge?
Ollive organizes financial-liability analysis around three overlapping surfaces: regulatory and legislative obligations, civil liability, and contractual and product boundaries.
These are sources of obligations and consequences, not competing technical failure categories. A hallucination, retrieval error or malicious instruction can cross any of them. The purpose is to connect a technical event to the responsibility it creates.
1. Regulatory and legislative risk: which rules govern the work?
This surface begins with the laws and regulations applicable to the organization and the activity being performed. The relevant questions include jurisdiction, sector, the parties involved, the type of communication or decision, and any applicable exceptions.
The rule does not need to mention AI to matter to an AI-enabled workflow.
For example, Regulation F restricts when a covered debt collector may contact a consumer. Subject to the regulation’s exceptions, communications cannot occur at unusual or known inconvenient times. In the absence of contrary information, times before 8 a.m. and after 9 p.m. in the consumer’s location are treated as inconvenient. A consumer’s stated preferences can impose additional restrictions.
A useful monitor therefore needs more than the sentence, “Do not call too early.” It needs the facts necessary to apply the rule: whether the activity is covered, the consumer’s location, the time of the attempted communication, relevant preferences and any valid exception.
This is the difference between a broad compliance instruction and an evaluable requirement.
Within ARMS, the obligation should retain its source, interpretation, applicability and effective date. Its associated check should identify the evidence required to reach a conclusion. Missing evidence should remain visible rather than silently becoming a finding of compliance.
Ollive does not provide legal advice or legal opinions. ARMS flags potentially relevant conduct and its supporting evidence for the organization's in-house legal and compliance teams to assess. Those teams determine whether a rule applies and what response is required.
Financial exposure can then be analyzed through the relevant enforcement pathway. An investigation, required remediation and a monetary penalty are different outcomes. They should not be collapsed into a single “regulatory risk” score.
2. Civil and litigation risk: what harm can create a claim?
Civil liability requires looking beyond a checklist of regulatory provisions. The question is whether the agent’s conduct could support a claim by someone who was harmed, including through negligence or a misleading representation.
Historical litigation helps identify the factual patterns that matter: what was represented, whether reliance was reasonable, what duty applied and how the conduct connected to the alleged loss. Relevant history may involve humans performing the same function; it does not have to involve an AI system.
The Air Canada chatbot dispute illustrates the mechanism. In its analysis of Moffatt v. Air Canada, Dentons describes how the British Columbia Civil Resolution Tribunal found negligent misrepresentation after a customer relied on incorrect chatbot information about bereavement fares. The tribunal awarded C$650.88 in damages, plus interest and fees. The loss arose from an ordinary customer interaction, not a security breach.
For an agent-risk system, the engineering implication is to preserve more than an “incorrect answer” label. The relevant record includes the representation, the policy or source information behind it, the context in which it was delivered and evidence of what happened afterward.
Litigation history must also be interpreted carefully. An allegation is not a finding. A settlement is not automatically a rule of law. A decision in one jurisdiction is not a universal liability standard.
ARMS’ proposed approach is to make those distinctions part of the obligation record, so that a monitor can identify a potentially relevant pattern without pretending to adjudicate the resulting claim.
3. Contractual and product risk: what did the builder promise, and what is the agent allowed to do?
This surface captures commitments specific to the relationship between an AI builder and its customer, alongside the boundaries of the product itself.
A contract may define service levels, permitted uses, escalation requirements, warranties, indemnities, remedies and liability limitations. Product specifications may impose additional operational restrictions, even where those restrictions are not themselves contractual promises.
Consider a hypothetical support agent authorized to issue refunds up to $100, but required to escalate larger requests. There are several distinct ways it could cross that boundary. It could execute a $500 refund, promise a $500 refund without executing it, or fail to escalate a request that requires approval.
The evidence and consequences differ in each case.
This is why technical permission cannot be treated as the whole authority model. An API credential may permit an account change that the customer contract or the agent’s assigned role does not authorize. Conversely, an agent can create exposure through language without making a tool call at all.
Product scope matters for the same reason. A scheduling agent that begins offering treatment recommendations has entered a different risk context, even if its answer sounds useful.
The measurement task is to connect what the agent was permitted to do, what it promised, what it actually did and which consequence could follow. A scope violation should not automatically be counted as a contractual payout.
These surfaces also overlap. One incident may create a contractual dispute, a consumer claim and regulatory scrutiny. The system must retain those relationships without counting the same underlying loss three times.
What is the ARMS protocol?
ARMS sets out Ollive’s proposed protocol for continuously governing an AI agent in a specific operational role. It defines governance artifacts and procedures intended to be usable across vendors, deployers and auditors.
Its purpose is to create a shared record of the agent’s authority, obligations, performance and response to failure. The current draft specifies a proposed protocol; it is not a validated industry standard or a proven actuarial model. Its initial scope is single-agent governance; multi-agent governance and a public vulnerability registry remain areas of further development.
The protocol is organized around five artifacts:
| ARMS artifact | What it establishes |
| Role Card | The agent’s duties, scope of authority, forbidden actions, autonomy level and escalation responsibilities. |
| Obligation Map | The sources of applicable requirements, their versions and effective dates, and their connections to rules, metrics and evidence. |
| Performance Review Protocol | How interactions are sampled, classified and reviewed, and when recurring findings should become new controls. |
| Incident & Escalation Policy | How failures are assigned severity, who must respond, applicable deadlines and how remediation feeds back into governance. |
| Compliance File | The assembled evidence, relevant framework mappings, review records and dated attestation associated with the agent. |
The employment analogy is useful because an operational role needs more than a test score. It needs defined authority, supervision, escalation and a record of performance.
But the artifacts serve an audit purpose. Their value is in making those responsibilities inspectable, rather than simply giving an agent a human-sounding job description.
How does an obligation become a measurable check?
An obligation becomes useful for runtime measurement when its interpretation, required facts and evaluation logic are explicit.
Ollive has described this separation in its technical work on compliance directives. The runtime language model extracts relevant facts from conversations and system activity. A directive evaluates those facts against an encoded interpretation. Lean 4 is used to make the directive logic mechanically checkable. The guarantee is conditional: the conclusion follows from the facts and interpretation supplied, not that either is automatically complete or legally correct.
For the hypothetical refund agent, a practical check could connect the requested amount to the active authority limit, approval state and action taken. The supporting record would identify which policy and agent versions applied, what the customer was told, whether the refund executed and whether a human approved an exception.
Some checks can be deterministic. Others require interpretation of unstructured language. Some cannot reach a definite answer without additional evidence.
A defensible system preserves those differences. An indeterminate result is not the same as a pass, and a natural-language explanation is not a substitute for the underlying evidence.
This is how a production trace becomes more useful than an engineering log: it is connected to a specific obligation and a potential consequence.
How do Control, Detect and Protect work together?
ARMS organizes governance into three planes with different responsibilities.
| Plane | Purpose | Example |
| Control | Define preventive requirements at the organization, infrastructure and agent levels. | Establish the refund authority limit and required approval path. |
| Detect | Measure behavior against obligations and identify relevant failures. | Identify a promise or action that exceeded the agent’s authority. |
| Protect | Intervene in line when behavior crosses a defined boundary. | Flag or block an unauthorized action before execution. |
The distinction matters for measurement. Detecting an unauthorized action after it occurred is not equivalent to preventing it. Blocking an action is not proof that a financial loss would otherwise have happened.
An implementation also needs to measure its own controls: missed violations, false alarms, intervention latency, availability and the outcome of escalations.
The draft describes two feedback loops. Recurring interventions can be codified upstream into preventive controls. Conversely, an overly restrictive control can be relaxed downstream into more targeted runtime handling, where the evidence supports that change.
For example, repeated attempts to exceed a refund ceiling may justify an infrastructure restriction. A blanket prohibition on all refunds might later be replaced by limited authority with explicit conditions.
These are governed changes themselves. They need owners, approval, version history and evidence that the new arrangement is appropriate.
Why must the governance record keep changing?
ARMS describes three clocks that can change an agent’s risk.
The world’s clock changes the applicable obligations: regulations, legal interpretations and contract terms. The agent’s clock changes the system: models, prompts, tools, permissions and retrieval sources. The traffic’s clock changes the situations the agent encounters: users, requests, languages and patterns of reliance.
A measurement taken under one combination cannot automatically describe another.
The proposed Employment File assembles the governance record for an agent. Its certificate is a dated attestation tied to a specific version set and review process. Relevant changes or a lapsed review cadence make that attestation stale. It is not a permanent declaration that the agent is safe.
This approach is intended to complement existing frameworks. NIST’s AI Risk Management Framework already calls for continuous, lifecycle-wide risk management. ARMS’ proposed contribution is more specific: artifacts and procedures connecting that objective to one agent, its role and its financial exposure.
What can a million sessions tell us about AI agent risk?
A million sessions can provide valuable evidence about observed behavior. They cannot establish that every material failure mode has been discovered.
The distinction is easiest to see by separating three measurement problems.
Recurring failures may appear often enough in ordinary traffic to estimate their frequency. Boundary failures may require unusual combinations of legitimate requests, incomplete information or conflicting instructions. Catastrophic outcomes require a separate analysis of severity and concentration, including failures that can affect many interactions or customers together.
These are not automatically fixed percentages of the risk distribution. Boundary behavior is not necessarily rare, and catastrophic describes the size of a loss, not the intent of the user who triggered it.
Why does ARMS separate observed and assessed behavior?
The protocol defines two detection modes.
Observed measurement examines real traffic. It distinguishes intended use, genuine users at the boundary of intended behavior and adversarial activity. It also preserves an unknown classification when the system abstains, rather than forcing every interaction into a confident category.
Assessed measurement examines deliberately constructed cases run against the agent. These can explore difficult boundary conditions, security failures and scenarios that ordinary traffic has not supplied. The draft requires assessed results to be reported separately from observed results.
That separation is essential. A test suite containing a high concentration of difficult scenarios can reveal weaknesses, but its failure rate is not automatically the agent’s production failure rate.
A result such as “the agent failed 20% of these stress tests” describes performance on that test distribution. Estimating real-world frequency also requires evidence about how often those conditions occur.
Why can rare failures remain invisible?
Consider an explicitly hypothetical failure with a constant probability of one in a million sessions.
Assuming independent sessions and perfect detection, the probability of observing no failures across one million sessions is:
P(no failures) = (1 − 10−6)1,000,000 ≈ 36.8%
An agent with that failure probability would therefore produce a completely clean million-session sample more than one-third of the time. For a hypothetical one-in-ten-million failure, the chance of seeing none in a million sessions is approximately 90.5%.
Real deployments add further uncertainty. Sessions may be correlated, detectors may miss events and model or traffic changes may invalidate the assumption of a stable probability.
The denominator also has to match the opportunity for failure. A million conversations containing only a few hundred refund authorizations provide a much smaller sample for estimating unauthorized-refund risk.
A million sessions is a sample size, not a guarantee of coverage.
Why must catastrophic risk be modeled separately?
A severe loss need not begin with an exotic prompt. A shared policy error could be repeated across thousands of ordinary interactions. A retrieval configuration change could expose the same class of information across many customers.
In those scenarios, the important questions include how broadly a failure can propagate, how quickly it can be detected and contained, and which deployments share the same dependency.
That analysis cannot be replaced by an average per-session failure rate. It requires stress scenarios and explicit assumptions about concentration, common causes and loss severity.
The objective is to understand the limits of the evidence, rather than to declare that enough traffic has made the remaining risk disappear.
How can behavioral evidence support risk pricing?
Behavioral measurement supports pricing by connecting the frequency of relevant failures to the probability and severity of financial 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 is an explanatory model, not a published ARMS rating formula or Ollive’s production rater. Incident definitions must also avoid double-counting losses across the three liability surfaces.
The decomposition makes the evidence requirements clear.
Production telemetry can help estimate exposure and behavioral failure frequency. Reviewed incidents can help establish whether detected events produced harm. Claims experience and relevant loss analogues are needed to calibrate the relationship between conduct, financial consequences and severity.
A detector alone cannot provide all of those inputs.
For example, an unsupported warranty statement might be corrected before the customer acts, lead to a small reimbursement or become part of a wider dispute. Counting the statements is useful. Treating every statement as an identical claim would be misleading.
Measurement quality matters as well. False positives can inflate apparent exposure; false negatives can hide it. Changes in detector sensitivity can create an apparent risk trend even when agent behavior has not changed. Rates therefore need consistent definitions, relevant denominators, version history and uncertainty estimates.
Finally, expected financial loss is not the same as an insurance premium. A policy responds to defined losses under its terms, limits, retentions and exclusions. Pricing also has to account for uncertainty, expenses and the capital required to support severe outcomes.
The policy premium is not the detector’s failure rate with a dollar sign attached.
Where does Ollive fit?
Ollive is building the connection between production behavior and financial responsibility.
The runtime risk layer examines agent logs and traces for behavior that can create legal, regulatory or contractual exposure. ARMS provides the proposed structure around that measurement: the role being governed, the obligations being evaluated, the evidence retained and the procedures for responding when something goes wrong.
The draft also proposes Critical Agent Vulnerabilities, or CAVs: a way to describe material failure modes at the operational-role level. The objective is to make a failure recognizable in terms of the job being performed, alongside mappings to established frameworks. The registry’s governance and validation remain development work, not established public infrastructure.
Our underlying hypothesis is that a substantial share of liability from agents performing human work will arise at the boundary of legitimate use: an ordinary person asks a reasonable question, the agent responds confidently and the organization inherits the consequence. ARMS is designed to generate evidence that can test that hypothesis, rather than assume it is true.
That evidence can support better controls and, over time, more credible underwriting of the risk that remains. It does not make every exposure insurable or every judgment automatic.
The agent workforce will be defined by how much responsibility businesses delegate, not simply by how many agents they deploy. The foundation for that delegation is a record of what each agent is authorized to do, whether it stays within those boundaries and what financial exposure the organization is accepting.
An agent can take on the work. The business still needs a way to measure the responsibility.
Frequently asked questions
What is an AI agent risk-management protocol?
It is a structured set of records and procedures for defining an agent’s authority, mapping its obligations, evaluating its behavior and responding to failures. ARMS focuses on making that governance specific to an operational role and connected to potential financial exposure.
Is ARMS an AI certification or an insurance policy?
No. ARMS specifies a proposed governance protocol. Its certificate records a dated review against a particular version set; it is not a guarantee of safety, a legal determination or an insurance contract. Coverage requires a separate policy and underwriting decision.
How is AI liability monitoring different from standard evaluations?
Evaluations can test correctness, task performance and other requirements. Liability-focused monitoring adds the obligation and consequence: whether behavior exceeded authority, breached a relevant requirement or created a representation someone could rely on. It complements evaluations rather than making them unnecessary.
Does a clean production history prove an agent is low risk?
No. It provides evidence within the scope and quality of the observations. Its significance depends on relevant exposure volume, detector performance, rare-event uncertainty and whether the agent, obligations or traffic have changed.