NAIC AI Model Bulletin vs OWASP Agentic Top 10: Mapping Agent Risks

What each framework is designed to do

The NAIC Model Bulletin was adopted on December 4, 2023. It reminds insurers that decisions or actions affecting consumers, whether made or supported by AI systems, must comply with all applicable insurance laws and regulations. It also sets out a Department's expectations for how insurers govern the development, acquisition and use of certain AI technologies. NAIC materials summarize its coverage as governance, testing, documentation and third-party oversight. The Bulletin is a model, so each state issues its own version. Confirm your state's text and effective date before building evidence around it, as of October 2026.

The OWASP Top 10 for Agentic Applications (2026) was released by the OWASP GenAI Security Project in December 2025. It is a peer-reviewed framework identifying the most critical security risks facing autonomous and agentic AI systems, aimed at builders, defenders and decision-makers. OWASP says agentic systems introduce new failure modes, including tool misuse, prompt injection and data leakage, and each entry carries threat mappings and mitigation guidance.

One document tells a regulator what a carrier's program must achieve. The other tells a security team how agents get attacked or misused. A CISO needs both, and needs a way to translate between them.

Comparing the frameworks on five dimensions

The differences below explain why no direct crosswalk exists and why the mapping that follows is interpretive. NAIC materials do not address agentic systems by name, although they describe an agent as something that may use tools, look up information, update systems, route work or start the next step in a workflow.

• Purpose: NAIC Bulletin: communicates regulator expectations for insurer AI governance. OWASP: identifies and ranks security risks specific to agentic applications.
• Audience: NAIC Bulletin: insurers, and the Departments that examine them. OWASP: builders, defenders and decision-makers.
• Scope: NAIC Bulletin: AI systems used by insurers, with consumer impact and compliance with insurance law at the center. OWASP: autonomous and agentic systems, including tool use, MCP and agent-to-agent ecosystems.
• Control specificity: NAIC Bulletin: outcomes such as a risk-commensurate program and third-party oversight. OWASP: vulnerability descriptions with mitigation guidance.
• Evidence expectations: NAIC Bulletin: documentation the Department may request during an investigation or examination. OWASP: no examination regime; evidence is a practitioner concern.

Crosswalk: agent risks mapped to Bulletin expectations

The rows below cover risk themes OWASP names or describes in its agentic guidance. The Bulletin column shows the expectation each risk touches, which is an analytical judgment rather than a section-level citation. The final column separates what can be enforced in the execution path from what depends on design or organizational measures.

• Tool misuse: Touches risk management, testing and documentation. Largely runtime-enforceable: each tool call can be allowed, blocked, rate limited or escalated against policy. Tool design and scoping remain a design decision.
• Prompt injection (direct and indirect): Touches risk management and testing. Partly runtime-enforceable: instructions arriving from websites, documents or emails can be inspected and acted on at the interaction. Residual exposure needs architectural limits on what the agent can do.
• Data leakage: Touches the duty to comply with insurance law and risk management. Runtime-enforceable where data leaves through prompts, outputs or tool-call payloads: redact or block.
• Excessive agency and privilege: Touches governance and the degree of human involvement. Mixed: permission scope is a design decision, while approval escalation for consequential actions is enforceable at runtime.
• Agentic supply chain (ASI04): Touches third-party oversight. Mostly design and organizational: vetting, provenance and review of MCP servers and agent components. Runtime policy can only limit which tools an agent may call.
• Unexpected code execution (ASI05): Touches risk management and testing. Mixed: calls that trigger execution can be blocked or escalated, but sandboxing and isolation are design measures.

Where the Bulletin sets outcomes but not controls

The Bulletin does not mention tool misuse, excessive agency or injected instructions. That silence is by design for a model bulletin focused on governance outcomes. NAIC's July 2023 exposure draft tied program rigor to the nature of the decisions, the potential consumer harm from errors or unfair bias, the extent to which humans are in the loop, and reliance on third-party data, models and AI systems. For agents, that means the control level for each use case comes from your own risk assessment, informed by a threat taxonomy such as OWASP's. The Bulletin will not tell you whether a claims agent may issue payments without approval. Your risk assessment has to.

This also defines the limits of runtime enforcement. Policy applied to individual interactions and tool calls can act on what is visible at that point: the content, the tool, the parameters, the destination and the rate. It cannot decide whether an MCP server was trustworthy when adopted, whether an agent's permissions were sensibly scoped, or whether a multi-step workflow as a whole produces a fair outcome. Those need vendor review, architecture decisions and workflow-level governance, and they are where the Bulletin's third-party oversight and governance expectations carry the most weight.

The practical split is straightforward. Use runtime enforcement for risks visible at the call level. Use design and organizational controls for risks that sit upstream of the call or span the workflow. Record the reasoning for each agent use case so the split is documented.

Evidence a regulator or auditor can examine

The Bulletin advises insurers that the Department may request documentation during an investigation or examination. Policy documents show intent. They rarely show what an agent actually did at a given moment, so interaction-level records matter for the runtime-enforceable rows above.

Candidate artifacts, which should be validated against your state's examination expectations, include a per-call decision record showing which policy version applied and whether the call was allowed, redacted, blocked or rate limited; approval records showing when a human approved or rejected an escalated action; and a change history of the policies themselves. For the design and organizational rows, evidence looks different: third-party assessments, tool and server approval records, and documented risk assessments explaining the chosen level of human oversight.

Carriers that also track NYDFS Circular Letter 7 and Colorado SB 24-205 should test the same artifacts against those regimes rather than assume one set of records satisfies all of them. A common evidence model across regimes reduces rework, but each regime's requirements need to be checked on their own terms.

How runtime enforcement produces evidence mapped to NAIC

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Each individual interaction or tool call can be allowed, redacted, blocked, rate limited or escalated for human approval. Enforcement is applied at runtime, not reviewed after the fact, and the same enforcement generates continuous audit-ready evidence mapped to NAIC, NYDFS, HIPAA, the EU AI Act and NIST.

This covers the call-level rows in the crosswalk. It does not replace third-party vetting of agent components, permission design or workflow-level governance. Trussed has run continuously in production at a regulated enterprise for more than 18 months, and generates over 30 GB of audit evidence per day. It can be deployed self-managed in the customer's cloud, with configurable retention and data residency.