AI Liability Insurance for Superintelligent Agents: Insurer Questions

AI liability insurance for agents is coverage that may respond to financial loss or third-party claims caused by an AI agent's errors, such as a wrong message sent to a customer or an action taken without proper authority. Insurers generally decide whether and on what terms to cover those errors by examining what the agent is allowed to do, what it records, and who approves its consequential actions. Before asking a broker for a quote, a business owner should be able to answer those three questions in writing.

Key takeaways

• Insurers start with the agent's boundaries: which systems it can read or change, and what it can commit the company to.
• A log is only useful if it lets someone reconstruct a decision, including the inputs, the tool calls and the approval state at that moment.
• Approval rules should be tied to specific action types and enforced by the system, not left to memory or habit.
• Coverage terms depend on the insurer, the policy and the jurisdiction, so treat these questions as preparation rather than a published standard.
• Controls you can demonstrate with records are worth more in a broker conversation than controls described only in a policy document.

Why insurers ask about controls before discussing cover

Underwriting is a judgment about how a loss could happen and how large it could become. For an AI agent, that judgment depends on the authority the agent holds, the systems it can change, and how quickly a bad action would be noticed. An agent that drafts replies for a staff member to send carries a different exposure than an agent that issues refunds or edits a supplier order. This is why the first questions tend to be about boundaries and evidence, not about limits or premiums.

Practices differ by insurer, jurisdiction and policy type, and there is no single questionnaire for AI agents that every carrier uses. The NIST AI Risk Management Framework is a useful shared vocabulary for naming risks, owners and controls before any review starts. Use the questions below as a way to prepare for a serious conversation, and ask your broker which questions a particular carrier is currently asking.

What is the agent allowed to do?

Scope is the first thing to define in writing. Insurers want to know what the agent can reach, what it can change, and what it can promise or spend on the company's behalf. Expect questions like these:

• Which systems can the agent read, and which can it write to?
• Which actions can it take without a person reviewing them first?
• What limits apply to money, commitments, deletions and messages sent to customers?
• Which credentials does it use, and are they scoped to the agent's role rather than to a person's account?
• How quickly can its access be removed, and who has the authority to remove it?

Each answer should match the configuration of the system, not only a policy document. If the written policy says the agent cannot issue refunds but its credentials allow refunds, that gap is the first thing a reviewer will find. A tiered approach helps: the agent starts with read access and narrow write permissions, and each expansion is a recorded decision with a reason. The article on growing trust tiers for superintelligent agents describes how to structure those steps.

Can you reconstruct what the agent did?

When something goes wrong, the first task is reconstruction. Who asked for the action, what information the agent used, which tools it called and with which parameters, what it returned, and whether a person approved it. If those facts cannot be assembled quickly, the company faces a dispute it cannot settle from evidence, which weakens its position with a claims handler and with the customer.

Good agent logs follow the same logic as application observability. Traces connect a request to each step, and timestamps place each step in order. The OpenTelemetry observability primer explains these building blocks in general terms, and they apply directly to an agent that calls several systems within one task. For each consequential action, the record should contain:

• the request or trigger that started the task, with the time it arrived
• the version of the instructions and the context the agent used
• each tool call, its parameters and its result
• the output sent to a person or to another system
• the approval record, including who approved, what exactly they approved, and when that approval expires

Logs also contain personal and business data, so retention and access need rules of their own. Keep enough to investigate a claim or an error, and limit who can read the records.

[figure]

Who approved the action, and when?

Insurers often look for the gap between a written approval policy and what the system actually enforces. A policy that says a manager must approve refunds above a set limit is only evidence if the agent cannot send that refund without an approval record existing. Approval boundaries should be defined by action type, not by vague categories such as important tasks. The guide on where an AI agent should stop and ask covers how to place those stopping points in a workflow.

Three properties matter. The system must record the approval, the approval must cover a specific action rather than a general instruction, and the approval should expire or need renewal when conditions change. An agent that asks once for permission to make an unlimited batch of changes carries a different risk than one that asks for each change or for a bounded batch.

Illustrative scenario: a regional maintenance company lets an agent draft service quotes for its office team. The agent may calculate a quote and save it as a draft without review. Sending a quote to a customer requires a staff member to approve that exact quote in the system, and quotes above a limit set in the approval policy also need a supervisor's approval. When a customer disputes a price weeks later, the company can show the policy, the approval record for that quote and the calculation inputs the agent used.

A checklist before you ask a broker for a quote

Before the broker conversation, assemble a short evidence file. It does not need to be long, but every item should point to something a reviewer can verify.

• Write a one-page description of the agent's role, the systems it touches and the named person accountable for it.
• List every action type the agent can take, marked as allowed alone, allowed after approval, or not allowed at all.
• Confirm that each credential is scoped to the agent role, can be revoked in one step, and is itself logged.
• Confirm that every tool call and output is recorded with a timestamp and a link to the request that triggered it.
• Document how an approval is requested, who can grant it, what it covers and how long it remains valid.
• Run the agent against realistic failure cases, such as an ambiguous instruction or a customer asking for something outside policy, and keep the results.
• Name the person responsible for incident response and state how affected customers would be notified.
• Add the agent to your risk register with an owner and a scheduled review date.

How Be Human's managed approach handles this

Be Human designs and operates the layer that gives an agent its identity, memory, channels, tools, permissions and operating context, so these questions are answered during the first engagement rather than reconstructed later. The first engagement defines one role, the memory and tools it needs, its approval boundaries and an observable success criterion. Managed operations keep those controls in use through monitoring, recurring evaluations, permission review, incident response and controlled changes, and records of tool calls and approvals are part of the design. Be Human does not sell insurance or decide coverage, but it can provide the documentation a broker or insurer asks for, which is often the most useful help at that stage.

What should a business owner do next?

Start with one agent role rather than a general plan for all AI. Write its scope, define its approval points, confirm that its records can answer a dispute, and only then bring the file to a broker or to your legal advisor. The order matters because coverage conversations go better when the company can show what the agent does and what stops it from doing more. If you are not yet sure which task should be the first one handed to an agent, the free Be Human AI diagnostic can help you find it.

Frequently asked questions

Does general business insurance cover mistakes made by an AI agent? It may cover some of them, but the answer depends on the policy wording, its exclusions for technology or professional services, and the insurer. Ask your broker to review how the policy treats automated actions and whether any endorsement applies. Do not assume coverage until that review is in writing.

What do insurers usually want to see from an agent's logs? They usually want to know whether the company can reconstruct a specific decision: the request, the information used, the tools called, the output and the approval state. Logs that show only the final message are rarely enough to settle a dispute. Keep records detailed enough to investigate and controlled enough to protect personal data.

Is a human approval step enough to make an agent insurable? A human approval step helps only when the approval is recorded by the system, scoped to a specific action, and enforced so the agent cannot act without it. A verbal rule that staff are expected to follow is hard to demonstrate after an incident. Insurability also depends on the agent's scope, logs and incident process, not on approvals alone.

Should we buy AI liability cover before launching an agent? Define the agent's scope, controls and evidence first, because those decide what a broker can say about the risk. Then ask a broker and legal counsel about timing, coverage terms and how the policy would apply to your specific workflow. Insurance is one part of managing the risk, not a replacement for controls.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.