Encryption, retention, and data lifecycle

Data Handling

This page describes how 9thSense handles document data from upload through deletion.

Encryption

At rest

All data stored by 9thSense is encrypted at rest using AES-256:

  • Uploaded documents and their binary content
  • Extracted fields and structured output
  • Embeddings (vector representations for semantic search)
  • Case records, messages, and metadata

Encryption is applied at the storage layer. The database and object store both encrypt data before writing to disk.

In transit

All data transmitted to and from the 9thSense API is encrypted with TLS. Unencrypted HTTP connections are not accepted.

This applies to:

  • Client-to-API traffic
  • Webhook deliveries from the platform to your endpoints

For webhook deliveries, 9thSense signs the payload with an HMAC-SHA256 signature using a secret you provide. Your endpoint can verify the signature to confirm the request originated from 9thSense and was not tampered with in transit.

Document lifecycle

Upload → OCR/Processing → Structured Storage → Configurable Deletion

1. Upload

Documents are accepted as file uploads or base64-encoded content. Upon receipt, the raw file is stored in object storage and a processing job is enqueued.

2. Processing

The document is processed by the configured pipeline — OCR, field extraction, classification, validation. All AI inference runs on your self-hosted runtime by default. Extracted fields are stored in structured form alongside the original file.

3. Storage

After processing, both the original document and its extracted data are retained according to your configured retention policy. Documents are associated with a case and a tenant, and are never accessible across tenant boundaries.

4. Deletion

Documents and associated data can be deleted via the API. Deletion is permanent — data is removed from object storage and the database. Retention policies can be configured to trigger automatic deletion after a set period.

PII handling

Field masking

Validation supports configurable masking rules. Fields marked as sensitive in your document type definition are masked before the output is returned or stored. Masking is applied inside the platform, before data reaches your application.

Aadhaar masking

For Aadhaar numbers specifically, 9thSense applies mandatory masking in line with UIDAI guidelines. Only the last 4 digits of an Aadhaar number are returned in extraction output. The full number is never stored or transmitted after masking is applied.

Example extraction output for an Aadhaar document:

{
  "aadhaar_number": "XXXX XXXX 5678",
  "name": "Priya Sharma",
  "date_of_birth": "1990-05-15"
}

Redact tool

A dedicated redact tool is available for masking arbitrary PII in text before storage or onward transmission. It can be configured to detect and mask names, dates, financial identifiers, and other sensitive patterns.

Self-hosted AI and data residency

When using the default self-hosted AI configuration, document content submitted for analysis — text, images, extracted fields — is processed entirely within your infrastructure. It is not sent to any external AI provider.

This means:

  • Document content never leaves your network boundary for AI processing
  • You retain full visibility and control over where inference happens
  • Compliance with data residency requirements (such as data staying within India) is achievable through self-hosted deployment

Cloud AI fallback is available as an opt-in feature for individual tool invocations via the allow_cloud parameter. When this flag is not set, the platform fails closed if the self-hosted runtime is unavailable, rather than automatically routing to a cloud provider.

Data access

Access to stored documents and case data requires a valid API key with the appropriate scope. All access is logged to the audit trail. See Security Overview for details on authentication and RBAC.

PreviousOverviewNextCompliance