Architecture Overview
Attest and Trace are different platforms solving different problems, compliance evidence and AI governance evidence , but they share the same foundational architecture: automated collection, tamper-proof storage, cryptographic chaining, and independent verification. This shared evidence infrastructure is what makes both platforms provable, not just functional.
make security evidence trustworthy enough for insurers, auditors, regulators, and courts, not just internal dashboards.
Evidence is written once and cannot be changed. There is no update operation and no delete operation at any layer. If evidence needs correction, a new record is appended , the original is never modified. This is enforced at the storage level, the database level, and the application level simultaneously.
Every evidence record is hashed and linked to the previous record in a per-tenant chain. Each tenant has its own independent chain. If any record in the chain were altered, all subsequent hashes would become invalid. Tampering is mathematically detectable.
Reports generated from evidence carry the chain reference and can be verified through a dedicated endpoint. Verification does not require platform access or trust in APEXLyn. It requires mathematics. An insurer scanning a QR code on a report can confirm its authenticity independently.
Neither platform accepts manual uploads for technical evidence. Evidence arrives through secure, tenant-bound connectors on policy-driven schedules. If a connector fails or evidence is unavailable, the gap is recorded honestly as insufficient evidence — never fabricated to fill a hole.
Both platforms collect evidence from different sources, process it through their own engines, and commit it to the same class of immutable evidence infrastructure. The shared architecture means shared trust, shared verification, and shared proof standards.
Attest collects compliance evidence from connected systems, Microsoft 365, Active Directory, AWS, Azure, Google Cloud, CIS scanners, backup software, EDR platforms, and Google Workspace. Each connector is tenant-bound and uses the minimum required permissions. Evidence is collected on a policy-driven schedule: a full baseline at onboarding, then recurring collection at defined intervals.
Collected evidence passes through the Attest compliance engine, which evaluates it against universal controls using versioned control rules. Controls are stable and framework-independent, frameworks are views mapped onto these controls. The engine produces a canonical status for each control (PASS, FAIL, UNKNOWN, NOT_ASSESSED, or EXCEPTION) with confidence calibration: PASS requires HIGH confidence based on evidence presence, freshness, completeness, structural validity, source validity, and scope match.
Framework mapping then renders the control results as framework-specific posture: Essential Eight maturity levels, ISO 27001 clause compliance, NIST CSF subcategory status, APRA CPS 234 requirement status, and so on. Adding a new framework requires loading requirement definitions and mapping rules, not changing the platform code. The engine commits all evidence and assessment results to the immutable evidence infrastructure.
Trace collects AI governance evidence across seven enforcement layers: browser extension, endpoint agent, network gateway, API interceptor, cloud application connectors, AI output inspection, and internal LLM API protection. Each layer monitors a different way AI tools can be accessed.
When an AI interaction is detected, it passes through an eight-stage classification pipeline: preprocessing, deterministic validation, semantic classification, prompt injection detection, context enrichment, file and image inspection, output classification, and policy resolution. The resolved action, block, warn, redact, educate, audit, or allow, is executed immediately.
Every governed interaction produces a forensic evidence record containing: tenant identity, event identity, timestamp, source layer, user reference, action taken, severity, policy reference, data classification results, destination summary, hash references, and lineage. This evidence is committed to the immutable evidence infrastructure using the same proof model as Attest, WORM storage, SHA-256 hashing, and per-tenant hash chaining.
Trace also integrates bidirectionally with existing security platforms (SIEM, XDR, EDR, ITSM, alerting, GRC), sending AI-specific findings to the customer's existing tools while receiving risk signals back where supported.
Attest and Trace share the following architectural foundations:
Immutable storage: Both platforms write evidence to WORM (Write Once, Read Many) storage. Once written, evidence cannot be altered or deleted at the storage level. This is an infrastructure guarantee, not an application-level restriction.
Cryptographic hash chaining: Both platforms maintain per-tenant hash chains where each evidence record includes the hash of the previous record. Chains are independent per tenant — no cross-tenant chaining exists. Tampering with any record invalidates all subsequent hashes.
Governance proof model:Both platforms record governance actions (attestation, risk acceptance, policy approval) as immutable signature events in the evidence ledger. Each signature event contains the actor's identity, role, timestamp, IP address, related evidence references, and scope context.
Report verification: Both platforms generate reports whose hashes are recorded in the evidence ledger. Reports can be independently verified through a verification endpoint or QR code without platform access.
Australian data residency: Both platforms host all data in AWS Sydney (ap-southeast-2). No cross-region replication. No offshore processing.
Tenant isolation:Both platforms enforce tenant isolation at the database level. Evidence chains are per-tenant. Connectors are tenant-bound. No tenant's data can be accessed by another tenant.
Retention and legal hold: Both platforms support 7-year default retention (tenant-configurable) and legal hold that overrides deletion.
Evidence in both platforms follows a defined lifecycle. Each stage adds trust. No stage can be skipped or reversed.
Evidence is collected automatically through secure, tenant-bound connectors. Each connector uses the minimum permissions required. Collection runs on a policy-driven schedule , baseline at onboarding, then recurring at defined intervals. No manual uploads for technical evidence.
Collected evidence is committed through a strict, deterministic sequence. The raw payload is written to WORM storage first. Then a SHA-256 hash is computed. Then the evidence record is created. Then the hash is chained to the per-tenant ledger. Only when all steps complete successfully is the evidence considered committed. If any step fails, the evidence is not recorded as committed.
Committed evidence is evaluated against controls and policies. Attest evaluates against universal controls mapped to compliance frameworks with confidence calibration , PASS requires HIGH confidence. Trace evaluates against AI governance policies with a staged classification pipeline. Both produce canonical status outputs.
Human decisions about evidence , attestation, risk acceptance, policy approval , are recorded as immutable governance signature events in the evidence ledger. Each signature event contains the signer’s identity, the evidence it relates to, and the scope context. Governance events are permanent and verifiable.
Evidence, assessment results, and governance records are assembled into structured reports. Each report’s hash is recorded in the evidence ledger at the time of generation. Reports include assertion statements describing what was assessed and non-assertion statements describing what was not. Reports carry chain-of-custody statements and can be independently verified.
Reports can be verified by any authorised reviewer through the verification endpoint or QR code. Evidence can be exported in controlled bundles for legal proceedings, regulatory submissions, insurance claims, and audit reviews. Legal hold preserves evidence beyond normal retention when required by law or litigation. Forensic evidence packs include digital signatures, chain-of-custody attestation, and verified entry hashes.
Both platforms are hosted entirely in AWS Sydney (ap-southeast-2). This is not a configuration option that can be toggled off. It is enforced at the infrastructure level through technical controls that prevent data from leaving the Australian region.
This matters because Australian organizations — particularly in healthcare, legal, financial services, insurance, and government — are increasingly expected to demonstrate that their data remains in Australian jurisdiction. Self-certification is no longer sufficient for many regulated industries. APEXLyn provides infrastructure-level enforcement that can be independently verified.
| Control | Implementation |
|---|---|
| Primary region | AWS Sydney (ap-southeast-2) |
| Cross-region replication | Blocked entirely |
| Evidence storage | Region-locked WORM storage with bucket policies enforcing ap-southeast-2 |
| Database | Private subnets only. No public internet exposure. |
| Database access | VPC endpoint access where feasible |
| Logging and monitoring | Australian-region only (CloudWatch in-region) |
| Audit logs | Australian-resident. Immutable. 7-year retention. |
| Third-party processing | No out-of-Australia processing unless explicitly approved and recorded as a governance event |
| CI/CD artifacts | Any artifact containing customer data remains AU-resident |
| Encryption at rest | AES-256 via AWS KMS |
| Encryption in transit | TLS 1.3 |
Every organization on APEXLyn operates in a fully isolated tenant. Your evidence, your assessments, your governance records, your reports, and your configuration are completely separated from every other organization on the platform.
This isolation is not enforced by application logic alone. It is enforced at the database level, the storage level, the evidence chain level, and the API level simultaneously. A failure in any single layer does not compromise isolation because multiple independent enforcement mechanisms operate together.
Database isolation: Row-level security (RLS) is enforced at the PostgreSQL database layer. Every query is scoped to the authenticated tenant. Cross-tenant data access is rejected and logged.
Evidence chain isolation:Each tenant has its own independent hash chain. No cross-tenant chaining exists. Evidence from one organization never enters another organization's chain.
Connector isolation: Every connector instance is bound to a specific tenant. Connector credentials and tokens are stored per-tenant and isolated.
API isolation: Tenant context is derived from authenticated claims (JWT/session), not from client-provided identifiers. Any request attempting cross-tenant access is rejected and logged.
MSP isolation: MSP access to client tenants is explicitly assigned per client. No MSP has default access to all tenants. If an MSP is suspended, access is revoked immediately across all assigned tenants.
Audit isolation: All tenant-scoped actions are audit-logged with tenant context. The audit trail is immutable and Australian-resident.
Database , row-level security per tenant
Storage , per-tenant evidence chains
Connectors , tenant-bound credentials
API , server-derived tenant context
MSP , explicitly assigned, instantly revocable
Cross-tenant access is rejected and audit-logged at every layer
Both platforms enforce a zero-trust access model. No action is permitted unless explicitly authorised. Every sensitive action requires MFA re-verification. Every access is logged.
Platform hierarchy:
Super-Admin (Platform Owner) , MSP (Partner) , Client (Business) , User (Employee)
RBAC roles within a tenant:
Admin , Approver , Reviewer , Viewer
All authorisation decisions are server-side. The UI presents what the server authorises — it does not decide what to show based on client-side logic. Deny-by-default means every endpoint and every action must explicitly allow a role. If a role is not explicitly allowed, access is denied.
| Control | Specification |
|---|---|
| MFA | Required for all tiers. TOTP and WebAuthn/FIDO2 supported. |
| MFA re-check | Required for: exports, approvals and attestations, connector changes, scope changes. |
| Session idle timeout | 15 minutes |
| Absolute session lifetime | 8 hours |
| Refresh token max lifetime | 24 hours |
| Token rotation | On every refresh. Immediate family invalidation on reuse detection. |
| Break-glass access | Maximum 2 accounts. FIDO2 hardware key required. Default 60-minute window. Maximum 4 hours. Audit-logged with high-severity event. |
| MSP suspension | Immediate access revocation across all assigned tenants. |
| Audit logging | Immutable. Australian-resident. 7-year retention. Covers: authentication, session lifecycle, role changes, connector changes, evidence ingestion, export generation, governance actions. |
Every report generated by Attest or Trace can be independently verified. The verification process does not require the reviewer to trust APEXLyn , it requires the reviewer to trust mathematics.
When a report is generated, its hash is recorded in the evidence ledger. The verification endpoint accepts a report identifier and returns metadata confirming whether the report is genuine and unaltered. The reviewer does not need platform access, does not need an account, and does not see any tenant data beyond the verification result.
An insurer receiving a report can scan the QR code to receive independent confirmation of authenticity. The audit trail is mathematical, ensuring transparency without compromising tenant privacy.
The endpoint returns only verification metadata. No tenant data, evidence records, or user information is exposed during the process.
Attest does not hard-code compliance frameworks into the platform. Instead, it maintains a set of universal controls — stable, framework-independent evaluation points. Compliance frameworks are views mapped onto these controls.
This architecture means:
A single universal control, such as "MFA enforced for all users", can simultaneously satisfy requirements in Essential Eight, ISO 27001, NIST CSF, CIS Benchmarks, and APRA CPS 234. The control is evaluated once against the evidence. The result is rendered through each framework's trace.
Adding a new framework, a new version of the ISM, a new APRA guideline, or an international SOC 2, requires loading requirement definitions and mapping rules into the engine. It does not require changing platform code or rebuilding the assessment engine.
Framework versions are tracked and reports are bound to the exact framework version, mapping rules version, and control rules version active at the time of assessment. Historical reports remain bound to the versions they were generated under, even as frameworks are updated. This means a report generated in March 2026 against ISM March 2026 remains valid and interpretable regardless of future ISM updates.
Assessment is confidence-calibrated. A control produces PASS only when the confidence level is HIGH, meaning the evidence is present, fresh, complete, structurally valid, from the correct source, and within scope. If any condition is not met, the result is UNKNOWN (insufficient evidence), never PASS. Missing evidence never produces a passing result. This is a hard platform rule that cannot be overridden.
If you are evaluating APEXLyn for an enterprise, government, insurance, or regulated-industry deployment and need detailed security documentation beyond what is published here, we can provide it under appropriate review.
Request security documentationAvailable to qualified evaluators. Covers: detailed architecture, data handling, evidence schemas, connector specifications, assessment methodology, and operational controls.
From a 10-person medical practice to a federal government agency. From Essential Eight to ASD ISM. From basic compliance evidence to forensic proof. One architecture. Two platforms. Designed for Australian operating conditions.
