Security
Security and data storage
Where account data lives, who can see it, what happens during a failure and where we ourselves have no access. What follows is the design, not promises: every point can be checked with a question at the meeting.
Client workspace → Separate database → Nightly encrypted backup
A separate database per client
Every account's data lives in its own database with its own access credentials, not in a shared table with a separator column. A mistake in a query cannot show someone else's row, because other rows are not in the database at all. The separation happens at the connection level, before any query runs.
Row level isolation
Inside the database a second lock is at work: PostgreSQL row level security. Each connection declares which account it acts for, and the database itself cuts off everything else. Even a badly written query cannot step outside the account, because the policy is enforced by the database rather than by the application.
Nightly backups
At 03:30 Moscow time dumps are taken of every database: each account separately, the service database and the sign-in records. The files are encrypted and go to a separate object storage with its own pair of keys — the application itself has no access to that storage. Copies are kept for about thirteen months, and the same nightly run removes the old ones.
Servers in Russia
The application, the databases and the file storage sit on servers in Russia. Data does not leave the perimeter and is not handed to foreign clouds for processing.
Roles and permissions
Access to sections and actions is set by roles, and data visibility is further limited by legal entities: an employee sees the companies they are cleared for. Permissions are checked on the server on every request, not merely by hiding buttons — a hand-picked address will not open someone else's section.
AI agents work with a person's rights
An agent connects over the MCP protocol on behalf of the signed-in employee and receives exactly the same rights: what the person cannot see, the agent will not see either. There is no separate key with access to everything, and every action an agent takes stays in the account history and is reviewed like a person's action.
Files
Attachments, documents and screenshots live in object storage with separate folders per account. A link to a file is issued for a limited time after a permission check, so an address copied from the browser does not turn into permanent public access.
What happens during a failure
One service going down does not take the others with it: sections work independently. If data is lost, an account is restored from the nightly copy — separately from the others, because its copy is separate too. Restoring one client does not require stopping work for the rest.
Where we do not go ourselves
Development staff do not work inside a client's account at will: access to the data is needed to investigate a request and is asked for from the client. Backup encryption keys sit on a server with restricted permissions, not in the repository and not in correspondence.
See Akeda
with your workflow.
Tell us what you want to connect or automate. We will show how the process could work in Akeda, what data it needs and where to start.
- 01Understand your needs
- 02Explore connected workflows
- 03Define the next step
Request received
Thank you! We have your number and will get in touch on the next working day.
What happens next: a short conversation about your process — what to connect, which data is needed and where to start. No sales pitch.