Carrier Governance of MGA AI Costs: Making Pass-Through Charges Verifiable

What must be governed in an AI pass-through arrangement

When an MGA or delegated partner underwrites, handles claims or performs another function on a carrier's behalf, AI use inside that function can surface as a line on an invoice, an expense allocation or a change in service pricing. The carrier then holds a charge it cannot easily trace to a system, a data flow or a decision.

Three things need to be governed together. The first is the charge itself: what was billed, on what basis, and for which function. The second is the AI use behind the charge: which models and tools were involved and what data they touched. The third is permission: whether that use fell within the carrier's own policy and its regulatory obligations. A pass-through arrangement is governed only when all three can be linked to each other.

This guide treats the problem as one of oversight and evidence. The question is not whether the amounts are large or small. It is whether the carrier can substantiate them and show what partner AI systems were allowed to do and what they did.

Financial review versus technical evidence

Finance teams already review invoices and allocations, and that work remains necessary. It answers a different question from the one an examiner or auditor is likely to ask. Keeping the two workstreams separate prevents a reconciled invoice from being mistaken for evidence of controlled AI behavior.

• Question answered: Financial review: was the amount billed consistent with the agreement? Technical evidence: what did the AI systems do, and was it permitted?
• Typical artifact: Financial review: invoices, expense allocations, bordereau-level summaries. Technical evidence: per-interaction records of model, tool, policy decision and outcome.
• Owner: Financial review: finance and vendor management. Technical evidence: risk, security, compliance and the partner's engineering team.
• Limitation: Financial review cannot show which tools ran or whether data handling was allowed. Technical evidence says little about price unless it is tied to the charge.

The regulatory anchor and where it stops

NYDFS Insurance Circular Letter No. 7, titled Use of AI Systems in Insurance Underwriting, was issued in final form on July 11, 2024. As of October 2026, it maintains the expectation that insurers conduct appropriate oversight of third-party vendors. It also calls for a governance and risk management framework to mitigate potential consumer harm and comply with legal obligations, and it places oversight of that framework with the board or other governing body, which monitors risk appetite. Pass-through AI arrangements belong inside that risk appetite and its reporting.

NYDFS guidance on third-party service providers adds that senior governing bodies and senior officers must engage actively in cybersecurity risk management, including oversight of third-party risks. The AI cybersecurity guidance states that it imposes no new requirements beyond 23 NYCRR Part 500 and explains how to apply that framework to AI-related risk.

NIST AI RMF subcategory MAP 3.2 asks organizations to examine and document potential costs, including non-monetary costs, that result from AI errors or from system functionality and trustworthiness. That framing is useful here: a pass-through charge is one input to a risk record, not only a ledger entry.

These materials set expectations for governance and oversight. They do not prescribe log formats, retention periods or audit-right clauses for delegated partners. Those terms are the carrier's to define by contract, and the requirements below are suggested controls, not regulatory mandates. Banking regulators' principles on due diligence, contract management and ongoing monitoring are a reasonable analogy for structuring them, but they are not an insurance obligation.

Evaluating whether partner controls operate in the execution path

Records can be produced in two ways. A partner can reconstruct a report after the fact from application logs and billing data. Or the partner's AI execution path can enforce policy on each interaction and tool call and record the decision when it happens. The second approach generally gives the carrier stronger grounds to rely on the evidence, because the record is a by-product of the control rather than a summary written later. This is an evaluation criterion, not a regulatory requirement.

When assessing a partner, ask five questions. Is policy applied before a model response or tool action takes effect, or only reviewed afterward? Can the partner show allow, redact and block outcomes for individual interactions? Do records identify the model and tool, so a charge can be matched to them? Are records durable, with retention the carrier controls? Does the evidence cover subcontracted AI providers as well as the partner's own systems?

Runtime policy enforcement is one technical mechanism that meets these criteria. Trussed enforces policy in the execution path across models, agents, tools and MCP servers, applying allow, redact, block, rate limit or escalation for human approval to individual interactions and tool calls. That enforcement produces audit-ready evidence, which Trussed maps to NAIC, NYDFS and NIST expectations. It can be deployed self-managed in a customer's cloud, with configurable retention and data residency. A carrier can use the same criteria to evaluate any partner approach, whether or not it uses Trussed.

One tradeoff deserves attention. Requiring execution-path evidence places a technical burden on partners and may limit which partners and tools the carrier can accept. Carriers can phase the requirement, starting with delegated functions that handle the most consequential decisions or sensitive data.