Data Encryption & Security
Workspace-scoped AES encryption for text content, Azure Blob Storage for binary files, and Azure Key Vault for key isolation — encryption layered across the full pipeline
Overview
Instafill.ai encrypts data at two distinct layers. Text content — source documents, profile text, form fill inputs — is encrypted at the application layer using workspace-scoped AES encryption. Encryption keys are workspace-scoped: a key derived for one workspace cannot decrypt text from another, and scope restrictions are enforced before any decryption call. Binary files — uploaded PDFs, filled output files, batch imports — are stored in Azure Blob Storage with storage-layer encryption; the key material for these files lives in Azure Key Vault and is never embedded in application code.
All data in transit uses TLS 1.3. Passwords are hashed using an adaptive algorithm — they are never stored in plaintext or reversible form. JWT tokens that authenticate requests carry workspace claims and are validated by shared middleware across all service layers, so no cross-workspace data access is possible.
Key Capabilities
- Text Source Encryption: Source text is encrypted with workspace-scoped keys before storage — a different workspace's key cannot decrypt it
- Scope Restriction: Decryption is enforced with workspace scope — cross-session and cross-workspace decryption is blocked at the application layer
- Azure Blob Storage: Binary files (PDFs, source documents, filled outputs) stored in Azure Blob Storage with storage-layer encryption
- Azure Key Vault: Key material isolated in Azure Key Vault — not stored in application code or database
- TLS 1.3 in Transit: All API, webhook, and email communications use TLS 1.3
- Password Hashing: One-way adaptive hashing with per-password salt — passwords are never stored in plaintext
- Workspace Isolation: All data scoped to workspace; JWT claims enforced by middleware across all service layers
- GDPR Erasure: Right to erasure propagates across sessions, sources, forms, and profiles within the workspace scope
How It Works
Text Content Encryption
Source documents submitted as text, profile text fields, and form fill inputs are encrypted before persistence:
Encrypt on Ingest: Text content is encrypted before being written to the database. The cipher is initialized with a workspace-scoped key derived from Azure Key Vault key material.
Scope Restriction: The encryption envelope includes workspace identity as associated data. Decryption verifies scope before returning plaintext — a ciphertext produced for workspace A cannot be decrypted in the context of workspace B.
Decrypt on Use: During the autofill pipeline, source text is decrypted in memory for the duration of the fill run and is not re-persisted in plaintext.
File Storage Encryption
Binary files follow a separate path:
Upload and Download: All blob uploads and downloads pass through service layer code. Files are stored in Azure Blob Storage; Azure's storage-layer encryption (managed by Azure Key Vault) is applied transparently.
Both Service Layers: Form template uploads, filled PDF retrieval, and batch file handling all use the same Azure Blob Storage backend regardless of which service layer initiates the operation.
Key Material: Azure Key Vault holds the key references. Application code contains only the vault URI and a managed identity credential — key bytes never appear in source code or configuration files.
Encryption in Transit
All connections use TLS 1.3. This applies to the REST API, webhook deliveries, email integration (SMTP/IMAP), and inter-service communication. HTTP requests are redirected to HTTPS at the load balancer level.
Password Security
User passwords are hashed on registration and login using an adaptive one-way hashing algorithm. Instafill.ai cannot reverse or read stored passwords. Account recovery uses verified email reset flows, not password retrieval.
Use Cases
Healthcare providers store patient intake forms and source documents where HIPAA requires encryption at rest and in transit — application-layer encryption satisfies the technical safeguard requirement while Azure Blob + Key Vault satisfies the infrastructure-layer requirement. Law firms handling immigration filings (I-485, I-130) rely on workspace isolation to ensure client A's documents cannot be accessed from client B's workspace. European enterprises reference TLS 1.3 and Azure Key Vault configuration in GDPR Data Processing Agreements.
Benefits
- Defense in Depth: Application-layer encryption + storage-layer encryption (Azure Blob) + key isolation (Azure Key Vault)
- Workspace Hard Boundary: Workspace scope restriction makes cross-workspace decryption architecturally impossible, not just access-controlled
- No Key Material in Code: Azure Key Vault means rotating or revoking keys doesn't require code deploys
- Password Non-Retrievability: One-way password hashing means compromised database rows cannot yield user passwords
- Compliance Architecture: Application-layer + infrastructure-layer encryption maps directly to HIPAA Technical Safeguard and GDPR Article 32 documentation requirements
Security & Privacy
All data is workspace-scoped and protected by JWT authentication middleware across all service layers.
Encryption Stack:
- Text Content: Workspace-scoped AES encryption applied at the application layer before storage
- Binary Files: Azure Blob Storage with Azure Key Vault-managed keys
- Passwords: Adaptive one-way hashing with per-password salt
- Transit: TLS 1.3 for all endpoints
Key Management:
- Key material in Azure Key Vault — not in application config or source code
- Workspace-scoped keys prevent cross-tenant decryption at the application layer
- Workspace identity is embedded in encryption scope and verified on every decrypt call
Compliance:
- GDPR: Erasure propagates across all data types within the workspace; TLS 1.3 and Azure Key Vault referenced in DPAs
- HIPAA: Application-layer + infrastructure-layer encryption satisfies Technical Safeguard § 164.312(a)(2)(iv) and § 164.312(e)(2)(ii)
Common Questions
What encrypts text content vs. file content?
Two separate mechanisms handle these:
Text Content (source document text, profile text fields, form fill inputs):
- Encrypted using workspace-scoped AES encryption before storage
- Keys are workspace-scoped; key material lives in Azure Key Vault
- Scope restriction enforced on every decrypt call — cross-workspace decryption is blocked at the application layer
Binary Files (uploaded PDFs, filled output PDFs, batch import files):
- Stored in Azure Blob Storage
- Azure Blob Storage applies storage-layer encryption using keys managed in Azure Key Vault
- Application code holds only the vault URI and a managed identity credential — no key bytes in code
The two layers are complementary: text gets application-layer encryption (allowing scope-restriction logic); files get infrastructure-layer encryption (simpler, handled by Azure).
Can Instafill.ai read my source document text?
Operationally, no — for two reasons:
Encrypted at Rest: Text is stored encrypted with a workspace-scoped key. Accessing the ciphertext without the correct workspace key context yields nothing usable.
Workspace Scope Enforcement: Even within the application, decryption requires the correct workspace context. A support engineer with database read access would see ciphertext; decrypting it requires Key Vault access scoped to that specific workspace.
In practice, source text is decrypted in memory only during an active fill pipeline run and is not logged or re-persisted in plaintext.
Exception: If you contact support with a specific fill issue, a support engineer with explicit workspace access and audit-logged Key Vault authorization could decrypt specific records. All such access is logged.
What happens to encryption when I delete data?
Deletion follows Instafill.ai's standard lifecycle:
Standard Deletion:
- Data moves to a 30-day soft-delete trash period
- After 30 days, storage records and blob references are permanently deleted
- Azure Blob deletion removes the ciphertext; Key Vault key references can be revoked separately for crypto-shredding
GDPR Erasure Requests:
- Right-to-erasure propagates across all data types within the workspace: sessions, sources, forms, profiles
- Both the encrypted ciphertext (database/blob) and associated key references are eligible for deletion
- Erasure is scoped to
workspaceId— deleting one workspace does not affect another
Stateless Mode (session-level):
- Files and text sources are deleted immediately on session completion
- No 30-day trash period — designed for workflows where source data must not persist
Is encryption enabled by default or do I need to configure it?
Encryption is always on — no configuration required:
- Text content: Text encryption is applied unconditionally before any source text is written to storage. There is no code path that persists unencrypted source text.
- Files: Azure Blob Storage encryption is a platform-level default — all writes are encrypted regardless of application-level settings.
- Transit: TLS 1.3 is enforced at the load balancer; HTTP connections are redirected to HTTPS before reaching application code.
- Passwords: Password hashing is applied on every registration and login — passwords never touch the database in plaintext.