Security

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.

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

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 body is operator-blind by construction. The memory never leaves the user's machine, and our cloud only ever handles ciphertext sealed by a key derived from the user's own Aedelgard key — we cannot read it, not as policy but as physics. Prompts travel directly from the user's machine to the model provider they chose (never through us); with a local model, nothing leaves the machine at all.
• The hosted cloud broker is operator-blind at rest, but not in-flight. Memory and keys are envelope-encrypted at rest and per-tenant isolated, but during a request the broker decrypts what it needs in memory to run inference. We do not log prompts, train on your data, or browse it — but a compromise of the running process could, in principle, see in-flight plaintext. We say so on the same page, in the same voice.

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.