Security & data handling
Handsom connects to your support and commerce systems, answers customers, and takes the action a ticket needs. This page summarizes how access, customer identity, credentials, model routing, approvals, and audit logs are handled.
Scoped access
Agents receive only the integration methods they are granted.
Encrypted credentials
Sensitive integration keys are encrypted before storage.
Approval gates
Sensitive writes can require human approval before execution.
Audit logs
Tool calls and approval outcomes are recorded for review.
Knowing who it is talking to
A bot that only answers questions never needs to know who is asking. Handsom issues refunds, sends replacements and changes orders, so it does. The check runs in platform code before the call, not as an instruction the model can be talked out of, and it asks for only as much proof as the action needs.
Nothing a customer can reach tells them whether an email, account or order exists. An address we hold nothing for gets the same answer as one we do, the way a password-reset form does. Your team sees what actually happened on the case record.
What each step opens up
- 01They give an order numberThat order alone, and only if the email on the conversation matches it. Nothing else on the account opens up.
- 02They ask for their order historyA one-time code goes to an address already on the account. The agent cannot choose where it is sent.
- 03They ask us to move money or goodsSame code, checked in platform code before the refund, replacement, or address change runs.
Control summary
The table below is intended for security and IT review. We keep it specific so teams can quickly identify which controls are relevant to their approval process.
Data processed
Handsom processes the minimum context needed to investigate a configured support case, answer the customer, and carry out the action it directs. Exact fields depend on the integrations connected and the agent permissions granted.
Typical categories
AI provider policy
We do not train on your data, and neither do the model providers we route to. OpenRouter passes provider policies through rather than enforcing them, so Handsom restricts routing itself: every call is sent with training and retention both denied, set in code rather than configuration.
Review points
- 01Every call routes only to providers that do not collect user data. It is set in code, not configuration.
- 02Every call routes only to providers that keep nothing at rest, which is a separate filter from the training one.
- 03Provider, model, token usage and cost are recorded per call, so what ran is readable afterwards.
- 04Higher-volume customers who need stronger SLA or residency commitments can move to direct provider contracts.
If you leave
Handsom works on top of the systems you already run. Turning it off takes your orders, tickets and subscriptions nowhere, because they were never held here.
What happens
- 01Your store, helpdesk and subscription data stay where they already live. Handsom reads them, it does not hold the system of record.
- 02What Handsom keeps is the case history, the rules you taught it, and the audit trail.
- 03Disconnect an integration and the access token is revoked at the provider.
- 04Ask for your case history and rules and we export them. Ask for them to be deleted and they are.
Audit and evidence
Every support brief should be backed by source records where possible. Audit rows record tool execution and gate outcomes so customers can review what Handsom accessed and what action was taken.
Compliance status
Handsom is early and is not yet SOC 2 certified. We are building toward a stronger formal security program and can share current controls with design partners during vendor review.
Have questions?
We can walk through integration scopes, model-provider routing, data retention, audit logs, and approval settings before you connect production systems.