Banking and insurance: read-only is the feature

Start with a narrowly defined customer question, such as finding policy information or a claim status. Decide which data an assistant may read in the customer's session and review the associated risks before implementing a tool.

Nobody is asking you to let an agent bind a policy. They are asking whether a customer can find out what their policy covers without navigating a portal at eleven at night.

A surface that passes review

find_my_policy()                      readOnlyHint: true
explain_coverage(policyId, scenario)  readOnlyHint: true
get_claim_status(claimId)             readOnlyHint: true
list_required_documents(claimType)    readOnlyHint: true
locate_form(topic)                    readOnlyHint: true
get_next_payment()                    readOnlyHint: true

prefill_claim_draft(...)              // prepares only; the human submits

These are candidate tools, not a verified deployment. Read-only behavior must be enforced by the application; a draft operation must not submit or change a claim without the intended human step.

The argument for the compliance meeting

1. Review the credential path. Browser tools may use the visitor's authenticated session, while a remote MCP server needs its own authorization design. Check what the assistant can see, retain and send, and how access is revoked.
2. Read-only is declared and enforced. readOnlyHint: true tells the agent. Your server-side authorisation enforces it. The annotation is advisory — the authorisation is not, and that distinction belongs in the submission.
3. Nothing is enumerable. Tools scope to the session. There is no tool that accepts an arbitrary policy number.
4. Anything consequential stops for a human, in your own UI, with your own confirmation copy.
5. Scope is bounded by policy. The tools permissions-policy feature defaults to an allowlist of ['self']; a cross-origin iframe needs an explicit allow="tools".

Do the boring pillars first

Public product pages may have access, rendering or form-label barriers that a source scan can inspect. Private portals need a separate authorized review and task test.

Fix a documented public-page barrier where it affects the chosen task. Estimate the implementation effort from the actual code and verify the page and browser task after the change.

The knowledge layer, further out

For institutions, the machine-readable knowledge layer eventually matters as much as the action layer. An agent answering a coverage question needs facts that are current, sourced and approved — not a paragraph scraped from a marketing page.

A governed knowledge layer may need provenance and freshness metadata: source, verification owner and review date. Scope it against the institution's data and access controls rather than assuming a standard format or timeline.