Security & Data Handling

Last updated: 28 October 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

Overdesk sends a reply only if your workspace turns sending on. Until then, nothing reaches your customer unless someone on your team has read the draft and pressed send. Sending takes two keys: we enable it for your workspace, and your admin turns it on. After that, Overdesk sends only the replies your guardrail rules approve, some replies are never sent whatever the rules say, and either side can turn it off at any time (Section 5).
Drafts are generated with your own Anthropic API key, in your Anthropic account, under your agreement with them.
Contact details in the TEXT 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 from the text of a ticket, or a North American phone number written with dashes, dots, spaces or brackets, such as (555) 123-4567. Phone numbers in other national formats can reach it in whole or in part, and so can a number typed as one bare run of digits, which is left as written because in a live ticket it is far more often an order number. A password reaches it unless it sits next to a label such as "password:" (in English, German or Dutch) or after the username it goes with, as in "login: admin / …", and is one unbroken string that mixes letters and digits, a run of six or more digits, or a string of 12 or more different characters, fairly evenly spread, that mixes upper and lower case with a symbol from ! @ # $ % ^ & *; a WordPress application password is replaced with no label beside it, and a shorter number, an ordinary word and a passphrase with spaces are left as written (all in Section 3). The model does receive any picture attached to it, exactly as your customer sent it: that pass reads text and cannot read inside an image (Section 3).
Overdesk opens pages your customers link to, while it drafts. The readable text of that page goes to the model with the rest of the conversation, and it is pseudonymised like any other text. The request carries none of your help desk credentials. Only links in your customers' own messages are opened, never links your team wrote, and there is a switch on the Customize AI page to stop it entirely (Section 3).
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. When Overdesk drafts a reply, and only then, also the pictures and log files attached to that conversation and the readable text of pages your customers linked to: up to four pictures, two text files and three pages, and only pictures in the formats the model reads. A log file and a linked page are pseudonymised like any other text; a picture is not, and cannot be (Section 3). A PDF a customer attaches is read the way a picture is: one per draft, up to ten pages. When Overdesk tries the issue on a test site, the screenshots it takes of that test site go too	Yours (your API key)	Every draft, triage, report commentary, and analysis, and every question asked of Ask Overdesk. Pictures and attachments go only with a draft, never with the rest
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 on Help Scout an unsent draft reply if you turn that on), with the real customer details restored	Yours (Help Scout, Zendesk, Intercom, or FreeScout)	Every draft
Your store, billing, or licensing system	Your end customer's email address, sent as the key to look them up. What comes back, their orders, plan, invoices, or licence keys, and from a licence system the sites they installed your product on with the versions each reported, goes into the draft prompt above. After a churn or frustration analysis, the customers its findings name are looked up in a licence system or billing account the same way, and what they hold and have paid is kept with the finding (Section 6); that goes to no model	Yours (WooCommerce, Shopify, Stripe, or Freemius)	Every draft, once you connect one; and after a churn or frustration analysis, for at most 25 of the customers it names
Slack	The reports and alerts you schedule, and the answer Ask Overdesk writes when somebody asks it a question about your queue. All three have your customers' names replaced with "(customer)", and their email addresses and North American phone numbers left as tokens. Ask Overdesk answers from a copy of your report that was stored with the names already replaced, so they are gone before the question is asked. A report archived before we started keeping that second copy cannot be read this way at all, and Ask Overdesk says so rather than falling back to the copy in your dashboard. Two records reach you as written, both explained in Section 3: a name that is really a mailbox or a company, because it names no person, and a name your helpdesk holds as only one or two letters, because substituting something that short would corrupt ordinary words around it. The copy kept in your Overdesk dashboard restores the names, because that copy does not leave your account	Yours (your workspace)	On your report schedule, when an alert fires, and whenever somebody asks
ClickUp	The reports you schedule and the alerts Overdesk raises. It is the same copy Overdesk sends to Slack, on the same terms, including both exceptions above. An answer from Ask Overdesk goes to Slack only, and never to ClickUp	Yours (your workspace)	On your report schedule, and whenever an alert fires
GitHub / Linear / Jira	The title and description of an issue one of your team opens from a conversation, with email addresses, card numbers and North American phone numbers 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; and the test copies of WordPress, which receive only the pseudonymised steps the model takes on them (Section 3)	Overdesk	Continuously, and a test site only while a draft uses it
Stripe, as our own account	Your billing details for your Overdesk subscription. We never see or store card numbers. This is separate from a Stripe account you may connect above, which is yours and which we only read	Overdesk	On subscribe
Resend	Your team's email addresses, for login links and notifications	Overdesk	On send

One thing happens in your browser rather than on our servers: choosing which Google documents to index opens Google's own file picker, which means your browser loads a script from Google and Google sees the request. It runs only when somebody on your team opens that picker, it is the only third-party script the product loads, and none of your support content passes through it.

That is every party that receives your data. Overdesk also reads, and reading is a different thing from sending: nobody on the other end is given your customers' data. It reads from the places you connect as knowledge — your public documentation or forum, and your Notion, Google Docs, GitHub, Jira, or Linear — with the access you granted. And since 14 September 2026 it also opens addresses your CUSTOMERS write, when one of them links to a page in a ticket and Overdesk reads that page while drafting a reply. That last one is worth stating plainly because it is the only outbound request this product makes to somewhere neither you nor we chose: the site's operator learns that the address was opened and sees the request arrive from our servers, and the address itself is whatever your customer typed. No credential of yours, no account detail and no other part of the conversation travel with it, and it is not a sub-processor because we send it nothing to process. You can switch it off on the Customize AI page. Section 3 has the detail. The app runs no analytics, advertising, or third-party tracking. Our websites count visits with Cloudflare Web Analytics, which sets no cookie; Section 7 of the Privacy Policy also names the one security cookie Cloudflare sets there.

Four of the systems you connect run under an Overdesk-owned credential rather than under one of yours, and we would rather say so than have you find out. Semantic-search embeddings run under an Overdesk-owned Voyage account: Overdesk provides them for every workspace and does not ask you to supply a Voyage key. The Google Docs connection is authorised through Overdesk's own Google application, so Google records that Overdesk opened the file, though the access is the one you granted and reaches only the documents you picked. And the Slack app your team installs is Overdesk's Slack application, so what it can do in your workspace is what you approved at install. A Help Scout connection can be authorised through Overdesk's own Help Scout app, so Help Scout lists Overdesk as the app with access, though the access is the one your admin approved; one made with an app of your own runs under that app. Every other system you connect, including every language-model request, runs under your own account and your own key.

The four rows above that name Overdesk are our own infrastructure and suppliers rather than anything you connect: the database, the hosting, the payment processor for your Overdesk subscription, and the service that sends your team's login emails.

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 from the text. (The token format is in the implementation notes.)

Tokenised before the model sees them:

Email addresses
North American phone numbers written with dashes, dots, spaces or brackets, such as (555) 123-4567, 555.123.4567 or +1 555 123 4567. Other national formats are not reliably caught, nor are numbers split by other separators such as slashes, en-dashes or non-breaking spaces: some reach the model whole and some in part, and a number typed as one bare run of digits is left as written
Payment-card numbers (checksum-validated), IBANs, and cryptocurrency addresses
Licence keys, API keys and passwords, with limits. A key's secret part is replaced, but a vendor prefix such as "FWG-" or "sk-proj-" can stay readable. A key with no label beside it can be left as written when it is shorter than 20 characters, such as A1B2C3D4E5F6G7H8I9J. A password is replaced only when it sits next to a label such as "password:" or "pwd:", or after the username it goes with, as in "login: admin / Hunter2x9!", "credentials: jane@example.com | Hunter2x9!" or "user bob, pass Hunter2pass", and only when it is one unbroken string that mixes letters and digits, a run of six or more digits, or a string of 12 or more different characters, fairly evenly spread, that mixes upper and lower case with a symbol from ! @ # $ % ^ & *. It is replaced as a password even when it also reads as an email address or a card number, so a reply that repeats it keeps the stand-in. One password is replaced with no label: a WordPress application password, six groups of four letters and digits such as "aB1c DeF2 gHi3 JkL4 mNo5 PqR6", unless four or more of its groups read as words, which leaves fewer than 1 in 1,000 as written. Once a password or a key is replaced, every other copy of it in the same text is replaced too, written on its own or after its label, even a label run into the word before it. A number under six digits, an ordinary word, a run of words joined by dashes and a passphrase with spaces are left as written, for example "password: sunset-harbor-lamp-quarry". A longer string that leans on a few characters, such as "CorrectHorse!Battery", is left as written too. The label must be in English (password, pwd, pass, pw, p/w, passwd, passcode, passphrase), German (Passwort, Kennwort) or Dutch (wachtwoord), or a prefixed name such as smtp_pass or DB_PASSWORD: labels in other languages, such as "mot de passe:" or "contraseña:", are not read, and a value under 4 characters is not replaced. A password with no label beside it, such as one written after "login" with no colon ("login admin / Hunter2x9!"), reaches the model as written, and so does one joined to its username by a bare slash after "login:" ("login: admin/Hunter2"), which reads the same as a path, or a word and its number after a way to sign in, such as "Login: Google / Office365" or "Login: SSO / SAML2". A username and password joined by a comma, a dash, a tab or a line break, a WordPress application password split across lines, and a copy run into the word after it are left as written too.
Social-security numbers written with dashes or spaces, such as 123-45-6789. A bare run of nine digits is replaced only when the same text says "SSN" or "social security", since on its own it is far more often an order number
MAC addresses
PO boxes, and street addresses introduced by an explicit lead-in ("lives at …", "address: …")
The name of everyone on the customer's side of the conversation, when Overdesk is drafting a reply: the person who opened the ticket, and anyone else who wrote one of the messages sent with it, such as a colleague copied in or a second contact at the same company. Taken from your helpdesk's structured fields rather than guessed from the prose, so a name it holds only as one or two letters is left as written. So is a name that is really a mailbox or a company. When a message arrives from an address like support@ or billing@, most help desks file the contact under that word, and a company record often ends in one of the usual forms. Those words are left readable, because replacing them would take the same words out of your own help articles in the same prompt, and because a mailbox names no person. A name with an ordinary word anywhere in it is masked in full, exactly as before

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).

Pictures are sent as your customer sent them, and this is the one limit that no pass can close. When somebody attaches a screenshot to a ticket, or pastes one into their email, Overdesk sends that picture to the model along with the text while it drafts a reply. Up to four pictures per draft, each under four megabytes, and only in the formats the model can actually read (JPEG, PNG, GIF and WebP), so a photo straight from an iPhone in Apple's HEIC format is not sent at all. Two text attachments come too, and those are pseudonymised like any other text. The pseudonymiser above reads text; there is no version of it that can read inside an image without destroying the thing the picture was sent to show. So an email address in a browser tab, a licence key in a console, an order in a dashboard, a face in a video call, all reach the model as they appear. We chose this deliberately rather than blurring it: a screenshot with the evidence obscured cannot answer the question, and a reply written from an unreadable picture is worse for your customer than no reply at all. Log files and other text attachments are different and do go through the pass, exactly like the message they came with. If you would rather Overdesk did not read pictures at all, you can switch it off yourself on the Customize AI page in your dashboard, and drafts are then written from the words alone. Text attachments are a separate matter and are not affected by that switch, because they go through the pass above like any other text.

Overdesk opens pages your customers link to, and this is an outbound request rather than a limit of the pass. When a customer's message links to a page, Overdesk opens that address while the draft is being written and gives the model the readable text it finds, so the reply can answer what the page says instead of guessing from the address. Up to three pages per draft, at most half a megabyte read from each, and nothing is stored. The text is pseudonymised like any other text. Four things are worth knowing before you leave this on. The request goes to a third-party website that your customer chose, so its operator learns the address was opened, and the address itself is whatever your customer wrote: no credential of yours, no account detail and no other part of the conversation travel with it, but if somebody pasted a link with something personal in the address then that part does. The text that comes back is written by whoever controls that address, not by your team and not by us, so the model is told to treat it as something to read rather than as instructions, and to say where a fact came from when it uses one. Only links in your customers' own messages are opened, never links your team wrote. And if a customer links to a picture instead of attaching one, it is read as a picture under the rules above, so switching pictures off switches that off too. There is a separate switch for this on the Customize AI page, and turning it off means no address a customer sends is ever opened. When the page is a WordPress site, the model is also told the WordPress, plugin and theme versions the page's code shows, read from the same page and never from a second request.

Overdesk can try the issue on a private test copy of WordPress, and the contact details the pass replaces never reach it. Once your team lists its products on the Sandbox settings page, Overdesk can start a copy of WordPress with those products, plus any public WordPress.org plugin or theme the customer mentions, and try what the customer describes before the reply is written. It runs on a separate machine at Fly.io with no route to the internet, to our application, to our database or to any other test site, and the machine is destroyed when the reply is done. The model decides what to do there, and the placeholders above stay placeholders in everything it types, so a command it runs never carries a contact detail the pass replaced. What it sees back (the page, a screenshot, command output) is pseudonymised before it is stored, and that record is kept with the reply for 180 days. A zip file of your own product that your team adds is stored with your workspace until you remove it, and only your own test sites install it. A reply that says something was tested, with no finished test behind it, is held for a person instead of being sent.

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 name of anyone on your customer's side who wrote one of the messages is masked, because your helpdesk hands each of those to us as a field; a name mentioned in passing has no field to read and no pattern to match. That masking is not particular to drafts. Every use of a model that reads the messages on a ticket registers the same names, so a colleague who signed their own message is masked when Overdesk writes a draft, when it classifies a ticket, when it nudges a customer who has gone quiet, when it fills in a new issue on a tracker you have connected, and in the summaries behind your reports and analyses. Where one of those reads only a ticket's subject and the opening snippet your help desk shows in a list, rather than the messages themselves, there is no author field to read and it sends the requester's name masked as it always did. That includes Ask Overdesk: when it answers a question about a report you already have, it reads a copy of that report stored with the names already replaced, and not the copy kept in your dashboard.

Your own team's names are not masked, and that is a decision rather than an oversight. When one of your agents writes on a ticket, whether or not the customer sees it, their name goes to the model as written. The drafting request runs on your own Anthropic account rather than ours, so this is your staff reaching a supplier you already chose. The model uses the name to follow who said what on a ticket several colleagues have answered, and it writes a worse reply without that. It is not signed off with, either: the instructions ban a name and a signature block at the end of a reply, because your help desk adds the real sender's signature when the message goes out. The one place a colleague's name can appear in the reply is when the draft says one of your agents is standing in for another, and only when the ticket already names them. Your customers' names are treated differently throughout, because your customer never chose any of this.

A connected store or billing account is a second source of the customer's name, and it is masked too. The masking above works from the contact field your helpdesk supplies. When you connect WooCommerce, Shopify, Stripe or Freemius, that system returns its own record of the customer, and the two spellings often differ: a billing contact rather than the writer, a company name, a middle initial. Overdesk registers the store's spelling as well before it builds the block, so that name is replaced on the way to the model and put back in the draft your agent reads, exactly as the helpdesk's spelling is. The other facts in that block are left readable on purpose: an order number, an amount, and the items on the order, so the model can see what they actually bought; the state each order, payment or subscription is in, which covers a refund, an unpaid invoice, a payment past due and a cancellation; a plan name and the dates it renews or ends; the day they first bought from you; how many orders they have placed and what they have spent with you; which products they are licensed for and on how many sites; and the last four characters of a licence key. A draft that quotes a tokenised order number answers nothing, which is the reason, but it means this block is an exception to the rest of this section rather than an instance of it.

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. Who sends a reply

Unless your workspace turns sending on, Overdesk places its drafts into your helpdesk unsent. By default a draft arrives as an internal note; on Help Scout, 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. Overdesk cannot place an unsent draft on Zendesk, Intercom or FreeScout, so there it stays an internal note, whichever way your team chose to receive drafts.

FreeScout gets an internal note, never a draft reply, and we would rather say why than leave you to wonder. FreeScout is self-hosted, so the version running is yours to choose, and its API and Webhooks module has no way to report that version to us. We read the vendor's own source to establish what happens when a module is too old to recognise an unsent draft reply: FreeScout treats a reply whose state it does not recognise as one to publish, so on an older module a draft could reach your customer unread. We cannot tell which module you run, so Overdesk does not write a draft reply to FreeScout at all. Every reply Overdesk holds back there, and every follow-up nudge Overdesk does not send, arrives as an internal note, never a draft reply, on any module version, with sending on or off. A note never reaches your customer.

Sending replies

A workspace can have Overdesk send replies itself, and it is off unless two keys turn. The Overdesk team enables sending for your workspace, and then an admin of your workspace chooses Send replies automatically under Send mode in Guardrails. A workspace we have not enabled cannot turn it on: the database refuses to store that setting without the first key. Either side can turn it off at any time.

What is sent. Only the replies your guardrail rules approve, and only replies Overdesk drafts in its own runs: when a new customer message arrives, and on its 15-minute schedule (which Run auto-draft starts early). The daily follow-up run, which writes a short check-in to a customer who has gone quiet, sends its nudge only when Also send follow-ups is on in Guardrails, and it is off until an admin turns it on. A draft somebody asks for on one conversation, with Re-draft, with /overdesk draft in Slack, or through the API, is never sent. Every other reply stays a draft or a note for your team, exactly as above.
What is never sent, whatever the rules say. A reply in a conversation Overdesk handed to a teammate, until that issue is resolved. A reply to a customer you have erased. A reply that would also reach someone copied on the conversation whom you have erased or excluded. A reply that claims a person wrote it, or talks about where its answer came from. A reply that carries a licence key, an API key, a password or code written beside its label, or a password written after its username or as a WordPress application password, as Section 3 describes them, is held for a person instead of being sent on its own. A reply the limits below stop.
What the starter rules hold. A reply to a customer who asked for a person, a reply to an out-of-office message, a no-reply sender or a bounce, and requests about billing, refunds, legal matters and account security all wait for your team under rules that start switched on (see the Guardrails rules in your dashboard).
Limits. At most 10 replies an hour per workspace by default, which an admin can change under Rate limit in Guardrails. No reply when the customer's message arrived within 3 minutes of Overdesk's last reply in that conversation, or repeats one of their earlier messages word for word, so two automated systems cannot keep answering each other. And after 5 replies in one conversation in 24 hours, a default an admin can change in Guardrails, the next reply waits for a person.
Help desks. Sending works on Help Scout, Zendesk, Intercom and FreeScout, on the channels in the table below. A reply in a conversation on any other channel, such as a phone call, an SMS or a social message, waits for your team, and the decision log says "Overdesk doesn't send on this conversation's channel yet".
After a reply. The status the conversation is left in is your choice for each help desk, and it applies to every reply Overdesk sends there (the table lists the choices). A reply that tells the customer their question was passed on, or that they will hear back, is the exception: it leaves the conversation in your team's queue whatever you chose, and Overdesk then assigns the conversation to the person who has to keep that promise, with a note saying why. That is the escalation target the reply hands the question to, when that is its only promise, or else the one your team ticked as keeping the promises replies make. With nobody ticked, such a reply waits for your team instead, and so does one bound for the ticked person whose promise is written in a language other than English. On Intercom the reply itself first assigns the conversation to the teammate your access token belongs to, and Overdesk then assigns it on to that person. A teammate hands an Intercom conversation back to Overdesk by adding a note to it.
What your customer receives. Your help desk adds to the email, not Overdesk. Zendesk adds its own footer ("This email is a service from" your company's name, then "Delivered by Zendesk"), the quoted original message and feedback buttons, and anyone copied on the ticket gets the reply too. Intercom adds the signature of the teammate your access token belongs to and "We run on Intercom". On Intercom, replying also assigns the conversation to that teammate, and in our testing closing it sent the customer no rating request. A line at the end of the reply saying AI helped write it is available, and off unless you turn it on.
The record. Every decision is recorded with the rule that made it and a redacted excerpt, and kept for 180 days (Section 6). A reply Overdesk sent is marked on its draft as sent by Overdesk rather than by a person on your team. After the draft is deleted at 180 days, a record of the conversation and message the reply went to and a fingerprint of the reply, never its text, keeps that mark as long as the workspace exists (Section 6).

Help desk	Sends on	Status after a reply, your choice	A hand-over reply leaves it
Help Scout	Email	Pending (the default), Active, Closed, Leave as is	Active
Zendesk	Email and API tickets	Open, Pending (the default), Leave as is	Open
Intercom	Messenger and email conversations	Close (the default), Leave as is	Open
FreeScout	Email	Active, Pending (the default), Closed, Leave as is	Active

Intercom closes the conversation as a second step after the reply, and a reply from the customer reopens it.

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), and so do findings, with the licences, subscriptions and totals kept on a churn or frustration finding's conversations (never an email address, name or licence key, only a stand-in for the address); drafts, triage, alerts, the redacted guardrail decision log and the pseudonymised record of each test site are kept 180 days; draft feedback (each draft paired with the reply your team sent, and what changed) is kept 180 days from its last update, after which a draft your team discarded with no reply keeps only a marker with no text, so its conversation stays out of search; a zip file of your own product is kept until you remove it; search-query logs 90 days; your indexed knowledge base lives for the life of the workspace. For each reply Overdesk sends it also keeps a record that Overdesk sent a reply, holding the conversation and message it went to and a fingerprint of the reply, never its text, as long as the workspace exists, so the reply is still recognised as Overdesk's after its draft is deleted. 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. The address you erased goes on that list too, so a conversation of that customer that Overdesk had not imported yet, one still open in your help desk, gets no drafted reply, no follow-up nudge and nothing sent from Overdesk's own runs. The account facts a finding keeps about the customer are found by the stand-in for their address, including on a conversation that is still open, and are deleted with every finding's record of those conversations; those conversations join the suppression list, and no later analysis looks that address up again. Both the knowledge base's copy of the address and this stand-in are derived from our encryption key, so if that key were ever rotated, records written before the rotation could no longer be matched to an erasure request.

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. 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-10-28: Section 6 now says what an erasure covers in Overdesk's own runs. Erasing a customer also keeps their address, so a conversation of theirs that Overdesk had not imported yet, one still open in your help desk, is never drafted, nudged or sent a reply on its own, as one already imported never was. A follow-up nudge that meets one of your escalate rules is now escalated with a note and an alert, as a reply is, and a nudge that Overdesk sends carries the same ai-sent tag as a reply it sends. The Terms and the Privacy Policy are unchanged.
2026-10-27: Sections 5 and 6 now say that for each reply Overdesk sends it keeps a record of the conversation and message the reply went to and a fingerprint of the reply, never its text, as long as the workspace exists, so a reply Overdesk sent is still recognised as its own after its draft is deleted at 180 days; erasing a customer deletes the record for their conversations. The Privacy Policy says the same in Sections 4 and 9, and its version moves to 2026-10-27, so your team will be asked to accept it once.
2026-10-27: Section 5 now says a workspace that has turned sending on can also have Overdesk send follow-up nudges, the short check-in it writes to a customer who has gone quiet. It is one rule, Also send follow-ups, off for every workspace until an admin turns it on, and a workspace with sending off still gets every nudge as a note or a draft reply for a person to send. With it on, Overdesk sends a nudge only where it sent the answer to the customer's last message itself, and only on a weekday in your workspace's time zone. Your gates and the rules that read tags, keywords or the customer, the holds that read a nudge's own words and the send-time holds all apply to a nudge, and the rules that allow a reply never allow a nudge. A nudge also follows only a message those rules already cleared. A nudge is also held when a teammate wrote in the conversation (a note or a reply) after Overdesk's reply, so it is only ever a follow-up to Overdesk's own reply, or when the last reply told the customer, in wording Overdesk recognises in English, that your team would get back to them. Every nudge Overdesk does not send still arrives as an internal note or a draft reply, and a nudge is never written for a customer you have erased. The Terms and the Privacy Policy are unchanged.
2026-10-26: Section 5 now says FreeScout gets an internal note and never an unsent draft reply, with sending on or off. Overdesk cannot read which version of FreeScout's API and Webhooks module you run, and a module older than the one that recognises a draft reply can publish it to your customer, so it no longer writes one there. The unsent draft reply option remains on Help Scout. Nothing about who sends a reply has changed: a person still sends every message unless your workspace turns sending on. The Terms and the Privacy Policy are unchanged.
2026-10-23: Draft feedback, each draft paired with the reply your team sent and what changed, is now kept 180 days from its last update (Section 6); a draft your team discarded with no reply keeps a marker with no text after that, so its conversation stays out of search. Section 2 now says a Help Scout connection authorised through Overdesk's own Help Scout app runs under that app, and Section 3 now says a social-security number written with dashes or spaces is always replaced. The Privacy Policy now says the phone numbers replaced are North American ones, names Cal.com, which hosts our demo booking page, says connecting Help Scout through Overdesk's app sets the same fifteen-minute cookie as Google Docs and Slack, says our billing and usage records are deleted with the workspace while Stripe keeps its own billing history, and says an erasure record keeps the address erased. Its version moves to 2026-10-23, so your team will be asked to accept it once.
2026-10-19: Sections 1, 3 and 5 now name more of the passwords replaced before the model reads a ticket, and held if a reply repeats one. A password written after its username is replaced, as in "login: admin / Hunter2x9!" or "user bob, pass Hunter2pass", and so is a WordPress application password with no label beside it. Once one is replaced, every other copy of it in the same text is replaced too. A labelled value of six or more digits, or one holding an "@" and a dotted name, is now replaced as a password: before, it was read as a card number, a phone number or an email address, and a reply that repeated it was given the real value back. Conversations stored with such a password readable, including those synced before 28 September 2026, are fetched again from your help desk once and stored with it replaced.
2026-10-19: When you sign up, Overdesk now keeps how you found us: the campaign tags on the link you followed, the page of our website you started on, the site that sent you there and the button you clicked. It is kept with your workspace record and never used for advertising. Our websites pass it to the sign-up form in the link's address and store nothing in your browser. Our team is also emailed when anyone starts signing up, with what was typed into the form, whether or not the sign-up is finished. The Privacy Policy moves to version 2026-10-19, so your team will be asked to accept it once. Nothing changes in what the app does or in how your support content is handled.
2026-10-18: Section 5 now says Overdesk does not send a reply on its own that would also reach someone copied on the conversation whom you have erased or excluded. Before it sends, it checks everyone copied on a Zendesk ticket, everyone in a Help Scout conversation's CC and BCC, and everyone else in an Intercom conversation, against your excluded senders, your rules' customer lists and the people you erased, whenever they asked, and holds the reply for your team if one of them is there or cannot be checked.
2026-10-16: Section 5 now says Overdesk cannot place an unsent draft on Zendesk or Intercom, so a draft there is always an internal note, whichever way your team chose to receive drafts. On Intercom, a reply that passes the question to your team, or says the customer will hear back, can now be sent like on the other help desks: it leaves the conversation open, and Overdesk assigns it to the person who keeps that promise (Section 5). Who Overdesk assigns a conversation to is now set for each help desk you connect, and a conversation is only ever assigned to someone on its own help desk. The Terms and the Privacy Policy are unchanged.
2026-10-15: Overdesk can now send replies on Zendesk, Intercom and FreeScout as well as Help Scout (Section 5). A table in Section 5 now says, for each help desk, which channels it sends on, which statuses your workspace can leave a replied conversation in, and what a reply that passes the question to your team leaves; a reply on any other channel waits for your team. Section 5 also says what Zendesk and Intercom add to the email your customer receives. While sending is on, a FreeScout reply Overdesk holds back is now always an internal note and never a draft reply, so the older-module risk described in Section 5 applies only while sending is off. Who can turn sending on, what is never sent and the limits are as before. The Terms and the Privacy Policy are unchanged.
2026-10-11: More replies that make a promise can now be sent (Section 5). A reply that answers what it can and whose only promises are passing the rest of the question on, or that the customer will hear back or be followed up, with or without a day, can go out even when it names none of your escalation targets. Overdesk then assigns the conversation to the person your team ticked as Keeps the promises replies make, with a note that quotes the promise word for word, and sends nothing more in it until the issue is resolved; until someone is ticked, these replies wait for your team as before, and so do they when the promise is written in a language other than English. A reply that can't answer the question goes out only when it says the question was passed on. A part answered with a guess, or one the writer says they will look into or find out themselves, is not answered, so such a reply waits for your team; for a reply written in English, Overdesk also looks for the second kind itself and holds the reply when it finds one. So does a reply that also promises a fix, a change or an outcome, makes the promise wait on a condition, asks for a way into the customer's site or accounts or for a secret, or offers to look at their site; for a reply written in English, Overdesk also checks for the condition, the way in, the secret and the offer itself. So does a reply with one of these promises, written in English, that mentions money or an entitlement anywhere, such as a refund, a price, a licence or a renewal, unless it answers the question and its only promise hands the question to one of your escalation targets. Separately, a reply that answers all it can and asks the customer only for information they haven't given yet can now be sent like any approved answer, but not one that also promises to get back to them, or asks for a way into their site or accounts or for a secret such as a token, a config file's contents, a cookie or a connection string. The reviewer is told to hold those in any language, and for a reply written in English Overdesk also checks for them itself, holding one that names such a secret anywhere, even in a how-to step, though not a word that names no secret there, such as clearing cookies, a cookie banner or blurring a token out of a screenshot. The alert Overdesk raises after a hand-over names who has the conversation and never quotes the reply. The last sentence of the 2026-10-02 entry no longer holds.
2026-10-09: Our websites, overdesk.io and docs.overdesk.io, now count visits with Cloudflare Web Analytics, which sets no cookie of its own. Cloudflare already served both sites and is now listed in the Privacy Policy's sub-processor table. Section 7 there says what the count records, and names the one cookie Cloudflare's automated-traffic check sets. The Privacy Policy moves to version 2026-10-09, so your team will be asked to accept it once. Nothing changes in what the app does or in how your support content is handled.
2026-10-08: Sections 1 and 3 now say exactly which phone numbers and passwords are replaced before the model reads a ticket. North American phone numbers written with dashes, dots, spaces or brackets, such as (555) 123-4567, are replaced. Other national formats can reach the model in whole or in part, and a number typed as one bare run of digits is left as written, because in a live ticket that is far more often an order number. A password is replaced only when it sits next to a label and is one unbroken string that mixes letters and digits, or a string of 12 or more different characters, fairly evenly spread, that mixes upper and lower case with a symbol from ! @ # $ % ^ & *, and the label is one Overdesk reads (English, German or Dutch, such as password, Passwort or wachtwoord), so a number on its own, an ordinary word, a passphrase or a label in another language is read as written. A licence key's secret part is replaced, but a vendor prefix can stay readable, and a key under 20 characters with no label beside it can be left as written. This page used to say every phone number was replaced.
2026-10-02: A reply Overdesk sends may now tell the customer their question was passed to one of your escalation targets (Section 5). It is sent only when that target is a person your help desk can assign and nobody else owns the conversation; Overdesk then assigns the conversation to them with a note saying why, and sends nothing more in it until the issue is resolved. Such a reply leaves the conversation Active, whatever your reply status setting. Every other promise in a reply still waits for your team.
2026-09-26 (second change today): A workspace can now have Overdesk send replies itself (Sections 1 and 5). It takes two keys, ours and your admin's, and either side can turn it off at any time. With it on, Overdesk sends only the replies your guardrail rules approve, some replies are never sent whatever the rules say, at most 10 replies an hour go out by default, loop guards stop Overdesk answering an automated reply, and every decision is recorded. Sending works on Help Scout first. A workspace that does not turn it on is unchanged: every draft still waits for a person. The Terms of Service say the same in Section 1 and move to version 2026-09-26, and the Privacy Policy says it in Sections 4 and 12 and moves to 2026-09-26b, so your team will be asked to accept both once.
2026-09-26: When a churn or frustration analysis names customers who may leave, Overdesk now looks up to 25 of them in a licence system or billing account you connected, the same lookup a draft makes, and keeps with the finding the licences or subscriptions each holds, when they expire or renew, and what they have paid you, so the finding can say what is at stake (Sections 2 and 6). Nothing new goes to a model, a webhook or an issue tracker, and no email address, name or licence key is kept: only a stand-in for the address, which is how erasing a customer finds these facts, even on a conversation that is still open. They follow your plan's report retention. The Privacy Policy says the same in Section 4, with a new retention row in Section 9, and its version moves to 2026-09-26, so your team will be asked to accept it once.
2026-09-25: Overdesk can try a customer's issue on a private test copy of WordPress with your products before it replies (Sections 2 and 3): the machine has no route to anything else, the contact details the pseudonymisation pass replaces never reach it, and a pseudonymised record is kept with the reply for 180 days. A zip file of your own product, added on the Sandbox settings page, is kept until you remove it. Two more things reach the draft prompt: the WordPress, plugin and theme versions a linked page's code shows, and, from a licence system, the sites a customer installed your product on with the versions each reported. Also newly written down here: since 16 September a PDF a customer attaches is read the way a picture is, one per draft of up to ten pages, which the Privacy Policy said and this page did not. The Privacy Policy's version moves to 2026-09-25, so your team will be asked to accept it once.
2026-09-14 (second change today): Overdesk now opens pages your customers link to, while a draft is being written, and gives the model the readable text it finds. Before this, a link in a ticket reached the model as an address and nothing else, so a draft could only guess at what was on the other end. Up to three pages per draft, nothing stored, and the page is fetched with none of your help desk credentials attached. Only links in your customers' own messages are opened. There is a switch for it on the Customize AI page, on by default, and a linked picture is governed by the pictures switch instead. Sections 2 and 3 carry the detail, including what a third-party website learns when we open one of its addresses. The Privacy Policy says the same in Section 4 and its version has moved to 2026-09-14b, so your team will be asked to accept it once. We are aware that is the second request today. Each change had to be published before the behaviour it describes went live, and from now on the two documents carry their own version numbers, so a change to one of them no longer asks you to re-accept the other.
2026-09-14: The switch the entry below promised now exists, on the Customize AI page in your dashboard, and it is on by default. Turn it off and Overdesk stops sending your customers' pictures to the model, and drafts on those tickets are written from the words alone. Nothing else about how pictures are handled has changed, and nobody needs to email us for this any more. The switch covers pictures only: log files and other text attachments carry on being read, because they go through the pseudonymisation pass in Section 3 exactly like the message they arrived with, which is the limit the switch exists to answer. The Privacy Policy says the same thing in Section 4 and its version has moved to 2026-09-14, so your team will be asked to accept it once. Anybody already signed in sees that request the next time they open Overdesk, and nobody has to sign out for it.
2026-09-12: Overdesk can now see the pictures your customers send. A screenshot attached to a ticket, or pasted into an email, is fetched when a draft is written and sent to the model with the rest of the conversation, and so are log files and other text attachments. Before this, the model was given the file's NAME and nothing else, which is how a draft could thank somebody for a screenshot it had never seen and then answer around it. Three things follow and all three are now in Sections 2 and 3. A log file is pseudonymised like any other text. A picture is not, because the pass reads text and cannot read inside an image, so anything legible in a screenshot reaches the model as your customer sent it. And Overdesk stores nothing: the file is fetched while the draft is being written, sent, and discarded, so there is no new place your customers' pictures live inside Overdesk. The destination is unchanged, it is still your own Anthropic account under your own key, so what Anthropic does with a request is governed by your agreement with them rather than by anything we can promise on their behalf. There is no dashboard switch yet; email us and we will turn this off for your workspace by hand.
2026-09-02: The masking of other people's names on your customer's side is no longer particular to drafts. Section 3 used to say that it covered writing a draft and not the other things Overdesk asks a model to do, which was true and was the narrower half of a promise worth keeping whole. Every use of a model that reads a ticket's messages now registers the same names: classifying a ticket, nudging a customer who has gone quiet, filling in a new issue on a tracker you have connected, and the summaries behind your reports and analyses. Nothing new is sent anywhere and no new party receives your data. The same text goes to the same model with more of it masked, and your team's own names are unchanged and still readable, for the reason Section 3 gives.

One correction in the same breath, found while checking that the sentence above was true everywhere it is made. The Slack row in Section 2 said every one of the things Overdesk posts to your workspace has your customers' names replaced with "(customer)". That holds for a report and for an alert. It did not hold for an answer Ask Overdesk writes about an archived report, because that answer was built from the copy kept in your dashboard, which has the real names in it. The code has been changed to match the promise rather than the promise quietly narrowed: a report is now archived with a second copy that has the names already replaced, and that is the only one Ask Overdesk will read. A report archived before this change has no such copy and cannot be given one, because the substitution cannot be run again after the fact, so Ask Overdesk declines to read those and says why.
2026-09-02: One narrowing in Section 3, in favour of the answer your customer gets. Overdesk masks a customer's name by substituting each word of it wherever that word appears in the prompt, and the prompt carries your own help articles and past tickets as well as the ticket being answered. When a help desk had filed a contact under a mailbox word, that word was replaced throughout, so the model read your own documentation with a hole in it. Those words, and the usual company endings, are now left readable. Nothing that identifies a person stopped being masked: a name with an ordinary word anywhere in it is still masked in full, and a bare mailbox word identifies no person. There is one real cost and it is worth naming. The article a company name starts with is on that list, and it is also a syllable in Vietnamese names written without their accents, so a record spelled that way loses that one syllable while the full name and every other part of it stay masked. The same entry is the largest single improvement here, because that word appears in about half of everything a knowledge base holds. Where a customer's whole record is a mailbox word, there is then no name for us to replace, so it also reaches your own Slack or ClickUp workspace as written rather than as "(customer)".
2026-09-01: FreeScout is now a supported help desk, and four systems can be connected to give a draft your customer's real account state: WooCommerce, Shopify, Stripe, and Freemius. Connecting one means your end customer's email address is sent to that system to look them up, and what comes back goes into the draft prompt. Both are now in Section 2, and Section 3 says plainly that this block is deliberately left readable, apart from the connected system's own record of the customer's name, which is masked like the rest. The four lookups have been part of the product since the middle of August and this page did not say so, which is the drift this changelog exists to catch and did not.

One further correction and one further disclosure, both in Section 3. The name masking used to work only from the ticket's requester, so anyone else on your customer's side who had written one of the messages, a colleague copied in or a second contact at the same company, reached the model under their real name; every one of those authors is masked now. And your own agents' names are not masked, which has always been true and is now explained rather than left for you to discover. Section 3 also states which of Overdesk's uses of a model this author masking covers, and that a name your helpdesk holds as only one or two letters is left as written.

Also newly written down, none of it new behaviour: the Slack row now names Ask Overdesk and alerts rather than only scheduled reports, and says that everything reaching your workspace has your customers' names replaced with "(customer)", correcting a sentence on the Privacy Policy that had this backwards and said the names were restored; opening the Google Docs picker loads a script from Google in your browser; the Google Docs connection is authorised through Overdesk's own Google application rather than one of yours, as is the Slack app your team installs; and the two Stripe rows are now labelled, since one is your own account that we read and one is ours that bills you. Section 5 states the FreeScout version question that decides whether a draft stays unsent, and explains why a current module does not send one. Two earlier changes reached this page with no entry here: on 28 August the Anthropic row began naming the repository code a connected GitHub account sends to the model, and on 29 August Section 3 began naming which credential-shaped query parameters are replaced inside a link. Retention is unchanged, and a person still sends every message.
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.