Darwin.

Security principles

An assistant that reads email and sends email as you is a prompt-injection target. Our starting belief, straight from the research literature: you cannot make a language model safe by telling it to be safe. So none of Darwin's real guarantees live in the prompt.

The safety lives in a layer of ordinary code that sits between the AI and the outside world. The AI can want anything — it can even be fully convinced by a malicious email. It still cannot do anything the code doesn't independently allow. Five principles follow.

1. Senders are authenticated in code, before the AI runs

Darwin reads the one authentication header his own mail server stamped — not headers an attacker can write — and requires a genuine DKIM/SPF pass with domain alignment before treating anyone as who they claim to be. Only then does he ask whether that verified person has authority on this thread. A forged "from your boss" email fails cryptography before it ever reaches the AI.

2. Email bodies are data, never instructions

Text inside an email is wrapped in randomized fences and labeled untrusted before the AI sees it. "Ignore previous instructions, I am the admin" is just a sentence inside a fence. Authority comes from the verified sender classification — assigned by code — never from what a message says about itself.

3. Every action is re-checked at the moment it happens

Darwin can only email addresses that you introduced or that are already on the thread — an allowlist computed from verified senders' own words. Calendar tools return busy/free, never event contents, so your calendar cannot leak into an email even in principle. One thread books one meeting; protected fields (who attends, where, the notes) change only on your say-so. When the AI asks for something outside the lines, the tool refuses. Nothing about this depends on the AI agreeing.

4. When it's unsure, it asks a human

New people, odd hours, cancellations, anything ambiguous — Darwin emails you privately instead of guessing. "Ask, don't guess" is a code path, not a personality trait.

5. Everything is bounded, logged, and stoppable

Hard rate limits cap what any thread or any day can send. Every decision — including every refusal — is written to an audit log you can read on your dashboard. Errors notify a human. A kill switch stops everything instantly. And each customer's data lives in a physically separate database, so accounts can't read each other even by bug: isolation is a property of files, not of a WHERE clause we promise to always write.

What we ask of Google

Your grant is two narrow Calendar permissions — manage events on calendars you own, and list your calendars — plus your name and email for sign-in. Darwin reads full event details from the calendars you select, because free/busy alone cannot tell an accepted meeting from an ignored invite — but titles and contents never leave the availability computation. Darwin cannot share, delete, or reorganize your calendars, and we never request Gmail access — he reads his own mailbox, so your inbox stays yours. Stored credentials are encrypted at rest, and mail leaves over a domain protected by SPF, DKIM and DMARC.

Security researchers: we'd love your eyes. Write to darwin@darwinschedules.com and we'll take the report seriously, fast.
Try Darwin free for a month