Security

ChatPilot handles WhatsApp conversations, M-Pesa payments, customer contact records, and business credentials for hundreds of African businesses. Security is not a compliance checkbox — it is the foundation on which every business that trusts us with their customers and their payment flows depends.

This page explains what we do to protect your data, your customers' data, and your business.

Cloud Hosting

ChatPilot is hosted on Amazon Web Services (AWS), operating primarily in regions with the lowest latency to East Africa. AWS holds ISO 27001, SOC 2 Type II, and PCI DSS certifications, providing a certified physical and infrastructure security baseline that we build on.

All production infrastructure is deployed within a Virtual Private Cloud (VPC) with strict network segmentation. Public internet access to production systems is restricted to specific, documented ingress points only — inbound WhatsApp webhooks, the API layer, and the dashboard frontend. No database or internal service is directly reachable from the public internet.

Network Security

• All traffic between ChatPilot services and the public internet is encrypted via TLS 1.2 minimum — TLS 1.3 is the default
• Internal service-to-service communication within the VPC uses TLS where the service supports it
• Web Application Firewall (WAF) deployed in front of all public endpoints — protects against common web attacks including SQL injection, cross-site scripting, and request flooding
• DDoS protection enabled at the AWS Shield Standard tier across all public endpoints
• Rate limiting applied at the API gateway level — per-IP and per-Tenant limits protect against abuse and ensure fair usage
• Outbound traffic from the VPC is controlled via security group rules — services can only communicate with explicitly permitted external destinations

Redundancy and Availability

• Database: managed PostgreSQL with automated backups every 6 hours, point-in-time recovery, and Multi-AZ replication for automatic failover
• Application layer: horizontally scalable, deployed across multiple availability zones — a single zone failure does not take the platform offline
• Message queue: persistent task queue with retry logic — inbound WhatsApp webhooks are logged before processing begins, so no message is lost if a downstream service is temporarily unavailable
• Target uptime: 99.9% monthly (excluding scheduled maintenance windows, communicated in advance)

At Rest

All data stored by ChatPilot is encrypted at rest:

• Database (PostgreSQL): AES-256 encryption at the storage level via AWS RDS encryption — every row, every column, every backup
• Object storage (S3): AES-256 server-side encryption for any files stored (content documents, media files)
• Field-level encryption for sensitive credentials: M-Pesa passkeys, WooCommerce consumer secrets, HubSpot access tokens, Google Ads credentials, and PayHero API keys are encrypted at the application layer before database storage — encrypted with a key management system (AWS KMS), decrypted only in memory, only at the point of use, and never logged

In Transit

• All communication between clients (web browsers, mobile apps) and ChatPilot servers uses TLS 1.2 minimum
• All communication between ChatPilot and external APIs (Meta WhatsApp Cloud API, Safaricom Daraja, Anthropic, Cohere, HubSpot, Google) uses TLS
• HTTP Strict Transport Security (HSTS) enforced — browsers are instructed to always use HTTPS for chatpilot.biz and app.chatpilot.biz
• SSL certificates are managed via AWS Certificate Manager with automatic renewal — no risk of expired certificate exposing traffic

Tenant Isolation

The most fundamental security guarantee ChatPilot provides to its business customers is complete tenant isolation. Every piece of data in the system carries a tenant_id. Every database query that returns or modifies data is scoped by tenant_id at the application layer. One Tenant cannot access, read, or modify another Tenant's data under any circumstances.

This isolation applies to:

• Contact records and conversation history
• Messages and payment records
• Tenant content and vector embeddings
• Campaign data and analytics
• Integration credentials

Isolation is enforced at the application layer, not relied upon solely at the database level. Even in the event of a query error, cross-tenant data access is structurally prevented.

ChatPilot Staff Access

Access to production systems by ChatPilot staff is controlled and audited:

• Production database access is restricted to authorised engineering and operations personnel only
• All production access requires multi-factor authentication (MFA)
• Access to production databases is via authenticated bastion hosts — no direct public access to production databases exists
• All production access sessions are logged with timestamp, user identity, and commands executed
• The principle of least privilege applies — staff have access only to the systems and data required for their role
• Access rights are reviewed quarterly and revoked immediately on role change or departure
• Customer conversation content is not routinely accessed by ChatPilot staff — access to message content for support or debugging purposes requires a documented reason and is logged

Tenant User Access Controls

Within the ChatPilot dashboard, Tenants control their own team's access:

• Role-based access: Owner, Admin, and Staff roles with different permission levels
• Staff role: can view and respond to conversations, cannot access integration credentials or billing
• Admin role: full platform access except billing
• Owner role: full access including billing, subscription management, and account deletion
• All dashboard logins require email and password; MFA via authenticator app is available and recommended
• Failed login attempts trigger account lockout after 5 consecutive failures, with unlock via email verification
• Active sessions can be reviewed and terminated from the security settings page

Secure Development Practices

• All code changes require peer review before merging to the main branch
• Automated security scanning (SAST) runs on every pull request — checks for common vulnerabilities including injection flaws, insecure dependencies, and secrets committed to code
• Dependency scanning runs continuously — known vulnerable packages are flagged and patched promptly
• Secrets (API keys, credentials) are never stored in source code — all secrets are injected via environment variables from a secrets manager
• Security-focused code reviews for any change touching authentication, payment processing, or data access logic

Input Validation and Injection Prevention

• All user-supplied input is validated and sanitised before processing
• Database queries use parameterised statements — SQL injection is structurally prevented
• WhatsApp message content received from Meta's API is treated as untrusted input — no content is executed or interpreted as code
• API endpoints validate request schemas strictly — unexpected fields are rejected, not silently ignored

Authentication and Session Management

• Passwords are hashed using bcrypt with a per-user salt — plaintext passwords are never stored
• Password reset links are single-use, time-limited (1 hour), and invalidated on use
• JWT tokens used for API authentication are short-lived (15 minutes) with refresh token rotation
• Refresh tokens are invalidated on logout and on password change
• Session tokens are stored in secure, HTTP-only cookies — not accessible to JavaScript

API Security

• All API endpoints require authentication except explicitly public endpoints (webhook receiver, health check)
• WhatsApp webhook receiver validates Meta's X-Hub-Signature-256 signature on every inbound webhook — unsigned or incorrectly signed requests are rejected before any processing occurs
• M-Pesa callback endpoint validates the callback source and request structure before processing any payment state changes
• Rate limiting applied per API key and per IP to prevent brute force and abuse

M-Pesa payment security is a specific area of focus given that ChatPilot processes payment transactions on behalf of Kenyan businesses.

What ChatPilot handles:

• Initiating STK Push requests to Safaricom Daraja via the business's registered shortcode and passkey
• Receiving payment confirmation callbacks from Safaricom
• Logging payment outcomes (success, failure, timeout) and linking them to orders

What ChatPilot never handles:

• M-Pesa PINs — entered by the customer directly on their phone, never transmitted to or through ChatPilot
• Card payment data — ChatPilot does not process credit or debit card payments
• Safaricom account credentials beyond the API integration keys (shortcode, passkey)

Credential protection:

• M-Pesa shortcodes and passkeys are encrypted at the field level using AWS KMS before storage
• They are decrypted only in memory, only at the point of initiating a payment request
• Decrypted credentials are never written to logs, error messages, or monitoring systems
• Access to the decryption keys is restricted to the payment processing service only

Transaction integrity:

• Every STK Push is initiated with a unique Checkout Request ID returned by Safaricom
• Payment callbacks are matched against the original request by Checkout Request ID before being accepted
• Duplicate callback processing is prevented via idempotency checks on the Merchant Request ID
• Payment state changes (pending → confirmed, pending → failed) are irreversible in the database — there is no mechanism to alter a confirmed payment record

ChatPilot's connection to WhatsApp is through Meta's official Cloud API as a registered Meta Tech Provider:

• Business accounts are connected via Meta Embedded Signup — ChatPilot receives a scoped access token for the specific WhatsApp Business Account only
• ChatPilot access tokens are stored encrypted and can be revoked by the Tenant at any time through their Facebook Business Manager
• Inbound webhooks from Meta are signature-verified using X-Hub-Signature-256 before any message is processed — forged webhooks are rejected
• ChatPilot does not request or store access to any Meta data beyond what is required for WhatsApp message sending and receiving

Vulnerability Management

• External penetration testing is conducted at least annually by an independent security firm
• Internal security reviews are conducted quarterly on high-risk components (authentication, payment processing, data access)
• Known CVEs in dependencies are monitored continuously — critical vulnerabilities are patched within 72 hours, high within 7 days
• Bug bounty programme: security researchers who responsibly disclose vulnerabilities are credited and rewarded (see Responsible Disclosure below)

Incident Response

In the event of a confirmed security incident affecting Tenant or customer data:

1. Detection: Automated monitoring alerts on anomalous access patterns, unusual data volumes, or system errors
2. Containment: Affected systems isolated within 1 hour of confirmed incident
3. Assessment: Scope of impact assessed — what data, which tenants, what time period
4. Notification: Affected Tenants notified within 72 hours of confirmed impact, consistent with Kenya Data Protection Act requirements. Notification includes: what happened, what data was affected, what we did, and what Tenants should do
5. Remediation: Root cause addressed, controls strengthened, post-incident review completed
6. Regulatory notification: The Office of the Data Protection Commissioner (ODPC) notified where required by law

We maintain an incident response plan that is reviewed and tested annually.

If you have discovered a security vulnerability in ChatPilot, we want to hear from you.

Please report to: security@chatpilot.biz

Please include:

• A description of the vulnerability and its potential impact
• Steps to reproduce the issue
• Any proof-of-concept code or screenshots that help illustrate the vulnerability

We commit to:

• Acknowledging your report within 2 business days
• Keeping you informed of our progress
• Not taking legal action against researchers who follow responsible disclosure practices
• Crediting you publicly for your discovery (if you consent)

Please do not:

• Access, modify, or delete data belonging to other users or tenants
• Perform denial-of-service attacks
• Send phishing communications to ChatPilot staff or customers
• Disclose the vulnerability publicly before we have had an opportunity to address it (we ask for a minimum of 90 days)

For security concerns, vulnerability reports, or questions about our security practices:

Security team: security@chatpilot.biz Data protection queries: privacy@chatpilot.biz General enquiries: hello@chatpilot.biz

For urgent security incidents, email security@chatpilot.biz with "URGENT" in the subject line. We monitor this address continuously.

ChatPilot Ltd Nairobi, Kenya