Questions

The briefing is the product, and it does not exist in code yet. The intent is that twice a day Keelpost reads what arrived across every account you have connected and hands you a short list of decisions — a reply already drafted and ready to send, a stack of twelve to archive in one click, a rule worth adopting — with everything else summarised in a line, filed, and a sample of it offered back so you can correct it.

The site draws that in full and labels every drawing as a drawing. What runs today is the approval boundary underneath it: a server-rendered card on every change, drawn from the stored message rather than the model’s summary of it.

The briefing·Planned — not built yet

No, and there is no roadmap item for it — not at a paid tier, not behind a setting, not once it has behaved well for long enough. Sending and deleting always take a person approving that exact action, and neither can ever be part of an “approve all”.

Approving a send will send it rather than leaving you a second step, after a short visible delay with a cancel beside it. The consequence is deliberate and worth stating: if you never open the briefing, your mail goes unanswered. Keelpost is built to make responding fast, not to respond for you.

There is no price, because there is no plan, no billing and no way to buy it. If you see a price for Keelpost anywhere, it did not come from us.

The shape is decided even though the numbers are not: the meter is how often the briefing runs. Free is intended to run it every twelve hours, with a manual trigger whenever you want it sooner; paid tiers run the same briefing more often; connecting your own Cloudflare account moves the inference to your own bill and takes the cap off entirely. The approval boundary is not a paid feature and will not become one.

No. Keelpost is a client. You own the domain, you run the Cloudflare account, and Email Routing under your control delivers mail into the app. We do not sell you addresses, we do not run MX for you, and we are not in the position of holding your domain hostage — you change your routing and it stops.

A domain you control and a Cloudflare account with Email Routing configured for that domain. That is the only supported way mail gets in right now. You do not supply any API key; the secrets Keelpost needs are its own.

Not yet. Neither is built — not partially, not in beta, not behind a flag. Microsoft 365 is sequenced before Google Workspace, because acting on a Gmail account needs one of Google’s restricted scopes, and a restricted scope needs app verification plus a third-party security assessment renewed at least every twelve months; until that clears, an app still in testing issues refresh tokens that expire after seven days, which a twice-daily briefing cannot survive.

Today the only way mail reaches Keelpost is a domain you route in yourself with Cloudflare Email Routing. Zoho is not planned at all, and IMAP and POP are refused for an architectural reason rather than deferred.

Microsoft 365·Planned — not built yetGoogle Workspace·Planned — not built yet

Not with any confidence yet. The outbound path is written and it is written carefully — the message is stored before any delivery job is published, delivery runs as a durable background job with bounded retries and a dead-letter queue — but it has not been verified against a live provider. We do not count sending as working, and neither should you until this page says otherwise.

Sending in production·Planned — not built yet

The interactive agent cannot perform a destructive action on its own, and it has no send tool and no tool that deletes a message you have received. Its six state-changing tools — drafting a message, drafting a reply, revising a draft, marking read, moving a message and discarding a draft — halt and render an approval card that a person has to accept, and approving is what performs the action. The separate inbound assistant may create an inert draft after a fail-closed scan, but it has no send capability. The card is drawn by the server from the stored message, so it shows the real message and the real change rather than the model’s description of them. There is no setting that turns required approval off and no allow-list that skips it.

Inbound mail is scanned for prompt injection before the drafting model sees it, and a flagged message gets no automatic draft. If the scanner errors, the message is treated as flagged — it fails closed.

Be clear on the limit: the scan gates automatic drafting only. A flagged message is not quarantined, so if you or an MCP client ask the agent to read it, its content reaches the model. Beyond that, the structural answer is the one above: even a fully manipulated agent has no way to move, send or delete anything without a person clicking approve, and the auto-draft path has no send capability at all.

The agent runs on Cloudflare Workers AI, inside the same Cloudflare account boundary as the rest of the deployment. Message content is sent to that model when you use the agent or when auto-drafting runs on a new message. There is no other model provider in the path.

Remove their grant. Operators and viewers only ever see mailboxes granted to them individually; owners and admins see the workspace’s mailboxes. Removal takes effect on the session they have open — their next action, in the client or through the agent, fails rather than waiting for a logout.

It is constrained differently, and today it is constrained harder. An MCP client is stopped by scope first: it holds an OAuth 2.1 token with PKCE, gated to specific tools, and it can never exceed the mailbox grants of the account that authorised it. On top of that, the seven tools that would change something — send_email, send_reply, delete_email, discard_draft, update_draft, move_email and mark_email_read — stop and ask a person first, because a scope proves which client is calling and not that a person saw the change. So a client you granted mail:send still cannot send until you say so, on a Keelpost page showing the exact change. Reading and writing a new draft work outright, and a draft is inert until you send it from the app. Owners and admins create the clients, dynamic registration is off, and consent can be revoked and secrets rotated.

No. We hold no certification of any kind, we have not been audited, and we are not going to display a badge we did not earn. See the “what we do not claim” section on the security page for the full list of things we are not asserting.

Join the waitlist. Sign-ups are closed, there is no invite code circulating, and no trial. You get one email when sign-ups open.

Keelpost is derived from Cloudflare’s Agentic Inbox, which is licensed under Apache 2.0; that attribution stays in our footer and in the source headers where it belongs. We have not published our own repository and we are not promising when or whether we will.

The routing is yours, so the first step is entirely in your hands: repoint the domain and delivery stops. For what happens to data already stored, we will publish the exact behaviour before sign-ups open rather than describe something today that has never been exercised with a real account.