Security

1. Our approach

CustBot is multi-tenant software: many businesses share one platform, so keeping each customer's data apart is the first design rule, not an add-on. This page describes measures that exist in the product today. We do not currently hold a third-party security certification, and we say so rather than imply one.

2. Data protection

• All traffic between you and CustBot is encrypted with TLS.
• Passwords are stored only as one-way hashes.
• Third-party API keys and channel credentials that customers store with us are encrypted at rest.
• We do not receive or store full payment card numbers; subscription payments are handled by our Merchant of Record.

3. Customer data isolation

• Every business record carries the owning customer's identifier, and the database enforces row-level security so a query can only see its own customer's rows.
• Each customer's knowledge base is kept in its own isolated search collection.
• Caches and queues are namespaced per customer.
• Automated tests check that data from one customer is never returned to another.

4. Access and sessions

• Sign-in sessions use short-lived tokens and rotating refresh tokens that can be revoked on the server.
• Session cookies are HttpOnly and Secure, and state-changing requests are protected against cross-site request forgery.
• Team members get roles with only the access they need, and administrator actions on support requests are recorded.
• Sign-in attempts are rate limited, and repeated failures lock the account temporarily.

5. Application safeguards

• Public endpoints are rate limited, and incoming webhooks are verified by signature.
• Input is validated at every boundary, and text is sanitised before it reaches an AI model to reduce prompt-injection risk.
• Traffic passes through a web application firewall and DDoS protection.

6. Responsible AI behaviour

• The agent answers from your knowledge base. When its confidence is low, it hands the conversation to a human instead of guessing.
• The agent does not claim to be a person when a customer sincerely asks.
• You choose which actions the agent may take, such as orders or bookings, and can switch each one off at any time.

7. Monitoring and audit

• Important actions, including agent decisions and human handoffs, are written to an append-only audit log.
• Service health is checked automatically, and failures raise alerts.

8. Backups and changes

• A database backup is taken and verified before every production release that can change data.
• Releases switch traffic between two sets of containers with an automatic rollback if health checks fail, so updates do not interrupt service.

9. Incident response

If we confirm an incident that affects customer data, we contain it, investigate the cause, notify affected customers without undue delay, and add a test or control so it does not repeat.

10. Report a vulnerability

If you believe you found a security problem, write to [email protected] with the details. Please give us reasonable time to fix it before sharing it publicly, and do not access other customers' data. We will acknowledge your report and keep you informed.