Trust centre · For a CTO, security engineer or technical reviewer
What is implemented, what is tested, and what is not yet assured.
This page is written for the person who will be asked to sign off the platform. It separates controls that exist and are tested from work that is scheduled, and names the limitations rather than leaving them to be discovered.
How to read the evidence status on this page
- Verified in product
- Implemented in the platform and covered by automated tests or recorded verification evidence.
- Controlled document
- Maintained as a version-controlled internal artefact, issued under agreement rather than published.
- In external assurance
- Scheduled with, or in progress with, an independent party. No external opinion is claimed until the report exists.
- Not claimed
- Deliberately not asserted. Stated openly so a reviewer never has to infer whether it exists.
| Claim | Status | What evidences it |
|---|---|---|
| Row-level authorisation enabled on every application table | Verified in product | Enforced in database policy and re-checked inside every server function. A repeatable verification script produces the table-by-table output for reviewers. |
| Automated test suite executed on every release | Verified in product | Unit, integration and end-to-end cases run headlessly against the source tree and a running build. Results are published in the summary below. |
| Response hardening headers on every document response | Verified in product | Content Security Policy, HSTS, framing, referrer and permissions policy are generated by a unit-tested module rather than set by hand. |
| Second-factor step-up for privileged actions | Verified in product | Enforced server-side from verified token claims for owner-level operations, not only in the interface. |
| Upload content-safety pipeline | Verified in product | Type, size, filename, structural and decompressed-size limits, applied server-side and failing closed on any check it cannot complete. |
| Coordinated vulnerability disclosure route | Verified in product | Published policy page plus a machine-readable security contact record at /.well-known/security.txt. |
| Threat model, controls register and vulnerability register | Controlled document | Version-controlled internal artefacts, issued to customers and assurance reviewers under agreement. |
| Independent penetration test by an accredited provider | In external assurance | Scope, readiness checklist and attack-surface inventory are prepared and a staging target is being provisioned. No independent test report exists yet, so none is claimed. |
| ISO/IEC 27001 or ISO/IEC 42001 certification | Not claimed | We map our operating controls to both standards and support customer-led review. We hold no certification and do not present one. |
Stated plainly
AIRAS Cloud has not yet been penetration tested by an independent accredited provider. Security testing to date is internal: automated suites, code review and targeted hardening against a documented threat model. Until an external report and its retest exist, no material issued by us will describe the platform as independently penetration tested.
Change control and release discipline
Product change moves through a governed, versioned release process with review before deployment. Rulesets, policy packs and control libraries are versioned separately from application code, so a governance change is itself an auditable event rather than a side effect of a deployment.
Release verification is a gate, not a report: the release script runs type checking, linting, the full automated suite, the evidence generators and the assurance inventory. A failing gate blocks the release.
Verification evidence
The summary below is generated from recorded evidence artefacts, so the published figures cannot drift from the runs that produced them. No proprietary scoring logic or ruleset internals are disclosed.
Client test summary sheet
Automated verification of the regulatory engines, the public site and the governance demonstration workspace, executed headlessly against the source tree and a running build. Every figure below is generated from the recorded evidence artefacts. No proprietary scoring logic or ruleset internals are disclosed.
- Cases in register
- 2014
- Passed
- 2014
- Failed
- 0
- Pass rate (executed)
- 100.0%
Engine and platform logic
Deterministic regulatory engines, discovery pipeline, access control and the published scoring illustration, executed against the current source tree.
Automated unit and integration suite · 1287 cases · 0 failed · executed 2 Sept 2026
| Suite | Cases | Result |
|---|---|---|
| AI-system qualification engine | 24 | All passed |
| Demonstration scoring illustration | 26 | All passed |
| Discovery detection and document pipeline | 143 | All passed |
| High-risk classification and impact triggers | 23 | All passed |
| Identity, tenancy and access control | 39 | All passed |
| Operator role assessment | 30 | All passed |
| Other verified modules | 791 | All passed |
| Regulatory framework and pipeline ordering | 31 | All passed |
| Regulatory obligations register | 15 | All passed |
| Regulatory validation corpus | 132 | All passed |
| Ruleset administration and notifications | 15 | All passed |
| Transparency screening (Article 50) | 18 | All passed |
Website and demonstration workspace
Public website, the gated governance demonstration workspace, the guided tour and the machine-readable surface, executed headlessly against a running build.
Automated end-to-end suite · 727 cases · 0 failed · executed 2 Sept 2026
| Suite | Cases | Result |
|---|---|---|
| Route availability | 53 | All passed |
| Metadata integrity | 318 | All passed |
| Structured data | 53 | All passed |
| Accessibility landmarks | 106 | All passed |
| Runtime health | 53 | All passed |
| Navigation | 5 | All passed |
| Machine endpoints | 5 | All passed |
| Security controls | 7 | All passed |
| Access control | 4 | All passed |
| Demonstration screens | 42 | All passed |
| Tool data integrity | 10 | All passed |
| Lead capture | 4 | All passed |
| Readiness assessment | 1 | All passed |
| Responsive layout | 12 | All passed |
| Performance budget | 53 | All passed |
| Session lifecycle | 1 | All passed |
Summary generated from the verification evidence on 2 Sept 2026 and published for evaluation and procurement purposes. The full case register, including expected and observed outcomes for every case, is available on request.
Running a technical due-diligence review?
Tell us what your reviewers need to see. We will issue the architecture detail, threat model, controls register and verification evidence under agreement.
No commercial commitment. No confidential information required.