How it works

Permissions and approval

Two permissions, three kinds of tool, one rule about what stops for a yes — and a role that scopes Claude exactly as it scopes you.

The two permissions#

The consent page asks for one or both of these, in these words. Reading is always included; getting work done is a tick you can clear, and a connection that holds only the first can call nothing that writes.

Read your bookbrella.read

Always included

Policies and leads, locations and buildings, documents, certificates, claims, today’s work, licensing and the surplus lines calendar — only what you can see in Brella OS.

Get work donebrella.write

Your choice

Update records, generate ACORD forms and the SOV, add certificate holders, draft change requests and set reminders — the same work you do in Brella OS.

Asking for brella.write implies brella.read — there is no write-only connection, because nothing can sensibly be changed without first being read.
A request naming no scope gets both, and the person still decides on the consent page.
offline_access is accepted and ignored: every grant gets a refresh token, so there is nothing to ask for.

Three kinds of tool#

Behind the second permission is a line the product draws for itself, and Claude inherits it unchanged. Every one of the 102 tools is exactly one of three kinds:

Read

Looks and changes nothing. Runs without asking.

readOnlyHint: true

Changes

Edits the agency’s own record, under Claude’s normal approval.

destructiveHint: false, or true where it replaces rather than adds

Asks first

A policyholder would see it, or it can’t be undone. Claude asks you every time.

destructiveHint: true, plus _meta["anthropic/requiresUserInteraction"]

Today: 30 read, 38 change the record, 34 ask first. Which tool is which is in the tool reference, and the counts there and here come from the same generated file.

What always asks first#

The rule has three clauses, and a tool only has to meet one: anything a policyholder would see, anything a certificate will assert, and anything that cannot be undone. In practice that is:

Messages to the policyholder
Document requests
Questions in their portal
Questionnaires on their policy
Issuing certificates
Published advisories
Stage changes
Claim statuses and notes
Change requests marked sent
The endorsement on file
Filings and waivers
Every delete

Why a delete counts

Deleting is not outward, but it is permanent, and a record an agency is later asked to produce cannot be un-deleted. Recording a surplus lines filing and waiving an obligation are on the list for the same reason: both assert that something happened on a date, and a regulator reads them.

Everything else either only reads — and runs without asking — or changes your agency’s own record under Claude’s normal approval. Nothing in either group reaches a customer.

How your client is told#

The connector does not invent its own confirmation dialog; it tells your client what kind of thing each tool is, using MCP’s own tool annotations, and the client asks. That is why the same line holds whether you are in Claude, in Claude Code, or in something else entirely.

A read is readOnlyHint: true.
A write that only ADDS a record carries destructiveHint: false; one that changes or replaces a value carries true, because a directory reads destructive as “modifies or deletes data”.
Every ask-first tool carries destructiveHint: true and _meta["anthropic/requiresUserInteraction"], which is what makes Claude Code ask every time rather than once.

The plugin adds a second belt for Claude Code: a hook on the outward tools that asks before the call and flags risky coverage language in what is about to be sent. It never denies a call — it asks.

What your role reaches#

Your role in the agency scopes Claude exactly as it scopes you. This is not a rule the connector added: it is agencyCanAccess, the predicate every screen in the workspace already runs, and it is re-read from the membership table on every request rather than frozen into the token. Remove somebody from the agency and their connection stops working on its next call, with nothing to revoke by hand.

Owner: The agency’s whole book. Can also revoke any connection into the workspace, not only their own.
Manager: The agency’s whole book. Cannot revoke another member’s connection.
User: Only the leads and policies assigned to them. A policy reassigned away disappears from their Claude too.
Platform staff: Cannot connect at all. Brella’s own staff have no access to an agency’s book, and the connector does not change that.
Policyholder portal: Cannot connect. The portal is a different account family with its own tokens; the connector is for agency members.

Reads are scoped too

A User asking “what needs me today” gets their own work, not the agency’s. A search returns the policies they are assigned. There is no wider read that gets narrowed afterwards for display — the scoping is in the query.

When a permission is missing#

A call to a tool your connection’s scopes do not cover fails with 403 insufficient_scope, naming the scope it needed. In Claude that usually surfaces as a prompt to re-authorise with more access; if it does not, disconnect and connect again with Get work done ticked. Nothing half-runs: a refused call changes nothing.

Connect Claude

Tool reference