Security & Compliance

For IT and security teams evaluating Kelp for Google Workspace.

Hi — we're Alex and Jeremy, the cofounders of Kelp. We met studying Computer Science at Stanford in the 1990s and worked closely together in the early pre-IPO years at Google and Twitter. We built Kelp to be easy for security and IT teams to evaluate, with the privacy safeguards we'd want for our own companies.

This page is the short version: how we handle your users' data, which Google APIs we use and why, and the compliance work we've done. If you'd rather just talk to us, email security@trykelp.ai — we're happy to share our CASA report, fill out a questionnaire, or get on a call.

For Google Workspace admins

If you'd like to let your users sign in to Kelp, here's how to allow the OAuth app in your Workspace org. You'll need super-admin access to admin.google.com. The two things you'll need to identify Kelp:

• OAuth Client ID (the unique identifier — search by this): 85049188222-hro30vnvdknq5752v0tdun3fj86qicb8.apps.googleusercontent.com Copy
• App name (for confirming the result): Kelp AI

1. Open App access control → Configured apps directly, or navigate via Security → Access and data control → API controls.
2. Click Add app → OAuth App Name or Client ID.
3. Paste the Client ID into the search box and select the result. Search by Client ID rather than app name — the Client ID is unique, app names can collide.
4. Choose access level Trusted: Can access all Google services. Kelp uses restricted Gmail scopes (see Google API access below), so the Limited level will block sign-in.
5. Choose which organizational units or groups this should apply to (or All users), confirm, and you're done.

Allowing the app only authorizes Kelp to be granted access; individual users still sign in through Google's standard OAuth consent flow. If you'd rather roll out to a specific OU first, or want help validating the configuration, email security@trykelp.ai and we'll walk through it with you. Google's general docs on this flow are here.

Compliance

Kelp has completed Google's Cloud Application Security Assessment (CASA) — the security audit Google requires of any application that asks for restricted Gmail scopes. CASA isn't a self-certification: it's run through the App Defense Alliance by accredited third-party assessors.

The audit checks an application against the OWASP Application Security Verification Standard (ASVS) — architecture, authentication, access control, data protection, cryptography, logging, and secure deployment. Passing CASA is a prerequisite for Google to grant production access to sensitive scopes, so it's not optional for an app like ours.

Google API access

Sign-in is Google OAuth 2.0 with PKCE. We don't store passwords or manage credentials — users go through Google's standard consent flow.

Here are the scopes we ask for, and why:

• openid email profile — basic identity, so we can create and recognize a user's Kelp account.
• gmail.readonly — read message metadata and content so we can classify each inbound message against the user's filters, and observe how the user handles their mail (for example, a message marked as spam, a Kelp label removed, or a filter's label added by hand) so Kelp can suggest improvements to their filtering.
• gmail.modify — apply the action a user has chosen for a matching filter (archive, label, mark as read, move to Spam, or move to Trash). We need this because Kelp's whole job is to act on inbound mail per the user's rules; without it, we could read but not actually do anything. Note: gmail.modify is a coarse Google scope that also grants the ability to compose and send mail, which is why Google's consent screen renders it as "Read, compose, and send emails from your Gmail account." Kelp does not use those capabilities — we don't request the narrower gmail.send scope (or any send-related scope), and Kelp's codebase contains no send-message path. Filters only categorize and triage existing mail.
• contacts.readonly and contacts.other.readonly — used to figure out who the user has corresponded with. When we see a message from one of those contacts, we drop it immediately and never save any information about it.

We use Google API data only as the Google API Services User Data Policy and its Limited Use requirements allow. We don't sell user data, transfer it to data brokers, or use it for advertising.

Data handling

Kelp is built around a small data footprint. We don't keep copies of message bodies, attachments, or contact lists. What we do retain — so users can review what was filtered and so Kelp can improve their filtering — is listed below.

• Where messages are processed: All inbound email is handled by short-lived Pub/Sub workers running on Google Cloud Run — in Google Cloud, in the same regions as Gmail. The worker pulls each message and checks the sender first. If it's from one of your contacts, the worker ends processing immediately and saves nothing — no classification, no AI call, no envelope preview. Otherwise, the worker holds the body in memory just long enough to classify it against the user's filters and (if a filter matches) save an envelope preview, then drops the body. Message bodies are never written to Kelp's database. The only point at which email content briefly leaves Google's infrastructure is the per-message classification call to Anthropic (see AI processing below).
• Envelope preview: So users can review what was filtered and catch mistakes, we store just the sender, subject, and a short body snippet for messages that matched one of the user's filters. Rows are kept for about 30 days and then deleted by a scheduled job. This is on by default and can be turned off in Settings → Privacy; turning it off purges these previews immediately and stops Kelp storing the same envelope fields with the spam-mark feedback below.
• Feedback signals: When a user corrects Kelp in Gmail — marking a message as spam that Kelp didn't act on, removing a label Kelp applied, or adding a filter's label to a message Kelp missed — we store a small signal so Kelp can suggest improvements to their filtering. For a spam-mark we always keep the sender's domain, and — when envelope preview (above) is on — also the sender, subject, and a short snippet; for a label removal or addition it's only which label changed (no message content). These rows are kept for about 30 days, then deleted by a scheduled job.
• Assistant conversations and suggestions: So we can debug and improve Kelp's assistant, we keep a record of your conversations with it — the messages you send and what Kelp writes back, including which tools it ran — along with the filtering suggestions its periodic review generates for you. The email content the assistant reads from your mailbox to answer you (message bodies, subjects, senders, snippets) is never written into this record. Suggestions are short-lived working state, cleared after about 30 days. This is internal product work to make Kelp better — none of it is used to train an AI model.
• Learned filtering memory: To recommend and tune filters that fit each user, Kelp keeps a memory of patterns it infers from their mail and their interactions with it — their learned filtering preferences, plus a short profile of facts (where they're based, their work, recurring senders) that helps Kelp judge whether mail is relevant. This is used only to operate and improve the user's own filtering, is viewable and editable from their settings, and is kept until they edit or delete it. It is never used to train or improve any generalized AI model.
• Contacts: We don't store contact email addresses. We store one-way hashed fingerprints, used during classification to recognize trusted senders.
• In transit and at rest: Everything is TLS in transit and encrypted at rest in Render's managed PostgreSQL.

AI processing

Kelp uses Anthropic's Claude API in three ways: to classify inbound mail, to power the in-product assistant that helps users set up filters, and to run a periodic review that learns from how a user handles their mail and suggests filtering improvements. For each message we classify, we send the headers (From, To, Cc, Date, Subject), the user's filter prompts, the processed message body — converted from HTML to text and capped at 10 KB — and, when personalization is on, the user's profile, in a single classification call. The in-product assistant and the periodic review additionally draw on the user's learned filtering memory (see Data handling) as context.

Kelp keeps its own memory of a user's filtering preferences, but we don't use any of Anthropic's stateful features — no training, no fine-tuning, no Anthropic-side memory.

Per Anthropic's API data policy, customer inputs and outputs aren't used to train Anthropic's models, and content is kept only as needed to run the service and meet legal obligations. Kelp does not send Google user data to any other AI provider.

When the AI gets it wrong. Because classification is done by a large language model, a message can occasionally be filtered incorrectly — that risk is inherent to any AI system. Kelp is designed so a mistake is both recoverable and uncommon. Kelp itself never issues a permanent delete; its strongest actions move a message to Gmail's Spam or Trash, where it stays recoverable until Gmail's own retention window passes (about 30 days). Every action Kelp takes is recorded and can be reversed from the dashboard — putting the message back in the inbox and removing any label Kelp added — and the envelope preview above lets users see exactly what was filtered. To keep mistakes rare, Kelp only ever filters mail from senders outside your contacts and trusted list, and before a filter goes to work, Kelp checks it against your recent mail.

Access control & infrastructure

• Server-side authorization: Authorization lives in our Rust/Axum backend, with a database check on every request to validate session state and permissions. Session JWTs expire after 7 days and can be revoked server-side at any time via a session-version counter — logging out (or admin revocation) bumps the counter, and any token signed against the previous version is rejected on its next request.
• Cookies and CSRF: Auth tokens stay in HttpOnly cookies; we use a double-submit token for CSRF protection, with Secure and SameSite=Lax in production.
• Browser hardening: Production responses ship with Content Security Policy (CSP), Strict-Transport-Security (HSTS), X-Frame-Options, X-Content-Type-Options, and a tight Permissions-Policy.
• Internal access: Kelp staff don't access user Google data except with explicit user permission for a specific support issue, for security investigations, or as required by law.

Talk to us

For the user-facing details, see our Privacy Policy and Terms of Service.

For anything else — CASA report, security questionnaire, architecture deep-dive — email security@trykelp.ai and we'll get back to you quickly.