Security and data
Where a connected tool's credential is kept, what Adduce stores and what it never does, how long each thing is held, and who else processes it.
This page states what Adduce does with a credential you give it, what it keeps from the tools it reads, and how long each of those things lasts. It describes mechanisms that exist in the product today. It names no certification and no audit, and it is not a security assessment.
Where a credential goes
A credential is split the moment a source is saved: the secret parts go to a separate secrets store, and the workspace database keeps only an opaque handle pointing at them. The connector catalog marks which field of each tool is secret, so the split is a property of the connector rather than a judgement made per workspace.
| Question | Answer |
|---|---|
| What holds the secret values | A dedicated secrets store, Infisical, outside the application database |
| What the database holds | A handle, and the non-secret settings — a region, a subdomain, a project ID |
| When the secret is fetched | Inside the sync step that calls the tool, and it is not carried into any other step |
| Who can read it back | Nobody. No screen shows a stored credential, and there is no edit form for one |
| How to rotate one | Delete the source and add it again with the new value. The next sync backfills afresh |
The same holds for a destination: disconnecting deletes the stored credential and removes the control it powered, and work already created in the other tool is left as it is.
What a credential is allowed to do
Every source credential is a read credential. Nothing Adduce reads a tool with can write to it, and two sources need no credential at all.
| Kind | What the credential is asked for |
|---|---|
| A source | Read access to the surface named on that tool's Connect page, and nothing else. No write scope is requested anywhere |
| App Store reviews | Nothing. Apple publishes the reviews feed openly, so this source holds no key, token or secret |
| Call transcripts | Nothing. There is no tool to connect to — the files are ones you upload |
| A destination | Permission to create the one thing you asked for: an issue, a page, a message, or a signed POST to your own endpoint |
How narrow a read credential can be made is set by the tool, not by Adduce. Some can be scoped to exactly what is read — a read-only PagerDuty key, a Datadog application key limited to monitors and logs, Monitoring Reader on one Azure resource group, Viewer on one GA4 property. Others have no narrower option than the whole project: an Amplitude API and secret key pair grants read access to that Amplitude project entire. Each Connect page carries a Permissions table naming the exact scope that tool needs, and why each one is asked for.
What is stored, and what is never stored
What lands in a project is evidence: a quote as it was said, or a count, with a link back to the record it came from. The raw material behind it is not always kept, and for two sources it is deliberately never kept.
| Source | What is stored |
|---|---|
| Slack | The extracted evidence text and a permalink back to the message. Raw messages are never written down — they exist only inside the sync step's memory |
| Amplitude | Counts, trends and funnel results. Raw events are never stored: each sync folds a chunk of the export into counts and discards it |
| Call transcripts and Gong | The transcript itself, as a file in the storage Adduce holds for your workspace, plus the evidence taken from it |
| Every other source | Evidence and its link back. What the tool holds stays the record |
Two consequences follow, and both are worth knowing before you connect anything.
- The origin tool stays the record. Deleting or redacting a message in Slack does not reach back into Adduce: the evidence row keeps what was extracted, and its link stops resolving.
- Deleting a source deletes its evidence. The evidence that source produced goes with it, and any theme built from it loses that part of its case.
Who can reach it
Every read and every change is scoped to the workspace on your session, never to an identifier in the request, so one workspace cannot ask for another's data by guessing at it. Inside a workspace, a source belongs to one project and nothing crosses between projects: two projects reading the same account each hold their own source and their own credential.
Reaching a project you are not a member of fails as though the project were not there. Which roles reach what is set out in Roles and permissions.
How long each thing is kept
Account and workspace data stays for as long as the workspace does. Everything with a clock on it is below.
| Thing | How long |
|---|---|
| A workspace scheduled for deletion | Removed after 7 days. An admin can cancel within that window; after it, nothing can be brought back |
| A workspace whose subscription has lapsed | Held for 30 days, then removed. Exporting and starting a plan again both stay available throughout |
| An export archive | Downloadable for 7 days from the day it is built. One export is prepared at a time, so you can ask for another as soon as the current one is ready |
| A source you delete | Removed at once, with the evidence it produced |
| Your own account, closed by you | Closed straight away, unless you are the sole owner of a workspace — hand it over or delete it first. What you wrote stays in the workspace, no longer attached to your name |
| An enquiry sent through the public site | Kept for 24 months from last contact. Nothing clears it on a schedule — a person removes it |
When a scheduled deletion runs, a daily job removes what sits outside the database first — uploaded transcript files, stored credentials and any export archive — and then the workspace record itself.
An export holds your workspace content: projects, evidence, themes, findings, briefs and their comments, investigations, transcripts with their original files, connected sources without their secrets, objectives, key results and strategy. It does not hold enquiries, billing records or notifications.
Who else processes your data
A short list of providers handles data on Adduce's behalf. Each is named below with what it does and where it processes, because a provider that reaches your data should be nameable. The list was last changed on 2026-07-26; changing a provider updates that date.
| Provider | What it does | Where |
|---|---|---|
| Clerk | Sign-in and workspace membership | United States |
| Stripe | Subscription billing and checkout | European Union and United States |
| Neon | Database hosting | European Union, Frankfurt; US parent company |
| Vercel | Application hosting and file storage | United States |
| Vercel AI Gateway | Routing the model requests behind synthesis and Chat | United States |
| Infisical | Storing the credentials for the tools you connect | United States |
| Redis Cloud | Caching the lookups behind role checks | European Union |
| Resend | Sending notification and transactional email | United States |
| PostHog | Product analytics, only after consent is given | European Union, Frankfurt |
| Sentry | Error monitoring | European Union, Germany |
| Cloudflare | Bot protection on the public enquiry forms | Global |
| Attio | The CRM behind sales enquiries | United Kingdom and European Union |
Where a provider processes outside the UK or the EEA, the transfer relies on the standard contractual clauses with the UK addendum, and on the Data Privacy Framework where that provider is certified under it.
Related
- Export or delete your workspace — take a copy out, or start the seven-day clock.
- Manage your plan and seats — what cancelling does, and the thirty-day hold.
- How sources work — the connection test, the daily sync, and replacing a credential.
- Integrations A–Z — every tool, what it reads or writes, and what it needs.