AI Agent Governance Questions to Ask Vendors at ITC Vegas 2026

Why Vendor Governance Claims Need Technical Scrutiny

Insurance carriers and MGAs walking the floor at ITC Vegas 2026 will hear no shortage of vendors describing their AI agents as governed, secure, and compliant. These are architectural claims, not marketing adjectives, and they need to be tested as such. NIST's AI Risk Management Framework treats third-party and vendor-supplied AI systems as part of an organization's own risk surface, and the NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers makes this explicit for the industry: insurers remain accountable for the compliance of AI systems and predictive models obtained from vendors, including monitoring for unfair discrimination. A governance gap in a vendor's platform becomes the carrier's regulatory exposure, not the vendor's. That shifts the burden of diligence onto the buyer, and it means procurement conversations need to move past feature descriptions into architecture, evidence, and demonstration.

Agent Identity: Who Is Actually Acting?

AI agents are frequently provisioned using the service accounts or API keys already available to a development team, which means the agent inherits whatever broad permissions that account already holds. This is distinct from human identity and requires its own governance model. NIST's Zero Trust Architecture guidance (SP 800-207) establishes continuous verification, least privilege, and assume-breach as principles that apply to machine and non-human identities, a category that now includes AI agents. Ask vendors how agent identities are created, whether they are distinct from administrative service accounts, and how credentials are rotated. A vendor that cannot describe a dedicated non-human identity model is likely relying on static, over-provisioned credentials, which is a meaningful security gap for any agent touching claims, underwriting, or policy servicing data.

Least Privilege: Where Is It Actually Enforced?

OWASP's Top 10 for LLM Applications names "Excessive Agency" as a distinct risk category, describing agents granted more permissions or autonomy than their task requires. The critical diligence question is not whether a vendor claims least-privilege access, but where that access is enforced. Permission scoping instructed through a system prompt is not a security control, since a model's own judgment can be manipulated or can simply err. Meaningful enforcement happens at an API gateway or a dedicated policy decision point that sits outside the model's reasoning process and evaluates each tool call against defined rules before execution. Ask vendors to demonstrate a blocked unauthorized tool call in a live environment, not a diagram. Also ask whether agent credentials are ephemeral and scoped to a single task or session, versus long-lived and broadly provisioned, since the latter defeats the purpose of least privilege regardless of how it is described in sales materials.

Runtime Policy Enforcement: Blocked or Just Logged?

A recurring distinction in agent governance is between systems that enforce policy synchronously, blocking a non-compliant action before it executes, and systems that only monitor and alert after the fact. Post-hoc monitoring has value for investigation, but it does not prevent an agent from executing an unauthorized claims payout adjustment or accessing out-of-scope underwriting data. Ask vendors directly what happens operationally when a policy violation is detected at runtime: is the action blocked, escalated to human review, or only logged, and is this behavior configurable per workflow. For consequential insurance actions such as claims denials or underwriting decisions, human oversight and override capability should be a contractual requirement rather than an optional setting, consistent with the emphasis on human oversight found across NIST and NAIC guidance.

Model Context Protocol Security

The Model Context Protocol, introduced by Anthropic in November 2024, has become a common standard for connecting AI agents to external tools and data sources through a client-server architecture. Its security posture depends heavily on how each individual MCP server is implemented, since the protocol separates the reasoning model from the tool connectors it calls. Early MCP implementations lacked standardized authentication and authorization mechanisms, and OAuth-based authorization flows were only added to the specification in 2025. This means a vendor's claim of MCP support says little on its own. Ask which protocol version is implemented, whether OAuth-based or equivalent cryptographic authorization is used rather than static shared secrets, and how the vendor validates the security of any third-party MCP servers it connects to. A vendor built on an older MCP deployment may be carrying forward authorization gaps that were only recently addressed in the standard.

Auditability: What Insurance Compliance Review Actually Requires

Auditability for agentic systems goes beyond logging final outputs. Reconstructing a decision chain for a regulatory or internal compliance review requires records of intermediate reasoning steps, the specific tool calls an agent made, the parameters passed to those calls, and the data sources accessed. This level of detail matters directly for insurance workflows, where a claims or underwriting agent's decision path may need to be reproduced months later for a state regulator or internal audit. Ask vendors what is logged, in what format, and whether logs can be exported in a form usable by existing compliance tooling. Also confirm data residency and access logging practices for any claims, policy, or underwriting systems the agent is permitted to query, since these are precisely the systems the NAIC bulletin identifies as carrying insurer accountability regardless of which vendor built the tool.