Security and trust
What is implemented, and what has not been independently verified
The controls below are built and tested by us. No third party has reviewed them. Both halves of that sentence matter, and this page keeps them together.
No penetration test, code audit or third-party security review has been carried out, and no certification of any kind is held. Security controls are described here as implemented and self-tested. An organisation with a meaningful security bar should require an independent assessment before production use, and we will not describe the platform otherwise until one has taken place.
Tenant separation
Separation between customer organisations is enforced at the data access layer rather than in each individual query. Every read is automatically constrained to the active tenant, and every write is stamped with it.
The consequential design choice is what happens when no tenant context is set: the query raises an error rather than returning everything. A developer who forgets the context gets a failure in testing, not a data leak in production. Cross-tenant access attempts are covered by tests that assert a denial rather than an empty result, because an empty result would look identical to a filter that had silently stopped working.
Access control
Permission-keyed, not role-keyed
Routes check for a specific permission, never for a role name. Adding a role cannot accidentally widen access, and a permission that no role can reach is caught by a test at build time rather than discovered by a user who cannot do their job.
Separation of duties
The person who runs an assessment cannot seal its verdict alone. An override towards a more permissive outcome requires a written reason, a distinct permission and a second approver. An override towards greater caution needs none of that ceremony, because requiring it would discourage caution.
External participants are constrained
Accounts marked as external are structurally barred from a defined set of permissions. The restriction is a property of the account, not a configuration someone can loosen for convenience.
Credentials
Passwords are hashed with a memory-hard algorithm and are never stored or logged in any recoverable form. Session tokens are short-lived, and the web interface holds them in cookies that browser scripts cannot read, so a cross-site scripting flaw cannot lift a session.
Records and integrity
| Control | What it provides |
|---|---|
| Hash-chained audit log | Every consequential action is recorded, and each entry incorporates the hash of the one before it. Removing or editing an entry breaks the chain and is detectable. |
| Append-only records | Answers, decision runs, verdicts and released reports cannot be edited. A correction is a new record that supersedes the old one, leaving the original visible. |
| Report integrity hashes | Released reports carry a hash of their content, so a reader can confirm the document has not been altered since release. |
| Sealed verdicts | A decision is sealed with its rationale, conditions, accountable owner and integrity hash. Superseding it creates a new record rather than changing the old one. |
| Frozen financial baselines | The forecast at approval is sealed, so later performance is measured against what was actually promised rather than a quietly revised number. |
| Version pinning | An assessment records the exact version of every content pack it used, so it can be re-run and reproduced years later. |
Data handling
- Data classification is carried through. Questions are marked by sensitivity, and confidential answers are treated accordingly throughout, including in exports and any optional AI assistance.
- Errors do not leak. Failures are logged with full detail server-side and returned to the caller as a code and a request identifier, with no internal detail in the response.
- No third-party scripts. This website loads no external JavaScript, fonts, images, trackers or analytics. A restrictive content security policy is served with every page, and there is nothing to consent to because nothing is collected.
- Rate limiting. Request limits apply to authentication and to the API generally, to reduce the value of credential guessing.
- Region stays region. There is no automatic currency conversion and no implicit movement of data between regional deployments.
Commercial independence
DUN-AI is built by mAIb Tech, which also implements technology. An assessment that could be steered towards a recommendation its author profits from would be worthless, so the separation is enforced the same way the AI boundary is.
- The decision engines cannot read commercial, vendor or contract data. A test inspects their imports to confirm it.
- An assessment, its recommendation, and any resulting implementation proposal are separate artefacts with separate approvals.
- Where a recommendation could lead to work for mAIb Tech, the report says so rather than leaving the reader to notice.
- A customer is free to take a DUN-AI recommendation to any supplier. Nothing in the product or its outputs depends on their not doing so.
Reporting a vulnerability
If you believe you have found a security issue, please report it before disclosing it publicly. Send details through the contact page, including the steps required to reproduce it. We will confirm receipt and keep you informed of the outcome.
There is no bug bounty and no formal disclosure timetable at this stage. Saying so is more useful than implying a process that does not yet exist.