Approved-source boundary
Answers should be grounded in explicitly approved material with ownership, version and access state attached.
Security
Trust begins with a boundary.
This page describes AEI Labs’ intended security posture at a product-principle level. Deployment-specific controls, certifications and contractual commitments will be published only after verification.
Pre-launch security statement · technical verification required
What the architecture is designed to control.
Tenant and role isolation
Institutional and enterprise deployments are intended to enforce access boundaries before retrieval. The deployed implementation must be independently tested.
Prompt-injection resistance
Retrieved content is treated as untrusted input. Injection fencing and claim verification form part of the release path described in the architecture.
Durable answer records
The system is designed to retain the answer, evidence, verdict and relevant version information for later review.
Independent verification
Exported evidence records are intended to be checkable independently of the application that produced them.
Report a vulnerability
A dedicated security contact and disclosure SLA must be configured before launch. See responsible disclosure.
Still to publish
Controls need evidence.
Before this becomes a definitive security statement, AEI Labs must confirm hosting regions, encryption, identity providers, retention and deletion, backup controls, incident response, subprocessors, vulnerability handling, penetration testing and certification status.