Security First: How We Protect Your Data

When you entrust your customer conversations and business data to Chatsy, security isn't just a feature — it's a foundational principle that shapes every decision we make. From the encryption algorithms protecting your data to the access controls governing who can see it, security is woven into every layer of our platform.

In this comprehensive guide, we'll pull back the curtain on our security practices, explain our technical implementations, and help you understand exactly how we protect your most sensitive information.

Our Security Philosophy

Before diving into technical details, it's important to understand the principles that guide our security decisions:

Defense in Depth: We never rely on a single security measure. Multiple overlapping controls ensure that if one fails, others provide protection. A compromised password doesn't grant access without session validation. A network breach doesn't expose data without encryption. Each layer assumes other layers might fail.

Least Privilege: Every system, user, and process has only the minimum access required to function. Database connections can't access files. API endpoints can't access other customers' data. Background workers can't access user sessions.

Zero Trust: We verify every request, even from internal systems. Trust is earned through authentication and authorization, not assumed based on network location or previous access. Every API call is validated, every database query is scoped.

Transparency: We believe you should understand how your data is protected. This document is part of that commitment — demystifying security practices so you can make informed decisions about your data.

Data Encryption: Protecting Information at Every Stage

Encryption at Rest

All data stored in Chatsy systems is encrypted using industry-standard AES-256 encryption:

Database Encryption: Our PostgreSQL databases use Transparent Data Encryption (TDE). This means data is automatically encrypted when written to disk and decrypted when read into memory. Even if someone obtained physical access to our storage devices, the data would be unreadable.

File Storage: Documents, images, and other files are stored in S3 with server-side encryption (SSE-S3). AWS manages the encryption keys, providing automatic encryption without any performance impact.

Backup Encryption: All backups are encrypted with customer-specific keys. This ensures that even backup files — often overlooked in security discussions — maintain the same protection level as live data.

Vector Embeddings: Your knowledge base embeddings, which power AI search capabilities, are encrypted alongside other data. The mathematical representations of your content receive the same protection as the content itself.

Encryption in Transit

All communications use TLS 1.3, the latest and most secure transport layer protocol:

API Traffic: All API endpoints require HTTPS. HTTP requests are automatically redirected. We enforce HTTP Strict Transport Security (HSTS) to prevent downgrade attacks.

Internal Services: Communication between our microservices uses mutual TLS (mTLS). Both the client and server authenticate each other, preventing man-in-the-middle attacks even within our internal network.

Database Connections: All database connections require SSL with certificate validation. Unencrypted connections are rejected at the network level.

Third-Party Integrations: When your chatbot connects to external services (via tool calling or webhooks), we use encrypted connections and validate certificates.

Encryption Key Management

Proper key management is often the weakest link in encryption systems. We take it seriously:

• Keys stored in AWS KMS: We don't store encryption keys in our codebase or application servers. AWS Key Management Service provides hardware security module (HSM) protection.
• Automatic key rotation: Keys are rotated every 90 days automatically. Previous keys remain available for decrypting older data but aren't used for new encryption.
• Separate keys per customer (Enterprise): Enterprise customers receive dedicated encryption keys, ensuring complete cryptographic isolation from other customers.

Access Controls: Ensuring Only Authorized Access

Multi-Tenant Isolation

Chatsy is a multi-tenant platform, meaning multiple customers share infrastructure. Ensuring complete data isolation is critical:

typescript
// Every database query includes tenant validation
const documents = await prisma.document.findMany({
  where: {
    chatbotId,
    chatbot: {
      organizationId: session.organization.id  // Always scoped to organization
    }
  }
});

This pattern is enforced throughout our codebase. It's not possible to accidentally query another customer's data because the scope is always present.

We also implement row-level security in PostgreSQL as an additional safeguard:

sql
-- Row-level security policy
CREATE POLICY tenant_isolation ON documents
  FOR ALL
  USING (organization_id = current_setting('app.current_organization_id')::uuid);

Role-Based Access Control (RBAC)

Team members have different access levels based on their roles:

Roles are enforced at the API level — attempting to access functionality beyond your role returns an authorization error.

Authentication Security

Password Storage: Passwords are hashed using bcrypt with a cost factor of 12. We never store plaintext passwords, and the hashing algorithm is computationally expensive enough to resist brute-force attacks.

Session Management: Sessions use secure, HttpOnly cookies that can't be accessed by JavaScript. Sessions expire after 24 hours of inactivity, and users can view and revoke active sessions from their account settings.

OAuth Integration: We support Google and GitHub SSO for organizations that prefer centralized identity management. OAuth tokens are stored encrypted and scoped to minimum required permissions.

API Key Security: API keys are scoped to specific capabilities (read, write, admin), rotatable at any time, and rate-limited to prevent abuse. Keys can be restricted by IP address for additional security.

AI Safety: Protecting Against AI-Specific Threats

AI systems introduce unique security challenges. We address them proactively:

Prompt Injection Protection

Malicious users might try to manipulate AI behavior through crafted inputs. We sanitize all user inputs before they reach the LLM:

typescript
function sanitizeInput(input: string): string {
  // Remove potential injection patterns
  return input
    .replace(/\b(ignore|disregard|forget)\s+(previous|above|all)\b/gi, '')
    .replace(/\bsystem\s*:/gi, '')
    .replace(/\buser\s*:/gi, '')
    .replace(/\bassistant\s*:/gi, '')
    .trim();
}

We also use structured prompt templates that separate user input from system instructions, making injection attacks significantly harder.

Content Filtering

• Harmful content detection: AI responses are checked for inappropriate content before delivery
• PII redaction in logs: Personally identifiable information is automatically redacted from logs and analytics
• Configurable boundaries: You can define topics your AI should refuse to discuss

Hallucination Prevention

AI hallucinations are a significant concern in customer support. Our mitigations include:

• Source citations: Responses reference specific knowledge base articles
• Confidence scoring: Low-confidence responses trigger fallbacks
• Grounded generation: AI responses are constrained to information in your knowledge base
• Human escalation: Uncertain queries can automatically escalate to human agents

Infrastructure Security

Network Architecture

Our infrastructure follows defense-in-depth principles:

┌─────────────────────────────────────────────┐
│                 Cloudflare                   │
│              (DDoS Protection)               │
└─────────────────────────────────────────────┘
                      │
┌─────────────────────────────────────────────┐
│                 WAF Rules                    │
│          (OWASP Top 10, Custom)             │
└─────────────────────────────────────────────┘
                      │
┌─────────────────────────────────────────────┐
│              Load Balancer                   │
│              (SSL Termination)               │
└─────────────────────────────────────────────┘
                      │
┌─────────────────────────────────────────────┐
│              Private VPC                     │
│    ┌─────────┐  ┌─────────┐  ┌─────────┐   │
│    │ App Pod │  │ App Pod │  │ App Pod │   │
│    └─────────┘  └─────────┘  └─────────┘   │
│                      │                       │
│    ┌─────────────────────────────────────┐  │
│    │      Database (Private Subnet)      │  │
│    └─────────────────────────────────────┘  │
└─────────────────────────────────────────────┘

Key security features:

• Cloudflare DDoS protection absorbs volumetric attacks
• Web Application Firewall blocks common attack patterns (SQL injection, XSS, etc.)
• Private VPC keeps databases inaccessible from the public internet
• Network segmentation limits lateral movement if any component is compromised

Monitoring and Alerting

We maintain comprehensive security monitoring:

• Real-time anomaly detection: Unusual patterns trigger immediate investigation
• Failed authentication alerts: Multiple failed login attempts generate alerts
• Access pattern analysis: Unusual data access patterns are flagged for review
• 24/7 incident response: Security events are monitored around the clock

Compliance and Certifications

Data Residency

• Default: United States (AWS us-east-1)
• EU option: Frankfurt, Germany (AWS eu-central-1)
• Enterprise: Custom regions available upon request

Data Retention and Deletion

• Conversation logs: 90 days by default (configurable 30-365 days)
• Analytics data: 1 year
• Audit logs: 7 years
• Right to deletion: All data deleted within 30 days of request

When you delete your account or request data deletion, we don't just mark records as deleted — we cryptographically shred the data, rendering it unrecoverable.

Vulnerability Management

Bug Bounty Program

We maintain an active bug bounty program to encourage responsible disclosure:

Penetration Testing

• Annual third-party penetration tests by reputable security firms
• Continuous automated scanning for known vulnerabilities
• Immediate patching of critical vulnerabilities (within 24 hours)
• Dependency monitoring for vulnerable packages

Your Security Responsibilities

Security is a shared responsibility. While we protect the platform, you control access to it:

Use strong, unique passwords: At least 12 characters, combining letters, numbers, and symbols. Use a password manager.

Enable two-factor authentication: Available in account settings. We strongly recommend enabling it.

Review team access regularly: Remove access for departed team members promptly. Audit permissions quarterly.

Protect API keys: Never commit API keys to version control. Rotate keys periodically. Use IP restrictions where possible.

Report concerns immediately: If you notice suspicious activity, contact security@chatsy.app right away.

Questions and Contact

Security is an ongoing conversation, not a checkbox. If you have questions about our practices, need specific compliance documentation, or want to discuss your organization's security requirements, we're here to help.

Security Team: security@chatsy.app Bug Reports: security@chatsy.app (please include reproduction steps) Compliance Requests: Contact sales for SOC 2 reports and other documentation

Your trust is our most valuable asset. We work every day to deserve it.

Start Secure →