Home › Security
Security by construction, explained without adjectives
This page describes mechanisms, not promises. Each paragraph names something the server enforces, and where a limit exists, it says so.
Every account starts with a five-day trial. No card to start; prices are on the pricing page.
Tenancy
Every record of a company's work belongs to an organisation and every query for one is filtered by it; a person's own rows — their account, their sessions, their acceptance of the terms — belong to the person instead. 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 feature your role does not carry is never quietly missing from the navigation: it is listed and locked with the reason, and the API refuses it too, because the lock and the refusal read the same capability set. Plan allowances — seats, connectors, automations, memory entries, custom roles — are counted on the server at the endpoint that spends them, never in the browser.
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 rather than as instructions. A fence is a marker, not a proof, and the guarantee sits downstream of it: nothing arriving that way can start an action on its own, and the worst an injected sentence can do is name an action the person's role already allows, which is then previewed and gated like any other.
Cost control on the server
Every language-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. One thing sits outside that door: the optional embeddings helper that improves recall in company knowledge, which is off unless an operator configures it and costs a fraction of a cent per entry.
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?
Not by itself. Deleting customer records is declared as a destructive action with an owner-level approval floor, and the model is not allowed to propose it at all — but it also has no driver behind it, so AOFON refuses it by name rather than deleting anything. People delete their own workspace's records through the screens, where the server checks their role first.
Can it spend money?
No. AOFON cannot take a payment, issue a refund or spend an advertising budget: none of the three has a driver, and AOFON refuses each by name rather than guessing or simulating execution. The model cannot even propose them — financial actions are excluded from the list it may choose from. The financial approval level, and the per-plan ceilings on a single action and on a day's external spending, are real and are enforced today on every financial action; they will govern these three if they ship.