Security
Security at Almure
Our threat model, responsible-disclosure process, and the controls built into the platform by construction — not bolted on.
Threat Model
What we protect against
Almure's enclave boundary is designed to address four primary threat vectors in regulated AI workload deployments.
Insider threat
A privileged operator or cloud provider employee with root access to the host OS. Hardware memory encryption means enclave contents are never visible even to operators with physical or OS-level access.
Cloud provider access
The hypervisor or management plane gaining visibility into workload memory. Enclave memory pages are encrypted at the CPU memory controller before they leave the die — the hypervisor sees only ciphertext.
Network interception
Data in transit between the caller and the enclave being intercepted. All channels are encrypted with enclave-derived keys; the attestation report allows the caller to verify they are communicating with the correct enclave before sending data.
Compromised host
An attacker who has fully compromised the host OS or hypervisor. Hardware isolation is enforced below the OS level; a fully compromised host cannot read or modify enclave memory, cannot inject code, and cannot forge the attestation report.
Controls
Controls by construction
| Threat | Almure control | Hardware backing | Audit evidence |
|---|---|---|---|
| Insider / host OS access | Hardware memory encryption; enclave memory never decrypted outside CPU die | Intel TME-MK / AMD SME | mrenclave in attestation report |
| Hypervisor inspection | Nested page-table protection; EPT/NPT marked as encrypted for enclave pages | Intel TDX / AMD SEV-SNP | Platform attestation certificate from hardware vendor |
| Network interception | Channel encrypted with enclave-derived key; caller verifies attestation before data send | Key derivation inside enclave | Attestation report signed by hardware key |
| Code substitution | Pre-execution measurement; measurement hash in attestation report is hardware-signed | CPU measurement before first instruction | mrenclave + isvsvn in attestation log |
| Key exfiltration | Keys derived inside enclave; never exist in clear outside hardware boundary | Hardware sealing key (PCK-derived) | Key lifecycle events in audit log |
Responsible Disclosure
Reporting security issues
How to report
If you believe you have identified a security vulnerability in the Almure platform, SDK, or documentation, email [email protected]. We triage all security reports and respond within 72 hours with a severity assessment and next steps.
We operate a 90-day coordinated disclosure window. We will work with you to reproduce the issue, assess impact, develop a fix, and coordinate public disclosure timing. We do not pursue legal action against researchers who disclose in good faith and give us reasonable time to respond before publication.
For reports involving sensitive technical details, use PGP encryption. Our public key is available on request at [email protected]. We treat all reporter identities as confidential unless you indicate otherwise.
Note: we do not operate a bug bounty programme at this stage. We will acknowledge all researchers who disclose valid vulnerabilities in our public changelogs.
We design the Almure platform with reference to APPI and FISC security guidelines for financial institutions. We do not claim any formal certification. Compliance determination remains with the deploying organisation.