In short
AI employees produce proposals; a person with the right to decide accepts them. Every change goes to a journal the application cannot erase, each company’s data is isolated by the database itself, and the whole AI layer can be stopped at once.
More detail
This page describes the control mechanics, not intentions: each statement is backed by the product code and its tests.
What an AI agent can and cannot do
- An agent produces a draft — an answer, an assessment, a classification or a recommendation. It goes to the queue of a person who has the right to accept it; until then it has no consequences for anyone. There is no route in the code by which a proposal executes itself.
More detail
- Each agent has a closed list of tools: which data it reads and which proposals it makes is set in a registry and checked on every run. An area that is not on its list is not read, even if it exists in the database.
- As shipped, every agent is switched off and its budget is zero. The owner assigns a budget and switches it on — both actions require re-entering the password and are written to the journal. The spend cap is checked before a run, not after.
Who sees what and who approves what
- Permissions are a closed registry: a permission does not exist until it is written, and access checks refuse by default instead of allowing.
More detail
- High-risk actions — changing access, configuring an agent, lifting a stop — require entering the password again, even in an open session.
- The author of a change cannot approve it, the server refuses to raise one’s own permissions, and the last owner of an organisation cannot be removed.
What is recorded and cannot be erased
- Every change goes to the journal: who, what, when, on which record and with what result. A separate test suite asserts that no changing route is left without a journal record.
More detail
- The application cannot delete journal records: the rights are revoked in the database itself, and an attempt is rejected by a trigger. This is protection by permissions and backups, not a cryptographic chain.
- Passwords, keys and tokens are masked when they enter the journal, not when it is read.
Can one company see another company’s data
- Separation by organisation is enforced by the database on every table with company data: a query that forgot the organisation condition still does not see another company’s data.
More detail
- It is isolation between companies, not between projects: inside one company not every kind of data is separated by project — the approval queue is not, by design.
- Isolation is checked by tests that connect with the application role and try to read another company’s data, written for each kind of data separately.
When something goes wrong
- The emergency stop halts the whole AI layer at once — there is no need to work out which agent misbehaves. Only the holder of the policy permission can lift it, and the explanation stays in the journal.
More detail
- Spend caps, daily change limits and approval thresholds are checked before anything happens. A threshold nobody assigned blocks the action instead of letting it through.
- A sent message cannot be recalled, so an AI employee does not write to customers by itself: staff send the answer. Without staff, a visitor gets only a confirmed, word-for-word website chat answer — if the organisation switched it on and two people approved the auto-reply policy.
In detail
Five pages on the same topics, with the basis for every statement:
Basis: product documentation; the roles and permissions model. This page describes what exists in this build, not what is planned.