Security & data protection

Overview

Credentials at rest

• Encrypted. API keys, client secrets and OAuth access/refresh tokens are sealed with Fernet authenticated encryption before they are written to the database. The encryption key comes from a dedicated server secret that is separate from the one used for login tokens.
• Write-only. After you save a credential, the dashboard only ever shows that one is set, never its value. Refresh tokens are not even masked into the view.
• Destroyed on disconnect. Disconnecting a connector deletes the sealed credentials and the access key and switches off every bot tool that used it — they are erased, not hidden.
• Per-connection access keys. When a connector is used for customer verification, the platform issues it a random access key (scc_…) for its internal Account Connect endpoints. Only a SHA-256 hash is stored against the connection, and a new key replaces the old one each time you press Use to verify customers or Use for tracking (every bot tool wired to that connection moves to the new key at once). See Authentication.
• OAuth done properly. Sign-in uses a one-time state value, the redirect address is fixed to https://www.siluxchat.com/api/connectors/oauth/callback, and tokens are refreshed automatically shortly before they expire.

Read-only, least access

Every setup guide on the connector pages asks for read permissions only. Where a vendor uses OAuth, the scopes requested are fixed in the connector definition. These are the real scopes, straight from the catalogue:

For API-key connectors, create a dedicated key or user for Silux Chat with read-only rights, so you can revoke it without affecting anything else.

Verification before any personal data

• The bot’s account, billing and order tools are hard-gated in code: they refuse to run until the customer has completed verification in the same conversation, and every connector endpoint that returns customer data needs a live session token. Instructions to the AI are not relied upon for this.
• The one exception is parcel tracking by tracking number: it returns only order number, status, tracking number and courier, and only for a parcel whose tracking number is exactly the one the customer gave — the same facts the courier’s public tracking page shows. Tracking by order number needs a session and the order must be the customer’s.
• The customer must give their name plus one more detail. With a connector, the surname must match exactly and the first name must match or begin with the same letter, and the postcode, email or mobile must match the record.
• The one-time code goes to the contact details held in your system — by text where your plan includes SMS, otherwise by email. The chat never chooses where the code goes, so knowing someone’s details is not enough.
• Codes last 10 minutes and work once; five wrong codes void the code; a verified session lasts 30 minutes.
• Replies never say which detail failed to match.

The full sequence is in Customer identity verification & OTP.

Data minimisation

Vendors return far more than a customer needs to hear. Each connector maps a response into a small standard shape, and anything not mapped is discarded before the bot sees it. These are the shapes:

A few connectors add one or two extra fields where they are useful (for example currency or an outstanding amount); each connector page lists its exact fields. Results are limited to a handful of recent records.

Health, dental, veterinary & legal

Clinical records and case files are never mapped. Health, dental and veterinary connectors read appointment times, service names, status and invoices; legal connectors read contact details, bills and matter status. Generated from the catalogue:

Safe requests to vendors

Injection-safe queries

Customer-typed values (an email, a name, a postcode) often end up inside a vendor’s query language — SOQL, OData, search strings, spreadsheet formulas. Before they are inserted, control characters are always removed, and quotes and backslashes are stripped (or escaped for the specific query language where the connector declares one), so a value can never change the meaning of a query. Values placed in URL paths are URL-encoded, so ../ cannot walk to another resource.

No reaching inside networks

Every outbound address is checked before the request is made: only http/https, and addresses that resolve to private, loopback or internal ranges are refused. Redirects are not followed, so a vendor response cannot bounce a request somewhere else. Connector base addresses are HTTPS.

Another customer’s rows are dropped

As a final safety net, any returned row that carries an email address different from the verified customer’s is removed before the bot sees it — whatever the vendor’s search returned. For a customer verified from their own orders or bookings (a vendor with no customer search), a row is shown only if it positively names the customer’s email.

Honest failures

• If a vendor refuses the credentials or is unreachable, the customer is told “We can’t check accounts right now — our team has been told.” The response carries system_error: true, and the connection is marked as failing. A dead connector must never look like “no orders found”.
• Every connection is re-tested daily. If one that was working starts failing (a revoked key, an expired sign-in), the account owner is emailed once with the reason and how to reconnect.
• Rate-limited requests (HTTP 429) are retried a few times, honouring Retry-After, before being reported as a failure.

UK GDPR, roles and retention

Tell your customers, in your privacy notice, that your assistant can look up their account after verifying them, and which systems it reads.

Developer security checklist

• Create a dedicated, read-only API user or key for Silux Chat in each vendor system.
• Never paste production keys into tickets, emails or chat — enter them only on the dashboard.
• For Account Connect: HTTPS only, a long random key, constant-time comparisons, hashed codes, 5-attempt lock, 10/30-minute expiry.
• Rate-limit verify-identity per IP and per account.
• Send codes only to the contact already on the account.
• Return only what your own “My Account” page would show — never passwords, full card numbers or internal notes.
• Log outcomes, not codes or tokens.
• Rotate keys when staff leave or a key may have been exposed; disconnecting destroys the old one on our side.
• Keep the test customer (Test Customer / TE5 7ST, code 123456) working so connections can be re-tested without contacting anyone.

Get help