How the NAIC AI Model Bulletin Applies to AI Agents That Take Actions

What the bulletin says, and where it is silent on agents

The NAIC adopted the Model Bulletin on the Use of Artificial Intelligence Systems by Insurers on December 4, 2023. It is model guidance, not state law, and it is described as principles-based. States issue their own bulletins, and the NAIC adoption map notes that it does not determine whether a state's version contains every element of the model. As of October 2026, the model bulletin remains the NAIC's operative guidance on this subject.

Three expectations matter most for agents. Insurers are expected to develop and maintain a written program for the responsible use of AI. The bulletin encourages verification and testing to identify errors and bias, and the potential for unfair discrimination. And insurers should expect questions about their AI programs in regulatory investigations and market conduct actions, so program documentation should be retained, including documentation on AI systems, data and predictive models developed by third parties.

The text that bears most directly on agents is the reminder that decisions or actions impacting consumers, made or supported by AI systems, must comply with all applicable insurance laws. The earlier exposure draft referred only to decisions; the word actions appears in later versions. That gives a textual basis for agent behavior. But the bulletin does not use the vocabulary of agents, tool calls or autonomous execution. Controls such as allow, redact, block, rate limit and escalate are not drawn from it. They are one way to implement its risk management and internal control expectations, and the written program should say so plainly and record the reasoning.

Which agent actions carry the most exposure

The bulletin's scope spans the insurance life cycle, including marketing, underwriting, rating and pricing, case management, claim administration and payment, and fraud detection. For agents, a practical way to prioritize is to classify each tool by its consumer impact rather than by the model behind it. A read-only lookup of a policy record is a different risk from a tool that updates a claim, requests a payment, changes an underwriting input or sends a message to a policyholder.

Claims handling, underwriting support and customer communications are the areas where a tool call is most likely to affect a consumer. In claims, the concern is an agent that can reach payment or reserve systems, or that exposes claimant data to a tool that does not need it. In underwriting support, the concern is an agent that retrieves or passes along data that feeds a decision the insurer must be able to explain. In customer communications, the concern is content and disclosures sent without review.

The control follows from the classification. Read-only calls to approved systems can be allowed under a defined scope. Calls that carry personal data can be redacted. Calls to unapproved tools or outside an agent's role can be blocked. Bulk or looping access can be rate limited. Actions with direct consumer impact can require human approval. The tradeoff is friction: escalating too much creates approval queues that reviewers stop reading, so thresholds need review as the agents' behavior becomes clear.

Runtime evidence compared with documentation compiled afterward

A policy document shows what an insurer intended. A log review shows what someone could reconstruct. Neither shows that a control operated when the agent acted. When enforcement sits in the execution path, the decision to allow, redact, block, rate limit or escalate is made before the call proceeds, and the record is created by that same decision. Reconstruction after the fact depends on whatever was captured by other systems, and gaps surface at the worst time, during an examination.

A useful per-call record includes the agent identity, the tool and arguments requested, the policy evaluated, the decision, and the outcome. For escalations it also includes who approved and when. These fields are a proposed design, not a bulletin requirement, but they answer the question an examiner is most likely to put: what was this agent permitted to do, and what did it do?

"Permitted" also needs a point-in-time answer. NIST's recent technical guidance on agent identity lists short-lived, dynamic and revocable authorization as a design tenet, along with agent-specific policies and thresholds to manage the scale of interactions. This is not insurance regulation, but it fits the examination need: narrow permissions that expire or can be revoked make it possible to show what an agent could do on a given date.

Retention matters as much as capture. Records that cannot be produced by state, or mapped to the program elements an examiner asks about, add work during an inquiry. Because state bulletins can differ from the model, confirm which version applies in each jurisdiction where the insurer is domiciled or licensed.

Where runtime enforcement fits, and what to put in the program

Update the written AIS program to describe agent-specific controls. State that the bulletin does not specifically address agents, record how the insurer interprets decisions or actions for agent behavior, and define which actions require human approval. Assign accountability for tool permissions and policy changes, and treat third-party agent platforms and tool providers under the same documentation expectations as other third-party AI.

Trussed enforces policy in the execution path on individual interactions and tool calls, with actions to allow, redact, block, rate limit or escalate for human approval. The enforcement generates continuous audit-ready evidence mapped to NAIC and other regimes, and it can be deployed self-managed in the customer cloud with configurable retention and data residency. Its scope is the interaction and the tool call, so it does not replace the program, the inventory or the interpretive work described above.