AI and cybersecurity for insurers, on the work that already exists

Insurers are not short of places to put an agent. Claims notes, policy wording, broker questions, underwriting referrals, and the long tail of servicing mail are all text, and text is what these systems consume. The mistake is to treat that as permission. A claim file is a decision that spends the company's money and the customer's trust. An agent allowed to wander through it is a new insider.

S·CORP's work with insurers starts from the file, the authority to touch it, and the cyber basics the carrier already claims to follow. We do not invent a loss ratio for the project. We ask who may decide, what they may see, and how the security team will know.

Separate drafting from deciding

An agent can assemble a chronology from documents already in the claim system. It can point at a clause in the wording that a handler asked for. It can draft a request for a missing document. Those are drafts. Settlement, denial, rescission, a fraud referral, and any communication that tells a claimant what the company will pay are decisions. A named person with the existing authority makes them. The file records that the person saw the draft and what they changed.

If the draft is stored, store it as a draft. Handlers and auditors should be able to tell the model's language from the company's language. This is not a stylistic preference. It is how you explain a file later, including to a regulator or a court that asks what the company knew.

Underwriting referrals follow the same split. An agent may prepare a summary of the submission against the questions the underwriter already uses. It does not get an appetite of its own. If the appetite lives in a guideline, the person applies the guideline. If the appetite lives only in a prompt, the appetite is unauditable.

The claim file is the data map

Carriers already know that claim files are sensitive: health information on some lines, financial information on others, identity documents almost everywhere. The GDPR, where it applies, and sector rules the carrier already follows, do not relax because a model is in the path. The agent and its index are a new processing location. Name it in the record of processing. Name the vendor if a vendor hosts it. Name the retention, which should not be longer than the file's own retention just because a trace product defaults to forever.

Do not embed the entire archive "to see what the model can find." Build the retrieval from the file the handler is allowed to open, at the moment they are allowed to open it. Cross-file search sounds powerful and becomes a breach of the least-privilege rule the security team already wrote. If a fraud team needs cross-file search, that is a different system, with a different authority, not a feature of the handler's assistant.

PCI DSS is in scope when premium collection or card payments sit next to the servicing bot. Keep payment instruments out of the conversation. The policy system has a token or an internal reference. Use that.

Cybersecurity is the ordinary kind, applied to a new runtime

The agent runtime is an application. It needs an owner, a patch path, an identity, logs, and a place in the incident process. ISO 27001's value, for a carrier that uses it, is that this runtime should not be a shadow IT project beside the ISMS. Put it in scope. If the carrier does not certify to ISO 27001, the same questions still stand: who administers it, how credentials are stored, how you will hear about a vulnerability in the orchestration layer.

OWASP's Top 10 for LLM Applications is the specific overlay. Prompt injection against a claim summary is not theoretical. A claimant, a repair shop, or a document in the file can carry instructions. The agent's tools should not include "email the file to an address found in the document" or "change the reserve." Tool parameters come from the claim system, not from the text.

Excessive agency shows up as a connector to the policy admin system with broad update rights, created so a pilot could "do more" later. Delete the rights the pilot does not need. A read of the wording and a write of a draft note are usually enough for a first release.

Vendor traces are a cyber and privacy issue together. A prompt that contains a medical note is a disclosure to every company that stores the prompt. Turn off uses of customer content that the contract does not require. Test that the switch does what the contract says, with a file you can afford to use as a test, not with a live claimant.

Distribution and the broker channel

Agents that answer brokers are a different trust boundary. The broker is not the carrier's employee, and the broker's customer is not sitting in the carrier's identity system in a simple way. Authenticate the broker with the mechanism the carrier already trusts. Limit the answer to that broker's book. A model that "helps" by looking up a similar policy from another broker is a confidentiality incident.

Marketing and agency partners who build these experiences for a carrier should expect the carrier's security team to review tools, data, and logging as they would review any new system. A prototype hosted on a personal account is not a pilot. A pilot has an environment, an owner, and a date when it is turned off if the scope is not met.

What a serious first release contains

A named operation. A list of decisions the agent must not make. A data map no wider than the handler's own authority. Tools with narrow verbs. A person on the decision. Logs that point at the claim number rather than hoarding the claim. A vendor path the privacy office has read. A way to switch the agent off without a developer in the room.

NIST's AI Risk Management Framework can organize the conversation with risk. It will not choose the operation for you. The operation should be one the claims or servicing leadership already wants improved for reasons they can say without a model: missing documents, slow chronology, inconsistent wording. The agent serves that reason, or it does not ship.