Protect Insurance Claim Intake with Claude Code: Keep Policy Numbers and Medical Files Out

An accident intake inbox contains one customer email, a policy PDF, repair estimate, accident note, and a photo of a medical certificate in the same folder. The staff member wants to reply quickly, so the tempting request is: “read all of this and draft the missing-document email.” That shortcut is where the workflow breaks. Policy numbers, addresses, vehicle identification numbers, diagnoses, and counterparty names can be mixed into the draft before anyone notices. The first fix is not a better prompt. It is a table that separates claim intake CSV fields from original attachments before Claude Code sees them.

For an insurance agency, claim intake joins customer support, carrier handoff, document chasing, and internal approval. Claude Code is useful for classifying a redacted intake CSV, finding missing document categories, drafting a review checklist, and checking local permission settings. It should not decide claim payment, coverage, liability, medical evidence, consent, or the official destination for each carrier. Those decisions stay with trained staff and the agency’s approved process.

This article uses current primary sources: Claude Code permissions, Claude Code sandboxing, Japan FSA guidance on financial-sector personal information protection, the PPC cloud-service notice, and PPC material on insurance companies and agencies. This is not individual legal advice. The single primary CTA is training and consultation because this workflow needs role boundaries, approval rules, and practice with fictional fixtures.

Key Takeaways

• Keep originals in claim-raw/ and put only redacted working copies in claim-ai-work/.
• Let Claude Code see claim ID, case type, date band, missing-document category, redacted summary, and next owner.
• Keep policy numbers, addresses, phone numbers, emails, VINs, medical certificates, diagnoses, counterparty data, and carrier-specific internal notes out of the AI workspace.
• The three use cases are intake classification, missing-document email drafts, and carrier-specific submission checklists.
• Measure ROI with draft time, review time, rework, and the number of records stopped by the pre-input check.

Workflow: Separate Intake CSV and Attachments

Start with four folders. claim-raw/ holds the originals: customer emails, policy PDFs, medical certificate photos, repair estimates, and counterparty notes. claim-transform/ holds the field map and redaction rules. claim-ai-work/ holds the redacted working copies. claim-approved/ holds staff-approved emails and checklists.

Folder	Contents	Claude Code access
claim-raw/	Original emails, policies, medical files, photos, estimates	Deny read and write
claim-transform/	Field map, replacement rules, check command	Human-reviewed execution
claim-ai-work/	Redacted CSV, category table, draft material	Allow read and write
claim-approved/	Approved email and submission checklist	Human-controlled storage

The working CSV should be deliberately small. A useful row contains claim_id, case_type, received_date, missing_document_type, redacted_summary, next_owner, and carrier_channel. carrier_channel can be a category such as “Carrier A portal” or “Carrier B broker desk.” It should not contain the actual destination email, staff name, or direct carrier contact.

Free-text accident notes need special care. Phrases like “in front of the customer’s home,” “the customer’s mother was in the car,” or “neck pain after the collision” can reveal identity or health information. In the AI copy, replace them with “policyholder A,” “passenger B,” or “medical detail exists; check original.” Do not put diagnosis, hospital names, or medical-document content into the working file.

The Japanese PPC insurance-agency material discusses cases where policyholder data was not separated by insurer and was sent broadly, as well as inappropriate sharing by seconded staff and gaps in organizational and human safeguards. That makes the boundary here practical rather than theoretical: the AI workspace must make it harder to send one carrier information that belongs to another relationship.

flowchart TD
  A[claim-raw originals] --> B[claim-transform field map]
  B --> C[Redact and generalize]
  C --> D[Pre-input check]
  D --> E[claim-ai-work working copy]
  E --> F[Claude Code draft]
  F --> G[Staff review]
  G --> H[claim-approved final output]

What Claude Code Handles and What People Decide

Claude Code handles classification and drafting after redaction. It can sort redacted CSV rows, mark missing document categories, prepare questions for staff, and produce a customer email draft. For example, from “auto property, repair estimate missing, accident date present,” it can create a checklist item and a polite request for the missing estimate.

People decide coverage, claim payment, exclusions, liability, medical evidence, counterparty contact, official submission, consent, and retention. A Claude Code draft is not sent as-is. A staff member checks the original, the carrier procedure, the approved wording, and the actual recipient.

Permissions and sandboxing should be layered. Claude Code permissions control which tools can touch which files or domains. The official permissions page explains that permissions and sandboxing are complementary: permissions apply to tools such as Read, Edit, Bash, WebFetch, and MCP, while sandboxing gives OS-level boundaries to Bash commands and child processes. For this agency workflow, deny Read(/claim-raw/**) and Edit(/claim-raw/**), then allow only claim-ai-work/. Add sandbox filesystem denial so shell commands cannot read the original folder either.

For related background, read the localized Claude Code permissions guide and Claude Code security practices.

Three Use Cases

Use case 1: Classify intake CSV rows by claim type and missing document

• Input: claim_id, case type, received date, redacted summary, attachment category, and team owner.
• Output: classification, missing documents, original-field review column, and staff questions.
• Human review: coverage, contract content, policy number, counterparty data, medical files, and carrier destination.

Ask Claude Code for candidates and review fields, not final claim decisions. On heavy intake days, a redacted CSV can still help staff see which files need repair estimates, accident notes, or a carrier upload. The original contract remains outside the AI workspace.

Use case 2: Draft a missing-document email

• Input: claim ID, pseudonymous customer label, missing document category, response date, submission options, and contact channel category.
• Output: subject line, body, document list, reply caution, and send-before checklist.
• Human review: recipient, real customer name, actual required documents, carrier name, submission method, and attachments.

For missing-document messages, recipient accuracy matters more than elegant writing. The AI copy should contain categories like “repair estimate,” “accident note,” or “medical-related document,” not the medical details themselves. The structure is close to the broader inquiry workflow article.

Use case 3: Prepare a carrier-specific submission checklist

• Input: carrier category, claim type, submission channel, required-document category, staff role, and prohibited information.
• Output: pre-submission checklist, carrier-specific review column, information not to send, approver, and hold reason.
• Human review: outsourcing scope, consent, carrier rules, official destination, and customer contact while held.

Multi-carrier agencies need a habit of separating information by relationship. Claude Code should not decide where to send the claim. It should create review boxes that force a person to confirm the approved carrier channel and the scope of data sharing.

Copy-Paste Prompt

Use this prompt only after the working CSV has been redacted and placed in claim-ai-work/. Do not add policy PDFs, medical files, or original emails to the prompt.

You support insurance-agency claim intake.
Read only ./claim-ai-work/intake-redacted.csv and output in this order:

1. Claim type candidate for each claim_id
2. Missing document category
3. Original record fields a staff member must check
4. Draft missing-document email to the policyholder
5. Pre-send checklist

Constraints:
- Do not decide payment, exclusion, liability, or coverage
- Do not infer policy number, address, phone, email, VIN, diagnosis, or counterparty name
- Do not read original folders, send email, call external services, or delete files
- If you detect personal-data-like values, stop and report only the field name
- End with: "Not sendable before staff review"

Working Check Code

If you introduce a helper file, save it as tools/check-insurance-claim-input.mjs. This article does not create that file in the repository. The complete contents are below. The example uses fictional local fixtures only.

const files = [
  {
    path: "claim-ai-work/intake-redacted.csv",
    text: "claim_id,case_type,redacted_summary\nC-001,auto_property,front bumper damage"
  },
  {
    path: "claim-ai-work/bad.csv",
    text: "claim_id,email,policy_number\nC-002,[email protected],AB1234567890"
  }
];

const blockedFieldNames = [
  "name",
  "email",
  "phone",
  "address",
  "policy_number",
  "vin",
  "diagnosis",
  "hospital",
  "counterparty"
];

const valuePatterns = [
  /[A-Z]{2}\d{10}/,
  /[\w.+-]+@[\w.-]+\.[A-Za-z]{2,}/,
  /\b\d{2,4}-\d{2,4}-\d{3,4}\b/
];

const findings = [];

for (const file of files) {
  const lower = file.text.toLowerCase();
  for (const field of blockedFieldNames) {
    if (lower.includes(field)) findings.push({ path: file.path, type: "blocked field", field });
  }
  for (const pattern of valuePatterns) {
    if (pattern.test(file.text)) findings.push({ path: file.path, type: "blocked value", pattern: String(pattern) });
  }
}

console.table(findings);
if (findings.length > 0) process.exitCode = 1;

The test does not prove privacy safety. It only catches obvious field names and simple values. PDFs, images, handwriting, and meaning inferred from multiple columns are outside this example, so staff review remains mandatory.

{
  "permissions": {
    "deny": [
      "Read(/claim-raw/**)",
      "Edit(/claim-raw/**)",
      "Read(/secrets/**)",
      "Edit(/secrets/**)",
      "Bash(git push *)"
    ],
    "allow": [
      "Read(/claim-ai-work/**)",
      "Edit(/claim-ai-work/**)",
      "Bash(node tools/check-insurance-claim-input.mjs *)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "denyRead": ["./claim-raw", "./secrets"],
      "denyWrite": ["./claim-raw", "./secrets"]
    }
  }
}

Pitfall: Why the Boundary Breaks and How to Fix It

First mistake: removing only the policy number. Accident notes can still contain addresses, VINs, counterparty names, employers, hospitals, and diagnoses. Fix it by defining allowed fields per task and turning free text into a short redacted summary before it enters claim-ai-work/.

Second mistake: mixing carrier-specific information in one working file. A multi-carrier agency can accidentally send one insurer data that belongs to another relationship. Fix it by keeping carrier names and official destinations in the human review path, while the AI file uses categories.

Third mistake: assuming a Read deny rule blocks every shell or external tool path. The official documentation treats permissions and sandboxing as separate layers. Fix it by combining deny rules, sandbox denyRead, sandbox denyWrite, and a policy that stops the workflow if sandboxing is unavailable.

Fourth mistake: testing the check with real claim data. Terminal history and screenshots can retain sensitive values. Use fictional claim IDs and fictional emails for both allow and deny tests.

Small ROI Measurement

Run the first two weeks on one workflow: missing-document email drafts. Before the change, record draft minutes, review minutes, rework count, and corrections to recipient or document names across five cases. After the change, record the same fields and add pre-input stops.

Use cases × (draft minutes + review minutes + rework minutes) next to pre-input stops. If drafts get faster but review returns increase, the workflow is still too loose. Track speed and prevented mistakes together: carrier-name mixups, policy numbers left in files, medical details in the AI copy, and wrong-recipient warnings.

Do this before tying the workflow to lead volume or advertising. In claim intake, response speed and preventing prohibited disclosure need to be measured on the same sheet.

Frequently Asked Questions

Q. Can we send the file to Claude Code after removing policy numbers?

No. Also check names, addresses, phone numbers, emails, VINs, counterparties, medical documents, diagnoses, employers, and rare accident details. A person must check whether combined values still identify the policyholder.

Q. Are Claude Code permissions enough?

Do not treat them as enough by themselves. Permissions create tool boundaries; sandboxing, OS controls, and folder operations add another layer. Test denial with fictional data before using the workflow.

Q. What if we want a medical certificate summarized?

This workflow does not put medical certificate text in the AI copy. If the agency wants that process, a responsible person should review contract, consent, purpose, provider role, and internal rules first.

Q. Should Claude Code decide carrier rules?

No. Claude Code prepares review fields and missing-document categories. Staff confirm the official carrier destination and scope from original material.

Training and Consultation

For an insurance agency, a settings file alone is not enough. Decide who stores originals, who creates redacted copies, who approves email, who submits to carriers, and who checks deletion dates. Even when one person performs several roles, the review boxes should remain separate.

Training and consultation can map claim intake CSVs, emails, attachments, carrier channels, permissions, pre-input checks, and approval sheets without sharing real policy or medical documents.

What Was Actually Tested

For this article, I confirmed that /images/hero/hero-056.webp exists under site/public/images/hero/hero-056.webp, checked the Claude Code permissions URL, sandboxing URL, FSA URL, PPC cloud notice URL, and PPC insurance-agency PDF URL. The JavaScript block uses only fictional arrays. No insurance-company API, customer database, email sending, or runtime test with real claim data was run.

The publication checks target slug insurance-agency-claim-intake-data-boundary-claude-code, frontmatter, internal links, external links, CTA, code fences, ten locale files, and the Qiita link. The first practical step is to create fictional claim-raw/ and claim-ai-work/ folders and verify that originals are denied before any real claim data is handled.