Deploy and security

Runs in your account. Nothing leaves unless you route it out.

This page is for the platform and security team evaluating Claimwell. It says what runs where, what data moves between which components, what can leave your network and under whose control, who operates what, and how the package is deployed. If a question is not answered here, ask it and we will add the answer.

The short version

Your cloud account, your VPC

Deployed from a Terraform module into an account you own. Private subnets, one TLS ingress for the workbench, no inbound access from us.

Models on your GPUs

Open-weight models served by vLLM inside the VPC. Model traffic never leaves your network unless you enable a frontier route through your own provider account.

Operated by Claimwell, inside your perimeter

A named Claimwell team runs the agents: monitoring, evaluation on every release, incidents, model updates, statutory parameters. They reach the system through your identity provider with scoped roles, and every action they take is in your audit log. No data is exported to us and your claims are never used to train anything.

Append-only audit

Every constraint check, model call, write, and human signature, with inputs and versions. Not editable through the API by anyone, including us.

Least-privilege integration

One service identity per adapter, scoped to the endpoints that adapter needs. The Mail Room cannot write status. Nothing can write a decision without a human record.

Portable

Every managed service has an open equivalent in the compose stack. Leaving a cloud is a Terraform module, not a migration project.

Data flow

What moves where

Everything below runs inside your VPC. The only two arrows that can cross its boundary are marked, and both are off by default.

Inbound channels · your systems

Scan batches, fax inbox, mailbox, portal uploads, employer feeds, call notes. Read by the Mail Room from drop points you control. Originals stay where they are.

Document pipeline · in VPC

Render, OCR, classify, extract. Page images and extraction payloads stored in your object store with your keys.

Model serving · in VPC

vLLM on your GPU nodes. Prompts and outputs logged to your audit store. Optional egress 1: a per-task-class route to Amazon Bedrock, Vertex AI, or Azure OpenAI through your own provider account, visible in the trace.

Workflow runtime, agents, deterministic services · in VPC

Temporal with Postgres persistence. One workflow per claim. Benefit engine, clock service, constraint checker. No external calls.

Claims-admin adapter

Reads and writes to your system of record through its API with a scoped service identity. Constraint checker in front of every write.

HRIS, plan, guidelines

Read-only adapters to your census feed, plan repository, and licensed guideline table.

Payments, correspondence

Write adapters to your payment rail and correspondence engine. Only from an approved benefit period or a recorded decision.

Workbench

TLS ingress, your identity provider via OIDC or SAML. Examiner, nurse, and strategy owner roles. Optional egress 2: none. The workbench serves your users only.

Object store and audit store · in VPC

S3-compatible, your buckets, your KMS keys, your retention policy. Audit store is append-only and versioned.

Deployment

What the package contains and how it is deployed

ConcernAWSGoogle CloudPortability rule
infrastructure as codeTerraform module, your account, your state backendTerraform moduleone module per cloud; nothing cloud-specific outside it
computeEC2 or ECS for the platform; one GPU instance for model servingCompute Engine or GKE; one GPU VMcontainers everywhere; compose stack is the reference
object storeS3 with your KMS keysGCS through the S3 interop APIS3-compatible API only; MinIO in development
databasePostgres, container or RDSPostgres, container or Cloud SQLplain Postgres, no extensions you cannot run elsewhere
secretsSSM Parameter Store or Secrets ManagerSecret Managerone secrets interface, adapter per cloud
ingressload balancer with TLS, your certificateload balancer with TLSany ingress
identityyour IdP via OIDC or SAMLyour IdPno local accounts in production; Claimwell operators are users in your IdP with an operator role
model servingvLLM on a g6-class instance; Bedrock optionalvLLM on a GPU VM; Vertex AI optionalOpenAI-compatible endpoint; swap models by config
observabilityyour CloudWatch, or the bundled Prometheus and Grafanayour Cloud Monitoring, or bundledOpenTelemetry out; Claimwell operators read it in your account, nothing is exported
imagespulled from a registry you mirror; signed; SBOM published per releaseno pull from the internet at runtime

Azure and on-premises Kubernetes modules are in progress. The Helm chart targets any conformant cluster with an S3-compatible store and a Postgres.

Controls

The questions a security review asks, answered

Short answers below. Longer ones, with evidence, in the review packet we provide during evaluation.

Who can access claimant data?
Your users, through your identity provider, with the three workbench roles. Service identities per adapter, scoped to their endpoints. Claimwell operators, through the same identity provider, with an operator role that can read traces, run evaluations, and manage deployments but cannot sign decisions or change strategy. Every operator action is in your audit log, and you can revoke the role at any time.
What leaves the VPC?
By default, nothing. Two optional egress paths exist, both off until you enable them: a frontier-model route per task class through your own provider account, and outbound email, fax, or print through your correspondence system. Both are visible in the audit trail per call.
Is claimant data used to train or improve models?
No. Models are open-weight and served as-is. Any fine-tuning you choose to do happens in your account on your data and stays there. We never receive data from a deployment.
How is data encrypted?
TLS on every hop including inside the VPC. At rest, your object store and database encryption with your KMS keys. Secrets in your cloud's secrets service.
How is the audit trail protected?
Append-only store, versioned objects, no delete or update path through the API. Every record carries actor, action, before and after, rationale, citations, model and prompt version, strategy version, and constraint results.
What stops an agent from making a bad write?
The constraint checker runs in front of every write to your system of record and refuses anything that violates a cardinal rule, and the workflow runtime will not advance a guarded transition without the human signal. Neither consults a model. Every evaluation, pass or block, is logged.
How do updates reach us?
Signed container images and a versioned Terraform module, pulled into your registry on your schedule. Release notes include the SBOM and the model license check. Before any release reaches your claims it is replayed against the full scenario library, and the results are written to your audit store. A release that fails any constraint check does not ship.
What insurance does Claimwell carry?
Technology errors and omissions coverage, with the customer named as an additional insured, at limits set in the agreement. A certificate of insurance is provided during procurement and on each renewal. The four warranted rules on the Lifecycle Agents page are backed by this coverage.
What about retention and deletion?
Your buckets, your policies. The package includes a retention configuration for page images, extraction payloads, model logs, and audit records, each settable independently, with legal hold support.

Send us your security questionnaire

We'll return it with the data-flow diagram, the Terraform module, and the review packet.