Security & Data Handling

Last updated: 15 August 2026

Everything below describes what the product does today, with each limit stated next to the mechanism it belongs to. If you find a claim here that Overdesk does not honour, email security@overdesk.io and we will fix the page or fix the code. If you want the detail behind any of it, the security implementation notes go a layer deeper.

1. The short version

A human sends every message. Nothing reaches your customer unless someone on your team has read the draft and pressed send. There is no autonomous send: no schedule, rule, or confidence score can dispatch a reply on its own.
Drafts are generated with your own Anthropic API key, in your Anthropic account, under your agreement with them.
Contact details become tokens before any prompt leaves our system, and turn back into real values in the draft your agent reads. The model does not receive your customer's email address or phone number.
The pseudonymisation is pattern-based, and we publish its limits (Section 3). It is not a substitute for your own judgement about what belongs in a ticket.
We hold no security certifications (Section 9). We say so plainly rather than blur it.

2. What leaves our system, and under whose account

Destination	What we send	Whose account	When
Anthropic	Conversation text, pseudonymised (Section 3). When you connect a code repository, also its file listing and the contents of the files the model chooses to open while answering	Yours (your API key)	Every draft, triage, report commentary, and analysis
Voyage AI	Conversation, document, and saved-reply text for embeddings, pseudonymised with the stricter storage profile; and your search queries, which when Overdesk drafts include the customer's latest message (Section 3)	Overdesk (an Overdesk-owned Voyage account, not a key you supply)	Knowledge-base sync, and every search
Your helpdesk	The finished draft, written back unsent (an internal note, or an unsent draft reply if you turn that on), with the real customer details restored	Yours (HelpScout, Zendesk, or Intercom)	Every draft
Slack / ClickUp	The reports you schedule	Yours (your workspace)	On your report schedule
GitHub / Linear / Jira	The title and description of an issue one of your team opens from a conversation, with contact details removed	Yours (your repository, team, or project)	Only when a member of your team writes one and confirms it
Neon	Everything Overdesk stores	Overdesk	Continuously
Fly.io	Application hosting; your data in transit	Overdesk	Continuously
Stripe	Billing details. We never see or store card numbers	Overdesk	On subscribe
Resend	Your team's email addresses, for login links and notifications	Overdesk	On send

That is every party that receives your data. When you point Overdesk at your public documentation or forum, it fetches those pages to index them, an outbound request to a site you nominated that carries none of your customers' data. The product runs no analytics, advertising, or third-party tracking.

One asymmetry, stated plainly: language-model requests run under your Anthropic key, but semantic-search embeddings run under an Overdesk-owned Voyage account. Overdesk provides Voyage embeddings for every workspace; the product does not ask you to supply a Voyage key.

3. Pseudonymisation: what it catches, and what it misses

Before a prompt reaches a language model, Overdesk runs the conversation text through a pattern-based pseudonymiser. Matches become deterministic tokens, and when the model replies the tokens turn back into the real values, so your agent reads a usable draft and the model never received the raw details. (The token format is in the implementation notes.)

Tokenised before the model sees them:

Email addresses
Phone numbers
Payment-card numbers (checksum-validated), IBANs, and cryptocurrency addresses
Social-security numbers, but only where the nearby text actually says "SSN" or "social security", since a bare nine-digit run is far more often an order number
MAC addresses
PO boxes, and street addresses introduced by an explicit lead-in ("lives at …", "address: …")
The requester's name, taken from your helpdesk's structured contact fields rather than guessed from the prose

Four kinds of weak identifier are deliberately left intact on the way to the model: URLs, IP addresses, postcodes, and street addresses with no lead-in. Each one's pattern collides with ordinary support text (a version number, a ticket number, a plain English word), so redacting it reliably would corrupt the very ticket the model has to read; the implementation notes show the collisions case by case. The consequence, said plainly: a password-reset or invite link pasted into a ticket reaches the model intact. The same four are left intact in the copy we store and embed, for the same reason: a stored article is quoted back to the model as the source of its answer, so a version number lost to an IP pattern is an answer lost, and a link lost to a URL pattern is a citation the reply cannot point at. A credential carried inside a link is a separate matter, and it is replaced on both paths whenever it is long enough for the API-key and licence-key patterns to claim it: a long random run, a UUID, a signed-URL signature. Short link ids, and tokens broken up by dashes or dots, are not long enough for those patterns and are retained with the link; a query parameter that names itself a credential (?token=, ?key=, ?secret=) is replaced when its value mixes letters and digits, but one named nothing in particular is not. Treat a reset or invite link pasted into a ticket as retained.

The knowledge base is redacted before it is written. When Overdesk indexes a conversation, its subject, body, and resolution pass through the pseudonymiser on a slightly stricter profile than the model gets: every pattern above, plus two shapes the model path deliberately declines because in a live ticket they are more often order numbers: a card-length digit run that fails the card checksum, and a phone-length digit run written with no separators. The customer's email address is replaced with a deterministic stand-in, the same one each time, so the record still groups by customer without holding the real address.

Two limits on that. The structured name substitution does not run at rest, because it needs the contact field from a live draft; so in the indexed copy a name written into the ticket text, the requester's included, stays as written. And this covers the knowledge base, not every row in our database: two stores hold real details on purpose, the draft written back to your helpdesk (your teammate has to read a usable reply) and the raw webhook event (which sits in the job queue until it is processed and cleaned up). Both age out under Section 6, and neither is what reaches the model.

Your saved replies are indexed the same way. The templates and macros you keep in your help desk are pseudonymised on this stricter profile and indexed alongside your other content, so Overdesk can find the right one. That means their text is embedded through the Voyage account named in Section 2, exactly as your documentation and past conversations already are. These are wording your team wrote rather than a customer's message, so there is usually nothing personal in them; the redaction runs anyway, because a template written from a real ticket can carry a real detail.

Searching your knowledge base sends a search query out too. To find the right article, Overdesk searches on the ticket's subject plus the first part of the customer's latest message, so that text reaches the Voyage account above. It is pseudonymised on the same stricter profile as the knowledge base, with one difference: the structured name substitution described above needs a live contact field, so it does not run on a search query. This happens while the ticket is still open, not only after it closes.

Our own search log keeps the subject line only. The part taken from the customer's message is used to run the search and is not stored, so it is not sitting in a table here waiting to age out. What is kept is the subject, the number of results, and how the search ran, for 90 days (Section 6).

The limit that matters most: names of other people written in free text are not detected. Overdesk runs no named-entity model. If your customer writes "my colleague Dave Harrison can't log in either", that name reaches the model. The requester's own name is masked because your helpdesk hands it to us as a field; a name mentioned in passing has no pattern to match.

4. Bring your own key

Drafting, triage, report commentary, and analysis all run on your Anthropic API key, encrypted at rest (Section 8). Your conversations are processed under your own commercial agreement with Anthropic, not proxied through an Overdesk-owned AI account and not pooled with another customer's traffic.

We do not train models on your data. There is no shared Overdesk model to train.

5. A human sends every message

Overdesk places its drafts into your helpdesk unsent. By default a draft arrives as an internal note; if your team turns on draft delivery, it arrives as an unsent draft reply in the composer instead. Neither is visible to your customer, and neither is sent by Overdesk. A person on your team reads the draft, edits it if they want, and sends it.

Exactly one code path can put a reply in front of your customer, and the only thing that triggers it is a person choosing to send a draft they have read. No schedule, automation rule, or confidence threshold can reach it, because the autonomous path was never built.

Every draft is stored with the model that wrote it and the tokens it cost.

6. Retention and deletion

Content ages out automatically. Generated reports follow your plan's retention — 90 days (Trial), 90 days (Assist), 365 days (Pro), and unlimited (Scale); drafts, triage, alerts, and the redacted auto-send decision log are kept 180 days; search-query logs 90 days; your indexed knowledge base lives for the life of the workspace. The implementation notes carry the full schedule.

Erase one customer. An admin can erase a single end customer from Settings. Overdesk resolves their conversations, deletes the drafts, triage results, simulation results, and knowledge-base entries derived from them, and records that the request was honoured. Those conversation IDs go onto a suppression list, so the next sync with your helpdesk does not quietly re-import what you just erased.

Delete the workspace. The owner can delete the whole workspace from Settings. The Stripe subscription is cancelled first, then the workspace and its contents are removed immediately, with no grace period and no soft delete. Two things survive by design: the record that you accepted the terms, and the record that the deletion happened.

Two limits worth knowing. Report and alert text is prose written by a model, so a customer named inside it has no key to search on and is removed by the age-based schedule above rather than by a targeted erasure. And deleting your workspace does not remove the webhook you registered inside your own helpdesk; delete that one yourself, though once the workspace is gone anything the webhook sends is rejected.

7. Sub-processors

The full list, with each sub-processor, its purpose, the data it receives, and where it runs, is the table in the Privacy Policy. We keep a single canonical copy so the two pages cannot drift apart.

8. Infrastructure and access

Overdesk's application (Fly.io) and database (Neon) run in the United States. If you use Overdesk from elsewhere, your data is processed in the US.
All traffic is over TLS.
Helpdesk credentials, model API keys, and webhook signing secrets are encrypted at rest with AES-256-GCM, under a key derived per workspace and per purpose, so one workspace's ciphertext cannot be decrypted with another's key.
Every query against workspace data is scoped to a single workspace, and a test gate fails our build if a new query is written without that scope. The handful of deliberate exceptions are enumerated in the implementation notes.
Inbound webhooks are signature-verified. An unsigned or wrongly-signed event is rejected.

9. Compliance: what we can and cannot say

Overdesk holds no third-party security certifications. We are not SOC 2 audited, not ISO 27001 certified, and we do not offer a HIPAA BAA. If a certification is a hard requirement for you, we are not the right vendor yet, and we will tell you that now rather than during your review.

What is true:

For your customers' personal data inside your support conversations, you are the controller and Overdesk is the processor (GDPR Article 28). We process it only on your instructions, and the Article 28 obligations here (pseudonymisation, retention, deletion, erasure on request) are implemented in the product, not merely promised in a contract. If you need a separate data processing agreement, email privacy@overdesk.io.
Under the California CCPA/CPRA we act as a service provider for support content. We do not sell or share personal information.
Your rights, and your end customers' rights, and how to exercise them, are set out in the Privacy Policy.

10. Reporting a vulnerability

Email security@overdesk.io with what you found and how to reproduce it. We will acknowledge it, and we will not threaten you for reporting it.

We do not run a bug bounty: we are a small team and cannot fund one properly. Please do not test against other people's workspaces or real customer data. If you need an account to test with, ask and we will make you one.

Changelog

2026-08-07: Follow-up nudges now respect your draft delivery setting. A nudge is the short message Overdesk drafts when a customer has gone quiet on an open ticket. Until now it was always placed as an internal note, even for teams who had chosen to receive drafts as unsent draft replies in the composer; it now arrives in whichever shape you picked, the same as every other draft. Nothing about sending changed: both shapes are invisible to your customer, neither is sent by Overdesk, and a person on your team still sends every message. No new party receives your data and retention is unchanged.
2026-08-07: Saved replies are now indexed like the rest of your knowledge base, so Overdesk can actually find the right template. Their text is embedded through the Voyage account named in Section 2, which it was not before, and it is pseudonymised on the same stricter profile as everything else stored. Sections 2 and 3 now say so. No new party receives your data, retention is unchanged, and nothing about how a draft is delivered or sent has changed.
2026-08-06: Disclosed more about search queries. To find the right article, Overdesk now searches on the ticket's subject plus the first part of the customer's latest message, where it used to search on the subject alone. That means more of a customer's own words reach the Voyage account named in Section 2, on an open ticket rather than only a closed one. Sections 2 and 3 now say so, including the one gap: the structured name substitution needs a live contact field, so it does not run on a search query. Our own search log keeps the subject line only, so the extra text is used for the search and not stored here. No new party receives your data, and the search log's 90-day retention is unchanged.
2026-08-05: Corrected where a draft is placed. This page said drafts always arrive as internal notes; since the release that added draft delivery, a team can choose to receive them as unsent draft replies in the composer instead. Section 5 and the sub-processor table now describe both. The claim that a person sends every message is unchanged, and no send behaviour changed: neither shape is visible to your customer, and neither is sent by Overdesk.
2026-07-16: Restructured for length. Implementation detail (token format, redaction-collision cases, the full retention schedule, cookie and query-scoping specifics) moved to the security implementation notes. Every claim and stated limit is unchanged.
2026-07-14: First published, alongside the release that shipped the pseudonymisation, retention, deletion, and erasure behaviour described here.