NexavateAI Trust Center
Security Overview
Technical documentation of the NexavateAI security architecture — encryption controls, access boundaries, OTP verification pipeline, audit logging, backup posture, and deployment options for security and procurement review.
Security Philosophy
How we approach platform security
NexavateAI applies defence-in-depth across the platform: encrypted transport, hashed verification credentials, role-restricted access, server-side secret management, and operational audit logging. Security controls are embedded in the application architecture rather than added as an afterthought.
Platform Architecture
Four-layer security model with clear trust boundaries
Platform request flow — data path overview
All external calls use TLS and API key authentication. Credentials are supplied via environment variables — never embedded in application source code. See Subprocessors for provider details.
Encryption
Data protection in transit across all layers
| Scope | Method | Status |
|---|---|---|
| Browser ↔ API | HTTPS / TLS 1.2+ for all public API endpoints | Available |
| API ↔ MongoDB Atlas | TLS-encrypted connection strings; Atlas enforces TLS on connections | Available |
| API ↔ OpenAI | HTTPS with API key authentication over TLS | Available |
| API ↔ Resend (email) | HTTPS with Bearer token authentication over TLS | Available |
| OTP storage | SHA-256 hash (with session + API key pepper); plain-text OTP never stored | Operational |
| Data at rest | MongoDB Atlas encryption at rest | Platform managed |
OTP Verification Pipeline
End-to-end security of the email OTP flow
Server-side generation
6-digit OTP generated server-side with cryptographically secure random source. Never generated client-side.
Hashed storage
OTP stored as SHA-256(email + otp + session_id + pepper). Plain-text OTP never written to disk or database.
10-minute expiry
OTP sessions expire automatically after 10 minutes. Expired OTPs are silently cleared.
Attempt limits
Maximum 5 verification attempts before session is invalidated. Maximum 3 resend requests per session.
Timing-safe comparison
OTP verification uses constant-time comparison (secrets.compare_digest) to prevent timing attacks.
Per-session isolation
Each booking creates an independent OTP session. Email changes start a fresh session; old session is cleared.
Access Control
How different user types interact with the platform
Access to different platform areas is separated by role. Public patient features are distinct from internal clinic tools.
Patient / Public
- View clinic information & services
- Use SYRA for booking assistance
- Book appointments (after OTP verification)
- Cancel own appointment (via booking ID)
Clinic staff (NEXA)
- View & manage all appointments
- Block/unblock time slots
- Access patient records
- Generate & manage prescriptions
Role-Based Access Matrix
| Feature / API | Anonymous public | Verified patient | Clinic staff (NEXA) | Admin |
|---|---|---|---|---|
| View clinic info | Yes | Yes | Yes | Yes |
| Send / verify OTP | Yes | Yes | Yes | Yes |
| Create appointment | ❌ | After OTP | Yes | Yes |
| View all appointments | ❌ | ❌ | Yes | Yes |
| Cancel / reschedule any | ❌ | Own only | Yes | Yes |
| Block slots | ❌ | ❌ | Yes | Yes |
| View prescriptions | ❌ | ❌ | Yes | Yes |
| Generate prescriptions | ❌ | ❌ | Authorized | Yes |
| System configuration | ❌ | ❌ | ❌ | Yes |
Secret Management
How API keys and credentials are stored
All sensitive credentials are configured via environment variables — never hardcoded in application source files or committed to version control.
| Secret type | Storage method | Rotation policy |
|---|---|---|
| Database URI | Environment variable (MONGO_URI) | On compromise or staff change |
| OpenAI API key | Environment variable (OPENAI_API_KEY) | Periodic / on compromise |
| Resend API key | Environment variable (RESEND_API_KEY) | Periodic / on compromise |
| Qdrant API key | Environment variable (QDRANT_API_KEY) | Periodic / on compromise |
| OTP hash pepper | Derived from API key; not separately stored | Rotates with API key |
.gitignore excludes .env from version control.
Audit Logging
Events captured for monitoring and incident response
| Event category | Logged data |
|---|---|
| OTP operations | Send requests (recipient, session), validation attempts, failures, delivery status from Resend API |
| Appointment actions | Create, cancel, reschedule events with timestamps |
| API errors | 4xx / 5xx responses, error type, endpoint — without exposing sensitive payload data |
| AI interactions | Intent classification, booking state transitions (no raw message content stored long-term) |
| Admin actions | Slot blocking/unblocking, appointment status changes |
| System startup | Configuration validation, missing key warnings, service connectivity checks |
Database Security
Data layer protections
MongoDB Atlas
Managed cloud database with TLS connections, network access controls, IP allowlisting, and built-in encryption at rest.
Automated backups
Atlas provides continuous backup with point-in-time recovery for production deployments.
Least-privilege credentials
Database users are scoped to minimum required permissions for the application role.
Startup migration
On first boot, legacy JSON backup data can be imported once; thereafter MongoDB is the single source of truth.
Deployment Options
Flexibility for enterprise security requirements
Managed SaaS
NexavateAI operates and maintains the platform on managed cloud infrastructure. Security patching, monitoring, and baseline controls are provided by NexavateAI.
- Included security baseline
- Managed SSL/TLS certificates
- NexavateAI-managed backups
- Shared responsibility model
Customer-Managed
Enterprise customers deploy within their own cloud environment or on-premises, maintaining control over all infrastructure and data residency.
- Full data residency control
- Own security tooling integrations
- Support alignment with internal policies
- NexavateAI provides deployment guides
Responsible Disclosure
If you identify a security vulnerability in NexavateAI products, we request responsible disclosure. Good-faith reports are reviewed and validated issues are addressed according to severity.
Contact: info@nexavateai.com — subject line: Security Vulnerability Report
Please include: a clear description, reproduction steps, affected component, and severity assessment. Do not access data that is not yours or disrupt production services during testing.
We aim to acknowledge receipt within two business days and provide an initial response within ten business days for validated reports.
Incident Reporting
How to report a suspected security or data incident
If you suspect unauthorized access, data exposure, or a platform security incident affecting your organization, contact us immediately at info@nexavateai.com with subject line Security Incident Report.
Include: organization name, affected service, time of discovery, and a description of observed impact. Enterprise customers with active agreements may have defined incident notification procedures in their contract.
Current service status: System Status page