Model Context Protocol Hits Indian Insurance Stacks: Tool-Permissioning, Audit Trails and the Governance Questions Brokers Should Ask Vendors

In May 2026, ITC Infotech and InsureMO announced an alliance that pairs ITC's agent orchestration with InsureMO's library of what the companies describe as more than 2,500 atomic APIs spanning policy, claims, underwriting, distribution and product configuration. The stated mechanism matters more than the press release tone: the agents do not need bespoke connectors. They discover and call those APIs over a Model Context Protocol (MCP) server, with India named among the target markets.

MCP, originally published by Anthropic, has in roughly a year become the default way to connect large language model agents to enterprise systems. Other insurance-technology and payment players have moved the same way, building MCP into their architecture for tasks such as claims disbursement. For Indian brokers, the takeaway is not that another insurtech demo exists. It is that the question you ask a platform vendor has to change.

The old question was "how accurate is your model?" That question is now nearly useless. When an agent can call BindPolicy, IssueEndorsement or TriggerPayment against a live API, accuracy of language is not the control that protects you. The control is which tools the agent is permitted to call, under what conditions, with what human checkpoint, and whether every call leaves a tamper-evident record. The model is the engine. Tool-permissioning is the steering, the brakes and the black box recorder.

This post is a diligence guide. If you are a broker buying an agentic platform, or a corporate risk manager whose insurer or TPA is deploying one, these are the questions that separate marketing from a defensible control environment.

An LLM on its own cannot do anything to a policy. It generates text. Risk enters the moment that text is allowed to trigger an action in a system of record. MCP formalises that bridge: the agent is exposed to a discrete set of named tools, each mapping to an API such as GetQuote, UpdatePolicy or RequestDocument, and the agent can only invoke what it has been granted.

This is why practitioners increasingly describe MCP as a control plane rather than a connector. The governance levers live in the tool layer, and they are concrete:

• Scope-limiting: which of the 2,500-plus APIs is a given agent even allowed to see. A quote-illustration agent should never have the endorsement or payment tools in its menu.
• Conditional execution: a tool call can be allowed only when parameters fall inside set bounds, for example sum insured below a threshold, or only for renewal business on existing wordings.
• Human-in-the-loop checkpoints: binding, endorsing or paying can be configured to require a named human approval before the call executes, not after.
• Validation gates: every proposed action checked against access controls and business rules before execution, so a malformed or out-of-policy call is rejected rather than logged as a mistake.

The partners describe tool-level controls designed precisely to restrict which tools each agent can call and to keep behaviour inside regulatory bounds. The design intent is sound. What a broker must verify is whether the implementation in front of them actually enforces it, or merely documents it.

The uncomfortable middle

The danger zone is the agent that has read-write tools but loose conditions. It demos beautifully, because in the demo the operator picks safe inputs. In production, it will eventually be handed an edge case, a typo in a sum insured field, an ambiguous instruction, a near-duplicate risk, and it will call a tool it should have been blocked from calling. Your diligence is aimed at finding the gap between the demo path and the failure path before you sign.

Treat these as non-negotiable in any RFP or proof of concept. Ask for evidence, not assurances.

1. Show me the tool allow-list per agent role. A serious vendor can produce, for each agent persona, the exact set of tools it can call. If the answer is "the agent has access to the platform," that is an ungoverned stack. You want least-privilege by default: an agent gets GetQuote and GeneratePDF, and nothing that writes to a system of record unless explicitly justified.

2. Which actions are gated behind a human approval, and is that gate enforced server-side? A human checkpoint that the agent can bypass with the right prompt is theatre. The approval must be enforced at the tool layer, where the model cannot talk its way past it. Ask specifically about BindPolicy, IssueEndorsement, cancellation and any payment trigger.

3. What happens on an out-of-bounds call? Request a live demonstration where the agent attempts a binding above its authority or an endorsement on a wording it should not touch. A governed stack rejects the call and logs the attempt. An ungoverned one executes and hopes the model was right.

4. Can permissions be changed without redeploying code? Authority limits change with appointment letters, capacity and renewal seasons. If tightening an agent's scope needs an engineering release, governance will lag reality.

5. How are credentials and tokens scoped and revoked? Each MCP call should carry an authentication token tied to role-based access, and you must be able to revoke an agent's access instantly. Ask how a compromised or misbehaving agent is cut off, and how long that takes.

Every responsible MCP description promises audit logging. The phrase is doing a lot of work, and brokers should pull it apart, because a log that you cannot use to defend a claim is decoration.

What an evidentiary trail needs to capture, per agent action:

• The agent identity and the human, if any, who approved or initiated it.
• The exact tool called, the full parameters, and the timestamp.
• The inputs the agent saw and the reasoning artefact it produced, so a reconstruction is possible months later.
• The validation result, allowed or rejected, and which rule applied.
• The system-of-record state before and after.

Now the questions that matter for defensibility. Is the log immutable, or can it be edited by an administrator? Is it retained for the full limitation period of any policy the agent touched, which in Indian commercial lines can stretch years past the action? Can you export it in a form an Ombudsman, a court or an IRDAI examiner will accept, or is it locked inside the vendor's console?

Why this is a broker problem, not just an IT problem

When a client disputes that an endorsement narrowed cover, or that a binding was issued on terms they never agreed, the broker is the party who has to reconstruct what happened. If an agent drafted that endorsement, your defence is the audit trail. A vague "the system did it" is worse than useless before the Insurance Ombudsman.

The practical test: ask the vendor to produce, for a single past transaction in their demo environment, the complete chain from instruction to executed API call to record change. If it takes them days, or if pieces are missing, that is the experience you will have during a live dispute, except with a real client and a real deadline. Build retention and export terms into the contract, not the brochure.

Here is the part most demos skip. When an agent binds a policy, issues an endorsement or gives advice that turns out wrong, who is the intermediary in the eyes of the regulator and the client?

Under Indian law the broker owes the client a duty of care, and the IRDAI conduct framework holds the licensed intermediary accountable for advice and placement. An agent does not dilute that duty. Commentary on the evolving rules is consistent: insurers and intermediaries may be held liable for consequences of AI-driven advice or decisions, and accountability principles already visible in SEBI's stance on AI use by regulated entities are expected to extend across the financial sector. Other jurisdictions point the same way: Singapore's AI governance work has consistently held that the organisation deploying a system stays accountable for its behaviour, not the tool vendor and not the model. India's direction of travel looks similar.

What this means in practice for a broker buying an MCP-driven platform:

• The agent is your employee, legally speaking. Its actions are your actions. Tool-permissioning is not a technical preference, it is how you keep the agent inside your actual authority.
• Your professional indemnity exposure changes shape. Errors no longer happen at human speed in ones. A misconfigured agent can repeat the same wrong endorsement across a book before anyone notices. Review your professional indemnity limits and the wording's treatment of automated processes, and talk to your PI underwriter about the deployment before, not after.
• Vendor contracts must allocate fault. If the vendor's tool layer failed to block an unauthorised call, where does liability sit. Indemnity, caps and the cooperation obligations during a client dispute need to be negotiated.

The IRDAI Information and Cybersecurity Guidelines, 2023 already push board-level accountability for security at regulated entities, including intermediaries. Agent governance is the logical next chapter, and brokers who can show a controlled deployment will be in a far stronger position than those who cannot.

Governance is not only a compliance cost. It moves money, and brokers who understand where will buy and sell better.

On placement and pricing, an agent that drafts quotes and endorsements at scale changes the error profile of your book. Underwriters care about that. A broker who can evidence tool-permissioning, human checkpoints on binding and a clean audit trail presents a lower operational-risk counterparty than one running an opaque automation. Expect that to matter in underwriting conversations about your facilities and binding authorities, and to feed into how your own PI is rated.

On wordings, the policy wording is the asset most exposed to automated drafting. An agent that issues an endorsement is editing the contract. If it pulls a near-but-wrong clause, narrows a definition, or applies a wording from the wrong insurer template, the client is under-covered and does not know it. This is why endorsement and binding tools deserve the tightest scope and the firmest human gate. The cost of a wrong wording surfaces only at claim, when it is a coverage dispute rather than a typo.

On vendor selection, a practical filter:

• Prefer platforms where write-actions are off by default and switched on per use case with documented authority.
• Insist that the audit export format is open and yours to keep, surviving any exit from the vendor.
• Check that the agent cannot see client data outside the tenant it is serving, and that data handling matches your own cyber insurance and the IRDAI Information and Cybersecurity Guidelines, 2023 expectations.

For brokers serving IT services clients, who are often the earliest adopters and the most demanding on data control, being able to speak fluently about MCP tool governance is fast becoming part of the pitch, not a footnote.

Pull the threads together into something you can take into a vendor meeting tomorrow. Score each item; a platform that fails the first four is not ready for write-actions on your book regardless of how good the demo felt.

1. Least-privilege tool map exists and is per-role. You have seen, in writing, exactly which tools each agent can call. Write-actions are justified individually.
2. Human gates are enforced server-side on bind, endorse, cancel and pay. Demonstrated live, not described.
3. Out-of-bounds calls are rejected and logged. You watched the agent try and fail to exceed its authority.
4. Audit trail is immutable, complete and exportable in a form fit for an Ombudsman or IRDAI examiner, retained for the full limitation period.
5. Permissions are configurable without redeployment, so authority can be tightened the day an appointment changes.
6. Token scoping and instant revocation are demonstrated, with a clear answer on how a rogue agent is cut off.
7. Tenant isolation of data is verified, with no cross-client visibility.
8. Contractual liability allocation is negotiated, covering vendor fault in the tool layer, cooperation during disputes, and audit access on exit.

The meta-point for Indian brokers in 2026 is simple. MCP is genuinely useful. It lets agents compose real work across thousands of insurance APIs without months of integration, and that productivity is real. But the protocol moves the entire risk story into the tool-permissioning layer, and that layer is exactly where most marketing is silent. The brokers who win, and who stay out of the Ombudsman's queue, will be the ones who treat agent governance as a placement-grade diligence exercise, ask the questions above, and refuse write-access to any agent whose leash they cannot see, test and revoke.