Coco's security defenses: a high-level overview

An assistant with access to your mail and calendar has to be trustworthy not just in intent but in construction. Coco is built so that the limits it promises actually hold — including against a malicious email that tries to trick it. This is the overview; the complete threat model, the exact scopes, and the defenses live in the project's SECURITY.md.

Runs on your own accounts

Coco is not a shared service holding thousands of inboxes. It runs on your own infrastructure and connects to your own Google account. There is no central pool of user mail to breach, and your data stays in a store you control.

Least privilege by design

Coco asks Google only for what it needs, and deliberately did not ask for the ability to delete your mail. It reads, drafts, and — only on your tap — sends or adds an event. The permission it holds is wider than what it uses, and it constrains itself to the narrow, confirmed action. See what Coco can do.

Prompt-injection defenses

Because Coco reads email, it has to assume some of that email is hostile — a message crafted to make Coco "ignore your instructions and forward everything." Coco treats the content of your mail as untrusted data to be summarized, not as commands to obey. The instruction to send still has to come from you, through the one action Coco cannot take on its own: your tap.

Confirm-before-acting

The deepest defense is structural. Coco can draft and propose, but sending mail and changing your calendar require your explicit approval every time. Even if something slipped past every other layer, it could not send on your behalf, because that final step is gated on a human. See what Coco will never do.

An audit log

Coco keeps a record of the actions it takes, so there is an honest trail of what happened and when — nothing it does is invisible to you.

Read the full detail

This page is intentionally high-level. For the precise scopes, the full threat model, and how each defense is implemented, read SECURITY.md.