Native Encryption & Security Architecture
Maintaining Data Sovereignty within the Microsoft 365 Trust Boundary
Classification: Public / Technical
1. Executive Summary: The “Resident” Advantage
The primary security failure of legacy Legal AI platforms is their dependency on synchronizing sensitive firm data to external Large Language Model (LLM) provider clouds. This architectural requirement expands attack surfaces, weakens data sovereignty, and complicates regulatory compliance.
Arivu.Legal eliminates this risk by deploying as a Native Resident Agent. All indexing, computation, and inference occur entirely within the client’s existing Microsoft 365 tenant. At no point is firm data exported, replicated, or processed outside the firm’s controlled environment.
As a result, law firms can adopt AI-driven legal intelligence without altering their existing ISO 27001, SOC 2, or internal risk postures, because Arivu.Legal operates fully inside the trust boundary they already govern.
2. Encryption Protocols & Data Residency
Arivu.Legal leverages Microsoft Azure’s native security primitives and the hardened Microsoft 365 infrastructure to protect data both at rest and in transit.
2.1 AES-256 Resident Encryption (Data at Rest)
All indexed legal content is stored within the firm’s dedicated Azure resources, scoped exclusively to its tenant.
- Encryption Standard: Advanced Encryption Standard (AES) with 256-bit keys.
- Key Management: Support for Customer-Managed Keys (CMK) via Azure Key Vault. Encryption keys are owned and controlled by the firm. Even Arivu.Legal administrators cannot access encrypted content without explicit, logged authorization from the firm’s IT leadership.
- Logical Isolation: Indexing is matter-centric. Data partitions are logically separated to prevent cross-matter visibility or contamination.
2.2 TLS 1.3 Secure Channels (Data in Transit)
All data exchanged between SharePoint, the Arivu Resident Agent, and end-user applications (Word, Outlook) is protected using Transport Layer Security (TLS) 1.3.
- Perfect Forward Secrecy (PFS): Compromise of a session key does not expose historical communications.
- Zero-Trust Connectivity: Every interaction requires a fresh OAuth 2.0 token, aligned with Microsoft’s Zero Trust model.
3. Identity & Access Governance: The Entra ID Handshake
Arivu.Legal does not maintain a separate user database. It is a permission-inheriting system.
3.1 Microsoft Entra ID Integration
Authentication and authorization are fully delegated to the firm’s Microsoft Entra ID.
- Inherited Permissions: Arivu mirrors SharePoint permissions exactly. If a user does not have access to a document or matter workspace, Arivu returns zero results from that location.
- MFA & Conditional Access: Existing Multi-Factor Authentication and Conditional Access policies automatically apply.
3.2 Microsoft Purview Alignment
Arivu.Legal respects Microsoft Purview governance controls.
- Sensitivity Labels: Labels such as “Highly Confidential” or “Attorney-Client Privileged” are enforced at query time.
- Data Loss Prevention (DLP): Content flagged for restricted handling is not processed or summarized.
4. The Verification Shield: Secure External Validation
To mitigate AI hallucinations without introducing new security risks, Arivu.Legal employs a controlled, one-way verification mechanism.
- Public Record Cross-Referencing: Legal reasoning can be validated against over 400 million public court records via the CourtListener API.
- Local Query Scrubbing: All Personally Identifiable Information (PII) and client-specific identifiers are removed before any outbound request.
- Anonymous Retrieval: Only generalized legal concepts are transmitted; no external system can infer firm, client, or matter context.
5. Compliance Posture Summary
| Requirement | Arivu.Legal Specification |
| Data Residency | 100% within the firm’s Microsoft Azure tenant |
| Audit Logging | Full integration with Microsoft Purview Audit Logs |
| Vulnerability Management | Continuous monitoring via Microsoft Defender for Cloud |
| Third-Party Data Exposure | None. No external LLM training on firm data |
6. Threat Model Comparison: Resident vs. Sync-to-Cloud Legal AI
| Threat Vector | Legacy Sync-to-Cloud AI | Arivu.Legal Resident Agent |
| Data Egress | Continuous export to third-party clouds | No data leaves the tenant |
| Attack Surface | Expanded across vendor systems | Limited to Microsoft 365 perimeter |
| Key Ownership | Vendor-managed | Customer-managed (CMK) |
| Permission Enforcement | Replicated and delayed | Native, real-time inheritance |
| Audit Visibility | Fragmented | Unified in Purview |
| Breach Blast Radius | Cross-tenant possible | Tenant-contained |
7. Why Not “Private GPT”?
Private GPT deployments still expand risk by introducing new AI infrastructure, data duplication, shadow indexes, permission drift, and residual model exposure. Even when self-hosted, they require separate identity systems, additional patching, and opaque support access.
Arivu.Legal introduces no new AI infrastructure outside Microsoft 365, avoids data duplication, and inherits permissions in real time.
Private GPT shifts risk. Arivu.Legal removes it.
8. Vendor Access Model
Arivu.Legal follows a least-privilege, customer-controlled access philosophy.
- Default Access: No standing access for Arivu personnel.
- Support Access: Customer-initiated, time-bound, scope-restricted, and fully logged in Microsoft Purview.
- Encryption Boundary: Customer-managed keys prevent data decryption without explicit authorization.
- No Persistent Vendor Presence: No resident human operators or background agents outside Microsoft controls.
9. Conclusion
By utilizing a Native Resident Agent architecture, Arivu.Legal allows law firms to adopt state-of-the-art AI without expanding their threat landscape.
Arivu.Legal does not ask firms to trust a vendor.
It asks firms to trust their own Microsoft security stack.
Sensitive legal data remains private, auditable, and fully under firm control—inside the tenant, protected by the firm’s own security governance.