Claim data, from intake to decision.

Seven stages, each with the question a security review asks and the controls that answer it. Every safeguard below is evidenced in source code, a database migration, or an executable test, as found by an independent security review of the repository. The work that review found still to be proven is listed at the end.

Controls are mapped to NIST CSF 2.0, NIST AI RMF 1.0, NIST SP 800-37, and CIS Controls v8.1. A mapping says a safeguard is relevant to that framework area; it is not a certification. For how the model itself is constrained, see AI safety.

Govern

Who decides, and what evidence is required?

Humans make the decisions

The AI can organize evidence and suggest next steps. It cannot approve coverage, settle a claim, release a payment, or send a final communication.

So that a named, authorized person is accountable for every consequential decision.

Secure by design, not by checklist

Core access decisions are implemented as shared policy code and database rules rather than as procedures people have to remember.

So that the same security decision is applied the same way across users, claims, and services.

Every sensitive action is tracked

Sensitive reads and AI activity create attributable, content-minimized audit events that ordinary users cannot modify.

So that who accessed a claim, and what kind of action occurred, can be investigated without copying the claim into another log.

Identity and access

Can this person or service open this claim?

Claim-scoped authorization, checked twice

Being a Sentanis user is not enough to open a claim. The application checks the person, workspace, role, and explicit claim assignment, and then the database checks the boundary again with row-level security.

So that people see only the claims they were specifically permitted to handle.

Separate runtime identities

The web application and the background worker use separate database identities. Neither can inherit administrator powers or bypass row-level security.

So that a compromised service is limited to the small set of actions its job requires.

Enterprise sign-in

Enterprise single sign-on connects a carrier's identity provider to Sentanis sessions, and the provider's tokens are discarded after login.

So that carriers keep their existing identity controls while Sentanis keeps a bounded local session.

Rate-limited at the door

Per-client and process-wide rate limits throttle credential attacks before they reach application code. Sessions use signed, HttpOnly cookies, and membership is re-checked live on every request.

So that password guessing and revoked access fail early.

Intake and storage

How is sensitive material admitted and protected?

Encrypted at the field

Raw payloads, narratives, OCR text, model output, and review content are encrypted field by field with AES-256-GCM and a fresh random IV for every value.

So that a direct read of the database does not reveal the most sensitive claim content as plain text.

Tenant and segment guards

Every row carries its tenant key, and row-level policies plus consistency constraints stop a record from quietly pointing into another carrier's workspace.

So that cross-customer mixing is blocked by the database structure, not only by the application.

Intake retention is code, not policy

First-notice transcript retention is encoded in a database migration and enforced by an architecture test rather than existing only as a written rule.

So that sensitive intake content has a lifecycle that can be regression-tested.

AI and OCR routes

What leaves the boundary, and what can model input influence?

Bounded tools and claim context

The model chooses only from tools Sentanis defines. Every tool call re-checks authorization, and oversized results are replaced with an incomplete marker rather than trimmed.

So that a model cannot invent a database tool or use a valid one to read an unrelated claim.

Redaction on the way out and the way back

Known names and identifier patterns are replaced before selected claim context reaches an external model, and the output is redacted again before it is stored.

So that external processors receive less identifying information, and stored output gets a second privacy check.

Contained analysis

Can generated analysis escape its assigned packet?

A runner with no network

Generated analysis code receives a limited data packet in a separate environment with no network, no database credentials, a read-only root, and resource limits.

So that even unsafe generated code cannot reach the internet or fetch more claim data on its own.

Human decision

Can a reviewer reconstruct and challenge the conclusion?

Evidence-linked review gates

A final review records who decided, which claim and decision gate they reviewed, which evidence packet they saw, and which revision was current.

So that a regulator, a customer, or a court can reconstruct what the person knew when the decision was made.

Old work cannot overwrite new

Decision packets and completed jobs are tied to the worker's current lease. A timed-out or replaced worker cannot publish late results over newer work.

So that stale AI output cannot silently replace the evidence behind a current decision.

Operate and recover

Can Sentanis detect, explain, and recover from failure?

Attributable, content-free audit

Sensitive reads and AI or tool use create append-only records of the actor, action, claim reference, provider, and result, without copying prompts or claim content into the trail.

So that investigators can trace access without creating a second uncontrolled store of sensitive data.

Still being proven

The review distinguishes what the code shows from what only a running environment can show. These are the items on the second list. A carrier's own security team can ask for the evidence as it lands.

Deployed-environment proof that customer data and fabricated demo data never share an environment; the separation is designed and documented, and runtime evidence is being collected.
Provider account settings for every AI, OCR, storage, and logging route: processing region, retention, training use, and provider logging, tied to the actual account rather than assumed.
Backup, disk, and key protection for files in the deployed environment, and a completed restore exercise that sets the recovery commitments.
End-to-end deletion across derived records, files, caches, logs, backups, and provider-held copies, demonstrated on a synthetic case.
A reproducible build and software bill of materials for the running analysis service.
Negative tests in the deployed environment showing that a user, worker, or analysis process cannot impersonate another kind of actor.

Deployment target: customer-isolated AWS accounts with the carrier’s own keys, backups, and logs. The infrastructure definition exists; a live-data production environment is not yet operating, and no compliance certification is held.

Bring your security team to the demo.

We will walk the access model, the audit trail, and the analysis sandbox on a fictional file, and share the review evidence through a protected channel.

Request a demo