Chatsy security: what the code protects today

Security pages are easy to overstate. A code repository can show how an application handles a password or integration token. It cannot, by itself, prove where production data is hosted, how backups are encrypted, or whether a company has passed an external audit.

This page separates those two kinds of evidence. It describes safeguards visible in the Chatsy application code as reviewed on August 31, 2026. Deployment controls, legal commitments, and certifications need separate evidence.

Chatsy's code supports a specific set of security claims. Saved integration credentials use AES-256-GCM. Passwords use bcrypt with a cost factor of 12. The data model includes workspace roles and resource assignments. Public chat requests and outbound tool calls have targeted abuse controls. This is not proof of blanket encryption, regulatory compliance, regional hosting, or an audited security program.

Credential encryption

Chatsy encrypts credentials submitted through its dedicated integration authentication fields with AES-256-GCM before writing them to the database.

The implementation creates a new 12-byte initialization vector for each encryption operation and stores the authentication tag with the ciphertext. It requires a 32-byte key supplied through the TOKEN_ENCRYPTION_KEY environment variable. The same encryption path is used for OAuth access and refresh tokens, API-key connections, tool authentication settings, OAuth app secrets, and bring-your-own email credentials.

When an enabled tool runs, the server decrypts the saved authentication value and adds it to the outbound request. Tool list and detail endpoints replace the saved authentication payload with its type and a configured flag. The tool execution logger masks fields whose names look like tokens, keys, secrets, passwords, or authentication values.

The limits of this protection

This guarantee applies to credentials saved through the authentication configuration. A custom tool header is a separate database field. Do not place a secret in an arbitrary header or URL.

The application code uses one active encryption key. It does not contain a key ring or an automatic rotation process. Rotating that key safely would require a planned migration of existing ciphertext. Claims about AWS KMS, hardware security modules, customer-specific keys, or 90-day rotation need deployment evidence that is not present here.

Passwords and sessions

Chatsy's email and password authentication hashes passwords with bcrypt using a cost factor of 12. The application stores the hash, not the readable password.

Better Auth manages account sessions. The current server configuration sets a 30-day session lifetime and refreshes the session age every 24 hours.

The code reviewed for this page does not establish two-factor authentication, enterprise SSO, or a user-facing list of revocable sessions. Those features should not appear on a security questionnaire unless they have been implemented and tested in the current product.

Workspace and resource access

The database model distinguishes workspace owners, accepted admins, and accepted members. It can assign members access to a chatbot, mailbox, or knowledge base at VIEW, EDIT, or MANAGE level.

Chatsy's chatbot query helper includes resources owned by the signed-in user, resources in a workspace the user owns, resources available to an accepted workspace admin, and resources explicitly assigned to a member. Many chatbot routes combine that query with an authenticated session before returning data.

This is application-level authorization. It is not PostgreSQL row-level security. The presence of roles and access levels in the schema also does not prove that every route applies every level correctly. A security review should test read and write operations for each role, including requests made with a valid resource ID from another workspace.

Outbound tool safeguards

Chatsy agents can call approved HTTP tools. The executor applies several checks before it sends an external request:

• External endpoints must use HTTPS.
• A tool URL cannot contain a username or password.
• DNS results that point to private or reserved network addresses are rejected.
• Redirects are not followed.
• A request stops after 15 seconds.
• A response larger than 256 KB is rejected.

These checks reduce the risk of a tool reaching an internal service or returning an unbounded payload. They apply to the tool execution path. They are not evidence that every outbound request elsewhere in the application uses the same controls.

Public chat safeguards

Public chat endpoints only load chatbots marked public. A visitor token must match a restricted format. Chatsy hashes that token with the chatbot ID before using it to identify a visitor's conversations, so the raw token is not stored as the conversation identifier.

The chat endpoint rejects request bodies larger than 64 KB. It also records a database-backed limit of 20 chat requests per visitor and chatbot in each one-minute window.

Those controls help with basic abuse and cross-visitor conversation access. They do not replace load testing, bot protection, or an incident response plan.

What this repository does not prove

The application code reviewed for this page does not establish any of the following:

• SOC 2 Type II certification or a completion date
• HIPAA eligibility or a signed Business Associate Agreement
• GDPR or CCPA compliance
• US, EU, or customer-selected data residency
• PostgreSQL transparent data encryption or database row-level security
• S3 storage, encrypted backups, or per-customer encryption keys
• TLS 1.3 or mutual TLS across a production deployment
• Cloudflare DDoS protection, a web application firewall, or a private VPC
• fixed retention periods, 30-day deletion, or cryptographic erasure
• an active bug bounty, annual penetration tests, or 24-hour patching
• 24/7 monitoring or incident response

These may exist outside the repository, but customers should ask for current evidence before relying on them.

How to verify Chatsy for your use case

A useful security review asks for proof tied to the environment that will hold your data.

Review the documents

Ask for the current privacy terms, data processing agreement, subprocessor list, retention schedule, deletion process, hosting regions, and any independent audit report. Confirm the legal entity and product named in each document.

If you need HIPAA, ask for a signed BAA before sending protected health information. If you need SOC 2, review the report period, scope, exceptions, and bridge letter. A roadmap date or sales statement is not an attestation.

Test authorization

Create two test workspaces and use accounts with different roles. Try known IDs for chatbots, conversations, sources, mailboxes, knowledge bases, tools, and analytics. Test GET, POST, PATCH, and DELETE requests. A hidden navigation item is not an access control.

Test credential handling

Connect a disposable provider account with a restricted test credential. Confirm that read APIs do not return the secret and that execution logs do not contain it. Use the dedicated authentication fields. Do not put a secret in a custom header or endpoint URL.

Test public chat boundaries

Use two visitor tokens against the same public chatbot. Confirm that neither visitor can read, poll, stream, update, or rate the other's conversation. Confirm that a private chatbot returns no public configuration or conversation data.

Confirm deletion and recovery

Delete a test chatbot, source, conversation, and workspace. Ask Chatsy to show what is removed immediately, what remains in backups, who can restore it, and when backup copies expire. Database cascade rules do not answer the backup question.

Frequently asked questions

Is all Chatsy data encrypted at rest?

This repository proves AES-256-GCM encryption for saved integration credentials. It does not prove blanket encryption for the database, files, embeddings, logs, or backups. Ask for evidence from the current production environment.

Is Chatsy SOC 2, HIPAA, GDPR, or CCPA compliant?

Do not infer compliance from application code. Request the current certification, agreement, policy, or legal assessment that applies to your account and data.

Can team access be restricted?

The data model supports workspace roles, resource assignments, and three access levels. Verify the exact operations each role can perform because the schema alone does not prove route-level enforcement.

Does Chatsy delete account data within 30 days?

This repository does not establish that deadline or describe backup expiration. Ask for the current retention and deletion policy, then test the process with non-sensitive data.

Where should integration secrets be entered?

Use the integration or tool authentication fields. Do not put credentials in endpoint URLs or arbitrary custom headers.

Talk through your requirements

If Chatsy will handle regulated or sensitive data, send the exact requirements to the team before connecting a production source or integration. Ask for evidence, not a generic security promise.

Discuss your security requirements