Skip to main content

​
Security Philosophy

AVA’s security model is built on a fundamental principle: delegated user permissions. AVA never operates with elevated privileges or service accounts. Instead, it uses your Microsoft Entra ID identity and accesses only what you can access.
Zero Trust by Design: Every action AVA performs is authenticated through your Entra ID identity with delegated permissions. No backdoors, no elevated access, no shadow IT.

​
Identity & Access Management

​
Microsoft Entra ID Integration

AVA leverages your existing Microsoft Entra ID (formerly Azure AD) for all authentication and authorization:
  • User Authentication
  • Delegated Permissions
  • Application Permissions
Single Sign-On (SSO):
  • Users sign in with their corporate Microsoft account
  • Multi-factor authentication (MFA) enforced if configured in Entra ID
  • Conditional Access policies honored
  • Session management controlled by Entra ID policies
No Separate Credentials:
  • No passwords stored in AVA
  • No separate user database to manage
  • User provisioning/deprovisioning managed via Entra ID

​
Data Security

​
Encryption

At Rest

Azure Storage Encryption:
  • All data encrypted with AES-256
  • PostgreSQL encrypted at rest
  • Encryption keys managed by Azure Key Vault
  • FIPS 140-2 validated encryption modules

In Transit

TLS 1.3 Everywhere:
  • All API communication encrypted
  • Frontend ↔ Backend: TLS 1.3
  • Backend ↔ Database: TLS 1.3
  • MCP Servers ↔ External APIs: TLS 1.3

Key Management

Azure Key Vault:
  • All secrets stored in Key Vault
  • No hardcoded credentials
  • Automatic secret rotation
  • Access logged and auditable

Data Residency

Your Tenant Only:
  • Data never leaves your Azure tenant
  • No cross-tenant data sharing
  • Compliance with data residency requirements
  • Full control over data location

​
Data Protection

What AVA Stores:
  • User session metadata (who logged in, when)
  • Conversation history (chat messages, task definitions)
  • Knowledge Search corpora metadata and embeddings
  • User preferences and custom instructions
  • Audit logs
What AVA Does NOT Store:
  • User passwords (handled by Entra ID)
  • Raw email or calendar data (fetched on-demand via delegated permissions)
  • Salesforce/Jira/GitHub data (fetched on-demand via MCP servers)
  • Any data AVA doesn’t need to function
Data Retention:
  • Conversation history: Configurable (default 90 days, can be set to unlimited)
  • Knowledge Search embeddings: Until corpus is deleted
  • Audit logs: Configurable (default 365 days, can export to Azure Storage)
  • Session tokens: Expire per Entra ID policy (typically 1-24 hours)

​
Network Security

​
Architecture

Internet → Azure Front Door (DDoS Protection)
         ↓
    App Service (Frontend - Public)
         ↓ (TLS)
    Container Apps (Backend - Private VNet)
         ↓ (Private Endpoint)
    PostgreSQL (Database - Private VNet)
         ↓ (Managed Identity)
    Key Vault (Secrets - Private VNet)

​
Network Isolation

  • PostgreSQL: Accessible only within VNet, no public endpoint
  • Key Vault: Private endpoint for secret access
  • Container Apps: Backend services in private VNet subnet
  • No Direct Database Access: Database not exposed to internet
  • All backend services deployed in customer’s VNet
  • Network Security Groups (NSGs) control traffic
  • Azure Firewall optional for additional control
  • VNet peering with customer networks supported
  • Azure DDoS Protection Standard enabled
  • Automatic mitigation of layer 3/4 attacks
  • Rate limiting at application layer
  • WAF rules for common attack patterns
Inbound:
  • Users → Azure Front Door → App Service (HTTPS only)
  • App Service → Container Apps (internal HTTPS)
Outbound (from backend):
  • Container Apps → Microsoft Graph API (via delegated permissions)
  • Container Apps → MCP Servers (internal, same VNet)
  • MCP Servers → External APIs (Salesforce, Jira, etc. via HTTPS)
  • All outbound traffic logged

​
Managed Identity & RBAC

​
How AVA Backend Accesses Resources

AVA backend services use Azure Managed Identity instead of credentials:
1

Identity Assignment

Each Container App is assigned a system-managed identity automatically by Azure
2

Role Assignment

The managed identity is granted specific Azure RBAC roles:
  • Key Vault Secrets User: Read secrets from Key Vault
  • PostgreSQL Database User: Connect to database
  • Storage Blob Data Contributor: (if using Azure Storage for exports)
3

Authentication

When backend needs to access a resource:
  1. Requests access token from Azure Instance Metadata Service
  2. Azure validates the managed identity
  3. Returns short-lived access token
  4. Backend uses token to access resource
4

No Credentials

Benefits:
  • No passwords or keys in configuration
  • Automatic credential rotation
  • Audit trail via Azure AD logs
  • Cannot be compromised or leaked

​
User-Level RBAC

Within AVA, access is controlled by:
  1. Microsoft 365 Permissions: Users see only their own email, calendar, files
  2. Salesforce Permissions: Delegated access respects Salesforce sharing rules
  3. Jira Permissions: Users see only projects/issues they have access to
  4. GitHub Permissions: Repository access follows GitHub permissions
  5. Knowledge Search: Users can only search corpora they’re granted access to
No Shadow RBAC: AVA doesn’t create a separate permission system. It uses your existing access controls in each system.

​
Audit & Compliance

​
Audit Logging

All actions in AVA are logged with:
  • Who: User identity (UPN from Entra ID)
  • What: Action performed (query, export, corpus access, etc.)
  • When: Timestamp (UTC)
  • Where: Source IP, device info
  • Result: Success/failure, error codes
Log Destinations:
  • Azure Monitor / Application Insights
  • Azure Storage (for long-term retention)
  • Azure Sentinel (for SIEM integration)
  • Export to customer’s log management system

​
Compliance Frameworks

AVA supports compliance with:

SOC 2 Type II

Security, availability, confidentiality controls

ISO 27001

Information security management system

GDPR

EU data protection and privacy

HIPAA

Healthcare data security (via Azure compliance)

FedRAMP

Federal government (via Azure Government)

PCI DSS

Payment card data security (via Azure)
Shared Responsibility Model: Azure provides infrastructure compliance (physical security, network, encryption). AVA provides application-level compliance (access controls, audit logs, data handling). Customer is responsible for user access management and data classification.

​
Data Subject Rights (GDPR)

AVA supports GDPR data subject rights:
  • Right to Access: Export all user data via admin API
  • Right to Erasure: Delete user and all associated data
  • Right to Portability: Export data in machine-readable format (JSON)
  • Right to Rectification: Users can edit/delete their conversations
  • Data Retention Policies: Configurable retention periods

​
Security Best Practices

​
For Administrators

Configure in Entra ID:
  • Require MFA for all users accessing AVA
  • Use Conditional Access policies
  • Consider hardware tokens for privileged users
  • Audit Enterprise Application permissions quarterly
  • Review user access to AVA
  • Check MCP server configurations
  • Validate Knowledge Search corpus permissions
  • Set up alerts for suspicious activity
  • Review failed login attempts
  • Monitor data export events
  • Check for unusual query patterns
  • Only create corpora for documents users should access
  • Don’t include sensitive documents unless necessary
  • Use corpus-level access controls
  • Regularly review corpus contents
Entra ID Conditional Access policies apply to AVA:
  • Require MFA from untrusted locations
  • Block legacy authentication
  • Require compliant devices
  • Restrict access by IP range

​
For End Users

  • AVA stores conversation history
  • Don’t paste passwords, API keys, or secrets
  • Be mindful of PHI, PII, financial data
  • Use Knowledge Search for sensitive documents (more controlled)
  • Review PowerPoint/Word exports before sharing externally
  • Exports may contain aggregated data from multiple sources
  • Check for sensitive information before sending
  • Custom instructions are stored in database
  • Don’t include sensitive information
  • Keep instructions professional and task-focused
  • Contact your IT admin if you see unusual behavior
  • Report suspected unauthorized access
  • Security team email: avasupport@datarm.ai

​
Incident Response

​
Security Incident Handling

1

Detection

  • Azure Monitor alerts trigger automatically
  • Security Operations Center (SOC) monitoring
  • User reports via support channel
2

Analysis

  • Review audit logs and telemetry
  • Determine scope and impact
  • Identify affected users/data
3

Containment

  • Disable compromised accounts (via Entra ID)
  • Revoke access tokens
  • Isolate affected Container Apps if needed
  • Block IP addresses if attack detected
4

Remediation

  • Patch vulnerabilities
  • Reset credentials if needed
  • Restore from backup if data corruption
  • Update security configurations
5

Communication

  • Notify affected users within 72 hours (GDPR)
  • Report to management/board if major incident
  • Document incident in compliance logs
  • Post-mortem and lessons learned

​
Breach Notification

In the unlikely event of a data breach:
  • Timeline: Notification within 72 hours of discovery (GDPR requirement)
  • Channels: Email to admin contacts, in-app notification
  • Information Provided: What data affected, timeline, remediation steps
  • Support: Dedicated incident support team assigned

​
Security Certifications

AVA maintains the following security certifications:
  • SOC 2 Type II: Annual audit by independent CPA firm
  • ISO 27001: Information Security Management System certification
  • Penetration Testing: Quarterly by third-party security firm
  • Vulnerability Scanning: Continuous automated scanning
  • Responsible Disclosure Program: security@datarm.ai
Request Security Documentation: Contact avasupport@datarm.ai to receive:
  • SOC 2 Type II report (requires NDA)
  • ISO 27001 certificate
  • Penetration test summary
  • Security whitepaper

​
Common Security Questions

No. AVA uses delegated permissions. It can only access what you can access with your Microsoft work account.
No. AVA fetches email data on-demand via Microsoft Graph API using your permissions. Only the AI’s response is stored in conversation history.
No by default. Conversations are private to each user. However, admins can enable organization-wide audit logging to comply with legal/regulatory requirements.
AVA sessions are tied to your Entra ID authentication. If you report device theft, IT admin can:
  • Revoke device access in Entra ID
  • Force sign-out from all sessions
  • Your conversations remain secure in Azure
Key Differences:
  • AVA data never leaves your Azure tenant
  • Uses your identity and permissions
  • No training on your data
  • Enterprise-grade security and compliance
  • Audit logs and governance controls
No. AVA uses AI models (GPT-4, Claude, etc.) but your data is never used to train or improve these models. All prompts are sent with opt-out flags to prevent training.

​
Next Steps

Architecture Overview

Understand AVA deployment architecture

How It Works

Technical flow and MCP integration

Audit Logs

Monitor and review security events

Contact Security Team

Questions about security? Email us