AedelgardSecurity
Aedelgard is a memory you own. Its whole value rests on trust, so we treat security reports as first-class work, not a compliance afterthought. The full policy also lives in the open engine at SECURITY.md.
Report privately, before public disclosure:
Want to encrypt? Send a first, contentless email and we'll exchange a key.
Include, where you can: what you found, how to reproduce it, the affected component (engine / cloud broker / desktop body), and its impact.
What to expect
| Acknowledgement of your report | within 3 business days |
| Initial assessment + severity | within 7 business days |
| Fix or mitigation plan | as soon as it's understood |
We will keep you updated, credit you if you wish (or honour a request to stay anonymous), and we will not pursue good-faith researchers who follow this policy.
The honest trust boundary
We state this plainly on the architecture page and repeat it here because it is the truth your threat model should assume:
- The local desktop body with your own provider key sends prompts directly to that provider; Aedelgard is outside the inference path. Prompts and context travel directly from your hardware to your chosen model provider (Anthropic, OpenAI, Gemini, or a local offline model).
- The hosted cloud broker carries encrypted memory only — Aedelgard does not serve model inference. Your memory vault records are envelope-encrypted at rest and during sync (AES-256-GCM) with a key derived from your Aedelgard key. We do not log prompts, train on your data, or browse it.
Especially wanted: tenant-isolation escapes, device-token forgery, vault-at-rest weaknesses, and anything that would let plaintext leave a user's machine when they run the local body. If a claim anywhere in the product contradicts our privacy statement, the claim is the bug — tell us.
Artifact integrity
Every desktop release publishes SHA256 checksums at aedelgard.com/checksums and on each GitHub release. Verify before you install.