Restrict access by policyholder, claim, product, jurisdiction, and assigned team.
Scope resolves from the case in front of the agent — one policyholder, one claim — not from the carrier’s whole book.
Govern agents across underwriting, claims, policy servicing, and sensitive customer records.
Insurance agents work with personal, medical, financial, property, and behavioral data. They may summarize submissions, assess claims, recommend coverage, request documentation, or update policies.
Between 03 and 04 the agent stops assembling and a person decides.
Assembled from the claim’s own file and sent under the handler’s permissions. The message, its inputs and both identities are on the record.
Scheduling is routine work inside the case, so it goes out without waiting for anyone.
Blocked. Field-by-field limits keep medical detail out of a workflow with no approved reason to use it — the attachment is never retrieved, so there is nothing to send.
A different handler’s claim. Scope resolves from the case in front of the agent, so the file cannot be read and the message cannot be written.
Coverage and payment are the adjuster’s to decide, and neither is an action this agent holds. The draft stays where it is because there is no tool to send it.
NOT IN THE GRANTExample messages. The cases, sensitive fields and grants are the ones you set.
Scope resolves from the case in front of the agent — one policyholder, one claim — not from the carrier’s whole book.
Agents assemble and suggest; decisions that affect coverage or payout remain with adjusters and underwriters.
The decisions regulators scrutinize hardest are not actions any agent holds, so they stay with the people who have the authority to make them.
Field-by-field limits keep medical, financial, or behavioral data out of workflows that have no approved reason to see it.
Draft and send are separate actions, so an agent can prepare a letter to a policyholder, broker, or third party and have no way to send it.
Every claim and policy outcome carries what informed it, which agent acted, and whose authority it ran on — market-conduct evidence by default.
Explore the context attached to every request.
claims-agent has a defined purpose and a bounded set of tools.
The request acts for claims handler, using that person’s permissions.
The policy applies to the requested action within Claims platform, before the tool executes.
Intake agents summarize and route each new claim, limited to that claim’s policy and documents alone.
Assistants assemble submissions and flag risk factors; acceptance and pricing stay with the underwriter.
Routine changes are granted and apply automatically; coverage-affecting changes are not granted at all, so they stay with authorized staff.
Review agents work assigned referrals read-only, preserving evidence and avoiding cross-case contamination.
Broker-facing agents answer from approved product and appointment data, without exposing other producers’ business.
Analysis stays inside the case’s own documents, with sensitive details gated by purpose.
No. It drops in between your agents and the platforms you already run. Agents keep working in your claims and policy systems; Fabriq decides, per request, what they can read and which actions they can take there.
Field-by-field limits. A workflow with no approved reason to see medical or behavioral data simply cannot retrieve it — the block is enforced on every request, not requested politely in a prompt.
Grants resolve org → team → member, so authority follows the person — and revoking a session cuts their agents’ access immediately.
Yes — per user. The same agent can assemble files under a junior adjuster’s tight limits and act more broadly for a senior underwriter, because reach resolves from the person the agent works for. Denials, settlements, and coverage changes stay with humans because no agent is granted them.
Yes — an adjuster’s agent can read and draft freely while payment and coverage-change actions stay out of its grant, so they never appear in its tool list. Every call it does make is part of the record.
Through the hub — prebuilt connectors plus OpenAPI import for internal claims and policy APIs, with credentials held in the vault, not in bot configs.