Security Whitepaper.

Executive Summary

Dataviz by DemanualAI is an AI-powered analytics platform that translates natural language questions into SQL queries against your existing databases. Because our platform connects to your production data, security is foundational — not an afterthought.

This document describes the technical security controls, architectural decisions, and compliance posture that protect your data at every layer.

1. Architecture Overview

[Your Database] ←── SSH Tunnel (AES-256) ──→ [DemanualAI Backend]
                                                    │
                                              ┌─────┴─────┐
                                              │  FastAPI   │
                                              │  (Python)  │
                                              └─────┬─────┘
                                                    │
                                    ┌───────────────┼───────────────┐
                                    │               │               │
                              [AWS Bedrock]   [Supabase DB]   [Redis Cache]
                              (LLM - ephemeral) (metadata)    (temp cache)
                                    │
                              [Your Browser / Slack / WhatsApp]

Key architectural decisions:

• Your database credentials are encrypted at rest using AES-256-GCM in Supabase Vault
• LLM calls to AWS Bedrock are stateless — no data is retained by the AI model
• Query results pass through our system but are not persisted beyond the active session
• All inter-service communication uses TLS 1.2+

2. Network Security

2.1 Edge Protection (AWS CloudFront + WAF)

All API traffic is routed through AWS CloudFront with enterprise-grade protection:

• TLS 1.2 minimum enforced on all connections
• AWS WAF with managed rulesets: rate limiting at 2,000 requests per 5 minutes per IP; AWS Managed CommonRuleSet (OWASP Top 10 coverage); AWS Managed KnownBadInputsRuleSet (Log4j, known exploits)
• DDoS protection via AWS Shield Standard (included with CloudFront)

2.2 Application-Level Protection

• Security headers enforced at the reverse proxy: Strict-Transport-Security (HSTS, 1 year, includeSubDomains); X-Content-Type-Options: nosniff; X-Frame-Options: DENY; X-XSS-Protection: 1; mode=block; Referrer-Policy: strict-origin-when-cross-origin
• Application-level rate limiting: 30 requests/second per IP (burst: 50)
• HTTP → HTTPS redirect enforced at all entry points

2.3 Database Connectivity

• SSH Tunneling: Encrypted SSH tunnels for databases behind firewalls
• SSL/TLS: Direct connections enforce TLS where supported
• No public exposure: Your database credentials and connection details never leave our backend

3. Authentication & Authorization

3.1 User Authentication

• JWT-based authentication via Supabase Auth
• Token verification using JWKS (JSON Web Key Set) with RS256 signatures
• JWKS keys cached with 1-hour TTL and automatic refresh
• Token expiry enforced on every API request

3.2 Role-Based Access Control (RBAC)

3.3 Multi-Factor Considerations

• Authentication is managed by Supabase Auth, which supports MFA
• MFA enforcement can be configured per tenant

4. Data Security

4.1 Credential Management

Your database credentials receive the highest level of protection:

• Encryption: AES-256-GCM via Supabase Vault (pgsodium extension)
• Access Control: Vault decryption functions restricted to service_role only — no client-side access possible
• SSH Keys: Stored encrypted in Vault; raw keys never persisted in application tables
• Password Redaction: All API responses redact passwords — they are never returned to the frontend
• Credential Audit Trail: Every credential access is logged with user ID and timestamp

4.2 Zero Data Retention Model

5. AI / LLM Security

5.1 Prompt Injection Defense

Our platform processes untrusted natural language input through an LLM. We defend against prompt injection at multiple layers:

5.2 SQL Safety — Three-Stage Validation

Every AI-generated SQL query passes through three independent validation stages:

5.3 Read-Only Enforcement — Three Independent Layers

5.4 LLM Data Privacy

• Provider: AWS Bedrock (Claude Haiku 4.5)
• Data Retention: AWS Bedrock does not store or use customer data for model training
• Processing: Ephemeral — no data persists after the API call
• Compliance: AWS Bedrock is SOC 2, ISO 27001, and GDPR compliant

6. Multi-Tenant Isolation

6.1 Row-Level Security (RLS)

Every database table has PostgreSQL Row-Level Security policies:

• Users can only access data belonging to their own tenant
• Within a tenant, users see only their own conversations
• Immutable audit log: RLS blocks all UPDATE and DELETE on audit records — even our application cannot modify history
• Vault access restricted to service_role only

6.2 RLS Coverage

All 15+ tables have RLS policies including:

• tenants, tenant_members, connections, conversations, conversation_messages
• favorite_charts, audit_log, token_usage_log, tenant_limits
• generated_reports, connection_few_shots, connection_error_ledger

7. Client Recommendations

To maximize security when using Dataviz by DemanualAI:

1. Provide read-only database credentials — Create a dedicated user with SELECT-only permissions
2. Use SSH tunneling — For databases behind firewalls
3. Whitelist our IP — Restrict database access to our static IP (provided during onboarding)
4. Rotate credentials regularly — Update connection credentials periodically
5. Review audit logs — Monitor query activity through the admin panel
6. Set usage limits — Configure appropriate daily/monthly caps
7. Use strong passwords — Enforce MFA for team members via Supabase Auth

8. Compliance

9. Contact

This whitepaper is reviewed and updated quarterly. Last review: March 2026.