Security isn't optional—it's foundational. Chat.co implements multiple layers of protection to keep your data safe, control who can access your chatbots, and ensure compliance with privacy regulations. This guide covers the security features available to you and how to use them effectively.
1. Security Overview
Chat.co uses a defense-in-depth approach with multiple overlapping security layers.
Encryption
Data encrypted in transit and at rest
Access Control
Role-based permissions and authentication
Privacy
Privacy readiness review in progress
Security Layers
2. Data Protection
Your data is protected using industry-standard encryption and security practices.
Encryption
| Data Type | Protection Method |
|---|---|
| Data in transit | TLS 1.2+ encryption (HTTPS enforced) |
| Passwords | Bcrypt hashing (never stored in plain text) |
| API keys | Scrypt hashing with salt (shown once at creation) |
| Database | Encrypted at rest with cloud provider encryption |
Sensitive Data Handling
Chat.co automatically protects sensitive data from accidental exposure:
- API keys are never returned in API responses after creation
- Passwords are hashed before storage and never logged
- Response sanitization automatically removes sensitive fields
3. Access Control
Control who can access your account and what they can do with role-based permissions.
Authentication Methods
Email + OTP
Passwordless login with one-time codes sent to your email. Codes expire after a short time and are rate-limited to prevent abuse.
Google OAuth
Sign in with your Google account for quick, secure authentication.
API Keys
For programmatic access. Keys can be scoped to specific chatbots and have optional expiration dates.
User Roles
| Role | Access Level |
|---|---|
| Account Owner | Full access to all features, billing, and team management |
| Admin | Configurable permissions—can manage bots and staff but not billing |
| Team Member | Access only to assigned chatbots with specific permissions |
Granular Permissions
Team members can be granted specific permissions per chatbot:
Each permission can be set to view, add, edit, or delete access.
4. Private Chatbot Security
Private chatbots are restricted to authorized users only. Use these features for internal tools, employee resources, or customer portals.
Email Whitelisting
Restrict access to specific email addresses or domains.
- Go to your chatbot's settings
- Navigate to
Access Control - Enable the email whitelist
- Add authorized email addresses
How it works
- Users must verify their email before accessing the chatbot
- Only emails on the whitelist can proceed
- Email matching is case-insensitive
- You can add individual emails or entire domains
Tip: For internal company bots, whitelist your company domain (e.g., @yourcompany.com) instead of individual emails.
5. Deployment Security
Add extra protection to your chatbot's deployment links and embeds.
Security Options
Password Protection
Require a password to access your chatbot. Passwords are securely hashed and rate-limited (5 attempts before temporary lockout).
Link Expiration
Set deployment links to expire after 1, 7, 30, or 90 days. Perfect for time-limited campaigns or temporary access.
IP Whitelist
Only allow access from specific IP addresses. Ideal for office-only or VPN access requirements.
IP Blacklist
Block specific IP addresses from accessing your chatbot. Useful for stopping abuse or unwanted traffic.
Enabling Deployment Security
- Go to your chatbot's Deployment page
- Toggle "Enable Deployment Security"
- Configure your desired options
- Save changes
Note: Security settings apply to all deployment methods—script tags, iframes, and direct links all respect these restrictions.
6. Rate Limiting & Anti-Abuse
Protect your chatbot from abuse and excessive usage with built-in rate limiting.
Types of Rate Limiting
| Type | Default Limit | Purpose |
|---|---|---|
| Per-Chatbot | 20 messages / 2 hours | Prevents individual users from excessive usage |
| IP-Based | Configurable | Stops abuse from specific IP addresses |
| OTP Requests | Limited per 15 min | Prevents OTP brute force attacks |
| Password Attempts | 5 attempts / 15 min lockout | Prevents password guessing |
| API Key Failures | 5 failures / 15 min lockout | Prevents API key guessing |
Custom Rate Limits
You can configure per-chatbot rate limits to match your use case:
- Message limit — Maximum messages per user in the time window
- Time window — Duration before the limit resets
- Error message — Custom message shown when limit is reached
7. Model Data Retention
Everything above concerns data at rest in Chat.co. This section concerns something teams routinely miss: what the model provider does with the prompts and responses that pass through them. On a knowledge agent those prompts contain your documents, so the answer matters.
Every model in the picker under Tune Bot → Behavior carries an explicit data-retention badge:
| Badge | What it asserts |
|---|---|
| No training | The provider is contractually excluded from training on your prompts and responses. Every model hosted on AWS Bedrock carries this, because Bedrock's terms exclude customer content from training across all hosted foundation models. |
| No training, shared | Not trained on, but prompts and responses are shared with the model provider and retained for a limited period for abuse detection, including possible human review. |
| Unknown | No classification has been made for this route. Direct-API access to OpenAI, Anthropic, Google and xAI sits here — not as an allegation that training occurs, but because Chat.co withholds a classification until the exact contractual language has been reviewed. |
“Unknown” means unclassified, not unsafe. Guessing optimistically would mislead you; guessing pessimistically would misrepresent a provider. Where your compliance position needs a definite answer, use the no-training only filter on the model picker — it hides everything outside the strictest category, including the “shared” variant, because the filter promises the strongest posture rather than an approximation of it.
Model selection, and the reasoning behind picking one tier over another, is covered in tuning your bot.
8. Data Privacy & Compliance
Chat.co is designed with privacy in mind and supports compliance with data protection regulations.
ISO/IEC 27001:2022 Certification
SA CYBER LLC's ISMS supporting Chat.co is certified
GCAI, an IAS-accredited certification body, assessed the information security management system and certified it to ISO/IEC 27001:2022. The certified scope covers the design, development, hosting, operation, and support of the Chat.co conversational AI platform, including associated data pipelines, API integrations, voice services, and customer support functions.
- Certificate
- GCAI-ISMS-LM73
- Issued
- August 29, 2026
- Valid through
- August 28, 2029
GDPR Readiness Features
Data Export
Export all your data in JSON or CSV format. Includes conversations, leads, chatbot configurations, and account information.
Account Deletion
Request complete deletion of your account and all associated data. Deletion requests are logged with reason tracking for compliance.
Data Retention
Deleted data is soft-deleted with a 30-day grace period before permanent removal. This allows for recovery if deletion was accidental.
Audit Logging
Chat.co maintains detailed audit logs for accountability and compliance:
- Subscription and billing changes
- Account deletions with reason
- Security events and failed access attempts
- Team member access changes
Data Handling Practices
We do
- Encrypt all data in transit and at rest
- Provide data export on request
- Delete data upon account closure
- Log access for security purposes
We don't
- Sell or share data with third parties
- Use your data to train AI models
- Store passwords in plain text
- Access your chatbots without permission
9. Security Best Practices
Follow these recommendations to maximize your account security.
Account Security Checklist
Use a strong, unique email
Your email is your login credential. Use a professional email with good security practices.
Review team access regularly
Audit who has access to your chatbots quarterly. Remove access for former employees or contractors.
Use minimum necessary permissions
Grant team members only the permissions they need. A content manager doesn't need billing access.
Rotate API keys periodically
If you use API keys, regenerate them every 90 days or immediately if compromised.
Enable deployment security for sensitive bots
Internal chatbots with confidential information should use password protection or IP restrictions.
API Key Security
| Do | Don't |
|---|---|
| Store keys in environment variables | Commit keys to version control |
| Use separate keys for dev/prod | Share keys across environments |
| Set expiration dates on keys | Leave keys active indefinitely |
| Scope keys to specific chatbots | Use a single key for everything |
| Revoke keys when staff leave | Leave unused keys active |
Questions about security?
If you have specific security requirements or questions about compliance, contact our team at security@chat.co. We're happy to discuss your needs.
