Home › Security
Security by construction, explained without adjectives
This page describes mechanisms, not promises. Each paragraph names something the server enforces on every request, and where a limit exists, it says so.
Prices are published at launch; every account starts with a trial. No card to start.
Tenancy
Every record belongs to an organisation and every query is filtered by it. A person reaches a workspace only through a membership with a role, and the role's capabilities are compiled on the server for each request. A screen hidden in the navigation is also refused by the API; the two are generated from the same manifest.
Approvals bound to plans
An action is planned first: the plan is stored, its risk class and approval level decided by a registry, and its preview built from the stored row — the same row that will execute. An approval is bound to that row. Minutes later, at execution, the gates are re-run: role, approval validity and expiry, budget, and parameters. Authority is never older than the action it authorises.
Model output is untrusted
The Assistant's model may answer and may propose one action from a list the server built for the person's role. The proposal is re-validated on the server — the name must be in that list, the parameters are filtered to the action's own fields — and then planned like any other request. A malformed answer fails closed: nothing is executed on it. Content from email, web pages and documents reaches the model fenced as data, never as instructions.
Cost control on the server
Every model call is made through one door with an explicit model, a ceiling on calls, tokens, time and cost per task, and a budget window per workspace and plan. Usage is recorded per call with the model, the route and the actual cost, and the window is checked before the next call. A limit is a refusal with a reason, not a silent truncation, and nothing purchases capacity automatically.
Identity and sessions
Passwords are hashed with a modern key-derivation function; verification and reset links are single-use and expire. Tokens carry an audience naming the service they are for, so a token for one AOFON product is not a session in another. Sign out everywhere and password resets revoke every earlier session.
What this page does not claim
No audit report, attestation or compliance badge is claimed here. When one exists it will be linked from this page with its scope and date. Automated checks have a ceiling; this product's own release notes say what was measured and what was not.
Questions people ask
Can the Assistant delete data?
Deleting customer records is a destructive action with an owner-level approval; it is never proposed by the model and never executed without that approval.
Can it spend money?
Payments, refunds and ad spend are financial actions requiring financial approval and are limited per plan; the model never executes them.