Is AI Safe for M&A Due Diligence?
Deal documents are among the most sensitive material a company handles, and caution about putting them through any external system is the correct instinct. This page states plainly what to check before uploading anything to an AI due diligence tool - training data use, PII handling, encryption key ownership, tenant isolation, access control and audit logging - using Anweshna's own architecture as the working example throughout.
The question worth asking before uploading anything
Deal documents are among the most sensitive material a company handles — unreleased financials, litigation strategy, customer lists, the fact that a transaction is happening at all. The instinct to be cautious about putting that through any external system, AI or otherwise, is correct. This page states plainly what to check and what a properly built system actually does, using Anweshna's own architecture as the working example.
Is your data used to train the model?
This is the threshold question, and the answer depends entirely on which interface is used. Consumer chat interfaces frequently reserve the right to use conversation content for training unless a user opts out. Enterprise API terms are structured differently: inputs and outputs are typically excluded from training by contract, not merely by a settings toggle a client has to remember to set.
Anweshna processes documents through Anthropic's enterprise API, under terms that prohibit using client inputs to train models. This is a contractual guarantee, not a configurable preference — there is no setting to accidentally leave on.
What reaches the model in the first place
The strongest privacy control is not sending sensitive data to the model at all. Before any extracted text reaches the AI, Anweshna strips personally identifiable information — Social Security numbers, card numbers, email addresses, phone numbers — from the document. The risk-relevant content survives; the identifiers that would let a document be tied to a specific individual do not.
This matters independently of the training question, because it also limits exposure in the event of any downstream logging or debugging on the model provider's side, which is outside any client's direct control.
Encryption, and who holds the key
"Encrypted at rest" is table stakes and tells you little on its own — the question that matters is whether every client shares a key or each has its own. A shared key means a single compromise exposes every client's data; a per-client key limits a compromise to one engagement.
Anweshna derives a unique encryption key for every client using HKDF key derivation, salted with the client's own identifier, and encrypts extracted document text and analysis findings with Fernet symmetric encryption under that key. A breach of one client's key material does not expose another's data, because there is no shared key to compromise.
Isolation below the application layer
Most multi-tenant systems isolate clients through application logic — a query filtered by WHERE client_id = .... That works until a bug in that logic ships, and application-layer filtering is exactly the kind of code that accumulates bugs as a system grows. The question worth asking any vendor is what the second, independent layer is.
Anweshna enforces isolation twice, independently. Application-layer filtering is the first layer. Postgres row-level security is the second: the database itself refuses to return another client's rows to a restricted, non-superuser application role, regardless of what the application code asks for. A bug in the first layer does not become a cross-client data exposure, because the second layer does not depend on the first being correct.
Who can see what
Role-based access should map to how a deal team actually works, not to a flat all-or-nothing permission. Anweshna's roles — Owner, Analyst, Viewer, and Clean Team — control upload, analysis and download rights separately, and competitively sensitive material can be held in a clean room (the Clean Rooms add-on) — a separate database schema with its own key, per-room roles, and releases to the deal team only after a lead or counsel approves them — relevant where the buyer is a competitor and that material needs to stay outside the broader deal team's view.
The audit trail
Every access, download and change should be attributable after the fact — not as a compliance afterthought, but because a deal team needs to be able to answer "who touched this document and when" during and after the process. Anweshna logs every such action to an append-only audit trail, and every report download carries a provenance watermark identifying who downloaded it, their role, and when.
Certifications & Roadmap
Our security program is designed around the SOC 2 and ISO 27001 control frameworks. We have not yet completed formal third-party certification — the roadmap below states plainly where that work stands rather than implying more than we can evidence.
- Internal security review: Complete. The platform has been reviewed at source level against the OWASP API Top 10, GDPR, the India DPDP Act, and SOC 2 / ISO 27001 control expectations. This is an engineering review, not an independent audit.
- SOC 2: Preparing for a readiness assessment. No audit period has begun and no report is available yet.
- ISO 27001 & ISO 42001: Control implementation in progress. Formal certification not yet started.
- Penetration testing: A third-party penetration test is planned ahead of general availability. We will make a letter of attestation available once one exists.
If your evaluation needs certification artifacts we do not yet hold, talk to us about timelines and interim assurances.
Data Residency & Subprocessors
We process data exclusively in top-tier cloud regions with strict service level agreements.
- Data Residency: Database hosted on Supabase (United States — us-east-1, N. Virginia). Application hosted on FastAPIcloud (us-east-1).
- Breach Notification SLA: We commit to notifying affected customers within 48 hours of discovering a confirmed security breach, as enshrined in our standard DPA.
Authorised Subprocessors
| Subprocessor | Service | Location |
|---|---|---|
| Anthropic | LLM Inference (Zero Data Retention) | USA |
| Supabase | Database & Auth (Row-Level Security) | USA (us-east-1) |
| FastAPIcloud | Application Hosting | USA |
| Paddle | Payment Processing | UK / USA |
Implemented Controls Mapping
We align our security practices with the 15 core principles required for institutional due diligence vendors:
- Data Minimization: PII scrubbed pre-inference.
- Tenant Isolation: Row-Level Security enforced at the database layer.
- Encryption: HKDF per-client key derivation; AES-256 at rest, TLS 1.3 in transit.
- Access Control: Granular RBAC, plus clean rooms with per-room roles, human-approved releases and a hash-chained audit log.
- Model Sovereignty: Contractual zero-training guarantees via Anthropic API.
- Provenance Tracking: Cryptographic document watermarking and append-only audit logs.
Seven questions to ask any AI due diligence vendor
- Is my data used to train your models, or the underlying model provider's? Ask for the contractual basis, not just a verbal assurance.
- Are personal identifiers removed before text reaches the model?
- Is data encrypted at rest under a key unique to my account, or a key shared across all clients?
- Is tenant isolation enforced below the application layer? If the answer is only "we filter by client ID in our queries," that is one layer, not two.
- What is the retention and deletion policy, and is deletion actually irreversible?
- Is every access logged immutably, and can I get that log?
- Can access be restricted by role within my own team, including a walled configuration for competitively sensitive deals?
A vendor with confident, specific answers to all seven has thought about this properly. A vendor whose answer to any of them is "we will look into that" has not, regardless of how the product otherwise looks.
Frequently asked questions
Is it safe to upload confidential M&A documents to an AI due diligence tool?
It depends on the specific system, not on AI as a category. Check whether documents are used to train models (contractually, not just by setting), whether personal identifiers are stripped before text reaches the model, whether encryption uses a key unique to your account, whether tenant isolation is enforced below the application layer, and whether access is logged immutably. A vendor with clear, specific answers to all of these has built the system properly.
Are documents used to train AI models when using Anweshna?
No. Anweshna processes documents through Anthropic's enterprise API, under terms that contractually prohibit using client inputs to train models. This is a contractual guarantee built into the processing agreement, not a setting that has to be configured or remembered.
How does per-client encryption actually protect data?
Anweshna derives a unique encryption key for every client using HKDF key derivation, and encrypts that client's extracted document text and findings with Fernet symmetric encryption under that key. Because there is no shared key across clients, a compromise of one client's key material does not expose any other client's data.
What does row-level security add beyond normal application permissions?
Most systems isolate tenants only through application code - a query filtered by client ID. That protection fails if a bug in that code ships. Row-level security enforces isolation a second time, independently, inside the database itself: a restricted database role cannot retrieve another client's rows regardless of what the application code requests, so a single application-layer bug does not become a cross-client data exposure.