Trust & Security

AIEP’s trust and security model is enforced by cryptographic invariant, not policy assertion. This section covers the trust record schema, security architecture, hardware security layer, and audit surface.

Trust Model

Trust →

Every step in an AIEP workflow produces a committed trust record. Trust is not a score or a rating — it is a machine-verifiable audit trail linking every output to the artefacts, certifications, and governance decisions that produced it.

The trust record chain for any AIEP output can be replayed by any node from the committed artefacts and verified to produce an identical hash.

Trust anchors

• GENOME_LOCKFILE.json — the trust root for any production AIEP deployment. Carries a cryptographic commitment to the kernel version in force.
• Certification registry — the canonical registry of certified publishers and their CertificateHash values.
• Constitutional parameters — versioned, committed, non-editable after execution.

Security Architecture

Security →

AIEP’s security model has two layers: software-enforced invariants (all tiers) and hardware-enforced invariants (Tier 3+).

Software invariants

• Fail-closed by default — any computation that cannot be verified is non-executable. There is no error-handling path that permits execution of an unverified artefact.
• Deterministic state machine — the arbitration layer is a formal state machine. Given identical inputs, every node produces identical output. Divergence between nodes is detectable and committed.
• Non-erasable ledger — committed artefacts cannot be modified or deleted. Retraction is a separate committed record, not an edit.

Hardware invariants (Tier 3+)

The hardware security layer (P09R / GB2519826.8) provides hardware-enforced anonymisation and attestation.

The key property (P91): the DeviceHardwareSecret lives inside the governance chip isolation enclave and is never accessible to software. Hardware-enforced anonymisation cannot be broken by any software instruction, operating system call, or network interception. This property is categorical.

• HardwareAttestationRecord — chip-level proof that a governance operation was executed on authentic AIEP hardware
• AnonymisationProof — cryptographic record that PII was excluded at hardware level

Hardware-enforced anonymisation is the only technically credible response to the data sovereignty requirements emerging from regulated jurisdictions.

Audit

Audit →

The AIEP audit export (AiepAuditRecord) is a complete, machine-readable record of:

• Every evidence artefact consulted in a session
• Every admissibility gate decision
• Every constitutional parameter in force
• Every trust record produced

The audit record is cryptographically sealed — it cannot be partially exported without breaking the commitment. A regulator receives either the complete audit record or a verifiable rejection.

Audit export is available from the GENOME SDK governance layer and from the machine interface:

GET /aiep/v1/audit/{session_id}
    → { artefacts[], gate_decisions[], const_params{}, records[] }

Regulatory governance

Regulatory Governance →

AIEP’s fail-closed admissibility gate, deterministic state machine, and non-erasable ledger are designed to satisfy the audit and accountability requirements expected under:

• AI Act — explainability, traceability, transparency
• NHS AI Code of Conduct
• Financial Services AI Governance frameworks (multiple jurisdictions)
• Sector-specific AI governance requirements (legal, clinical, defence)

The compliance page carries the full checklist:

→ Compliance →

Related

• Certification & Registry — publisher trust anchors
• Compliance — regulatory framework and compliance checklist
• Admissibility & QA — the fail-closed gate that enforces security invariants
• GENOME & Swarm — SDK and hardware layer access