Security
The security model, in plain words.
Sidekick Agents runs on your own server, so part of keeping it safe is yours. This page says what the platform itself does, and then what is left to you.
Instructions
Only the flow’s author tells a model what to do.
What a caller, another agent, a tool or a document says never reaches a model as instructions. Only what the flow’s author wrote does.
Callers
What a caller says is what a caller said. A review written after the call reads it, and never obeys it.
Other agents
What a client of the gateway sends reaches an agent as what its caller said. It is never treated as instructions, whatever it says.
Tools
A tool from an MCP server whose description changes is held back until somebody has looked at it. A tool can also wait for a person’s approval before it runs.
Documents
What a document in a knowledge base says reaches a model as something found, never as instructions.
Your data
One workspace cannot read another’s.
The database enforces it, not only the application.
Row-level security
Every table that belongs to a workspace is behind row-level security. The application’s database role cannot see across workspaces.
Credentials, encrypted and bound
Stored credentials are encrypted with AES-256-GCM, and bound to the hosts they may be sent to. A stored key is only ever sent to the host it was entered for.
Roles, for people and for keys
Each person in a workspace has a role, and so does each API key.
An audit log
A record of who changed what. Somebody who steps in to a live call is on it too.
What is kept about callers
When a stage is allowed to remember things about a caller, people in the workspace can see what is kept, and remove it.
Sensitive details stay off the record
What is said while a step collects details marked sensitive is kept out of the transcript and the trace.
A record that cannot be altered
Every request another agent makes through the gateway, allowed or refused, is written to it.
The roles
The network
What goes out goes through one guard.
An agent with tools can be asked to fetch things. The platform decides where it may go.
No private addresses
Outbound requests cannot be pointed at private addresses unless a platform administrator allows them.
The address checked is the address used
The resolved address is the one connected to, and redirects are checked again.
Nothing dialled of its own accord
The platform rings only destinations a workspace set up by name, under per-trunk rules on where and how often.
SIP kept to your PBXs
On a server set up by the runbook, only the PBX addresses you name may reach SIP, and a fail2ban jail shuts out SIP scanners.
Between services
Each part proves who it is.
The platform is several services. None of them takes another’s word for it.
Short-lived tokens
Services identify themselves to each other with short-lived tokens, with one signing key for each pair.
The voice worker decides nothing
It hears, takes turns and speaks. What to say and what to do is decided elsewhere.
A gateway key opens the gateway only
The REST API refuses it. A token from signing in is good for the gateway only, for ten minutes at a time.
Self-hosted
What stays yours to look after.
There is no hosted service behind this product. The server is yours, and so are these.
The server
One Ubuntu server, with everything in Docker. The host script sets up its firewall.
The encryption keys
Losing them loses every stored provider key, tool token and SIP password. They are saved beside every backup.
The backups
A nightly database dump is made, and restored into a scratch database to prove that it can be. Copying it off the server is up to you.
The updates
You replace the release files, rebuild and restart. Database changes are applied before the services start.
Start with a workspace of your own.
Create an account, connect a model, and make your first agent from a template.