Security & access

Built to a standard your IT auditor can test.

Most systems enforce access in the application, which means a bug in one screen can expose data that screen was never meant to show. Ours is enforced in the database itself.

Permissions · enforced in the databasenot in the screen
Branch managerown branch onlysees 1 of 6RLS
Purchasing managerorders, not the ledger12 of 217 toolsRLS
Accountantledger, not payroll84 of 217 toolsRLS
Ownereverything, loggedallRLS
Tenant 2 reading tenant 1tested every build0 rowsdenied
Role stored inmemberships, never the token
ACCESS LOG17/09 09:41 · purchasing manager
Asked“show me the payroll”
Toolpayroll_register
Permissionpayroll.read
Held by this roleno
Rows returned0
REFUSEDby the database
Recordedwho, what, when
Not by the prompt, and not by the screen
What it is

Row-level security, role-based access down to the individual action, an append-only audit trail, and a controls page that runs itself against your live data.

How it works

What it actually does.

01

Enforced underneath, not on the screen

Row-level security on every table, so a report cannot show a row you are not permitted to see even if it was written carelessly. The AI obeys the same rules and has no privileged back door.

  • Access per company, per site, per action — any combination.
  • Nobody can grant a permission they do not hold themselves.
  • Staff who move are handled: covering another branch this week means seeing it this week.
AttemptedByResult
Read the trial balanceWarehouse supervisorNo rows returned
Approve own requisitionBranch managerRefused
Edit an approved orderPurchasingRevise instead
Void a posted receiptShift supervisorReverse instead

Four real attempts, four refusals, all of them from the database rather than from a screen. A check that only lives in the interface is decoration.

02

An audit trail that cannot be edited

Append-only, enforced by the database. Nobody — including us — can quietly remove a row, and every change carries who and when.

  • Every action has a name on it: no shared logins, no generic accounts.
  • Approvals record the person, the reason and the time, permanently.
  • A lost phone is not an incident — nothing lives on the device.
Recorded, permanently
14:02Setting changedApproval threshold, by the ownerrecorded
14:18Permission grantedPayroll view, to the controllerrecorded
15:40Period closedAugust, with a written reasonrecorded
16:22RefusalTrial balance, warehouse supervisorrecorded

Including the refusals. An audit trail that only records what succeeded is half a trail.

03

Controls that prove themselves

The controls page runs every rule against your live data at the moment you open it. One check genuinely attempts to delete a posted ledger line and quotes the refusal.

  • Nothing on that page is a stored result, which is why it is worth showing an auditor.
  • Hosted in-region, encrypted in transit and at rest, point-in-time recovery.
  • Your data leaves when you say — everything, any time, in open formats, at no charge.
Questions

The ones people ask about this.

Where is our data hosted?

In region, on managed infrastructure, encrypted in transit and at rest, with point-in-time recovery measured in minutes rather than to last night’s backup.

Can we get all our data out?

Yes — everything, any time, in open formats, at no charge. A system you cannot leave is a system you do not own.

Can you see our data?

Only where you grant it, and every access is logged the same way anybody else’s is.

Is there a report we can give our auditor?

The controls page itself, run live in front of them, plus the audit trail and an export pack of the trial balance, sub-ledgers and the documents behind them.

See it on your own figures.

Bring one ordinary day from your business and we will run it through in front of you, on your own items and your own prices.