Privacy Policy

Effective date: 2026-09-29 · Last updated: 2026-11-06

This page describes termynl as it works today. It has not yet been reviewed by counsel and will be finalized before general availability.

This policy explains what personal data the hosted termynl service collects, what we do with it, who we share it with, how long we keep it, and the rights you have. termynl is operated by HODY, based in Maryland, USA ("termynl", "we", "us"). Questions and requests: hello@termynl.com.

1. Scope

This policy covers the hosted termynl service (the web app at console.termynl.com, the API and MCP endpoint at api.termynl.com) and our websites termynl.com and docs.termynl.com.
termynl is a business-to-business work platform for tasks, issues, projects, docs, saved views and AI agents. It is sold to organizations, not to consumers.
Self-hosted termynl is not covered. If your organization runs the self-hosted build on its own infrastructure, that organization decides how data is handled and is responsible for it. We do not host, receive or process the data in a self-hosted installation, and we are not a processor for it.

2. Our role: processor and controller

Customer Content (what a workspace's users create or upload: tasks, issues, projects, docs, comments, views, files, and AI conversations) is processed on behalf of the customer organization that owns the workspace. For that data the customer is the controller and we are its processor (a "service provider" under U.S. state laws). If you use termynl through your employer or another organization, send requests about Customer Content to that organization; we will help them respond.
Account, billing, security and website data (who you are, how you sign in, subscription and payment status, security logs) is processed by us as controller, as described below.

3. What we collect

3.1 Account and profile

Your email address, name, and a random internal account identifier (never derived from your email address).
The sign-in methods linked to your account (Google, Microsoft work or school, GitHub, an emailed sign-in link, or your organization's single sign-on) and the provider's identifier for you.
Profile details you choose to add, such as display name, pronouns, time zone and a profile picture. Profile pictures are stored on our servers with image metadata removed.
Your workspace membership: role (owner, admin, member or guest), status, how you joined (invitation, verified domain, group, SCIM), and the teams you belong to.
Your preferences, such as theme and keyboard settings.

3.2 Sessions and security records

For each signed-in session: the device's user-agent string and a coarse IP prefix (the first three parts of an IPv4 address, or the first 48 bits of an IPv6 address). We do not geolocate it. You can see and end your sessions in your profile.
Security events, such as sign-ins, linking or unlinking a sign-in method, two-factor changes, and deletion requests.
If you turn on two-factor authentication: each passkey or security key's public key, credential ID, name, signature counter, transports (such as USB or NFC), whether it is backed up (for example synced by a password manager), and when it was added and last used; your authenticator app's secret (stored encrypted), your backup codes (stored only as one-way hashes), and for each device you choose to trust, its user-agent string, coarse IP prefix and expiry. If a workspace admin resets your two-factor authentication, these records are deleted from our live systems, your sessions are ended and your connected apps' access is revoked, the reset is recorded in the workspace's audit log, and we send you an email. Deleted records may remain in a backup until that backup is deleted (see section 9).
Single sign-on (SSO). If your workspace sets up SSO with its own identity provider (SAML or OpenID Connect), we store: the connection settings an admin enters (metadata or issuer address, client id, certificates and their expiry, options, test results); the client secret, if the workspace uses OpenID Connect, only sealed (encrypted) and never shown again; for each person who signs in, a stored link made of the provider's identifier for you kept only as a one-way hash (not the identifier itself), the email address the provider sent, and whether the link was confirmed with termynl two-factor sign-in; the time of your SSO sign-ins to termynl (to apply the workspace's session length) and the time the provider says you last authenticated there (to confirm sensitive changes); and audit entries for sign-ins (including when an OpenID Connect provider did not say whether your email is verified), refusals (with a reason code), link resets and changes to the SSO settings. While a sign-in is in progress we keep short-lived records: the sign-in request for up to 10 minutes (a hashed request id, a hashed browser-binding value, the account and session that started a test or a confirmation, the termynl page to return to, and for OpenID Connect a sealed one-time value); a single-use hand-off record for up to 2 minutes that holds the provider's identifier for you as sent (not hashed), your email address and the names of the attributes the provider sent, deleted once the sign-in finishes or expires; and the assertion id (kept only until the assertion would expire, to stop it being used twice). We do not keep SAML assertions, ID tokens or access tokens from your identity provider, and we do not log them. The provider's response can contain other attributes or claims (for example your name), depending on how your workspace set it up. We use only your email address, your identifier, whether the provider says your email is verified, and when you authenticated there, and we keep only the records listed above (for the test sign-in an admin runs, the email address and the names of the attributes the provider sent, not their values).
A membership audit log per workspace: who invited, changed, deactivated or removed whom, and when. It also records changes to a team's task, issue and project statuses (who added, renamed, reordered or deleted one, with the status names as typed and how many items were changed), and GitHub changes (connecting or disconnecting an account, repositories shared with a team or project, status-move rules, links added or removed by hand, a person connecting their GitHub name, changes to the GitHub settings, registering a self-hosted server's GitHub App, and Tyn or a connected app reading a pull request's description), with repository names, pull request numbers and GitHub usernames, never titles, descriptions or code. It also records each time someone downloads a doc, task, issue or project as Markdown: who, which item (by id) and the format, never its content.
An audit log for connected apps (MCP clients) that records authorization events. It never holds raw tokens or the arguments of tool calls. Entries made through a connected app record the app's name as it was at that time.
Audit log streaming. If a workspace admin adds a streaming destination, every new audit log entry of that workspace (who did what and when, including names, account ids and the email addresses the log shows) is also sent to that destination: a web address, an S3-compatible bucket or a syslog server the customer configures. We keep the destination's settings with its credentials encrypted, and the entries still waiting to be sent to it (references only, up to 100,000 per destination) until they are delivered or the destination is removed. Destinations are never included in exports.
Our servers and Cloudflare (see section 7) process IP addresses, request details and user agents in operational and security logs.

3.3 Customer Content

Teams, projects, tasks, issues, docs, comments, labels, saved views, and conversations with Tyn, the in-app assistant.
termynl records every change as an entry in an append-only change history. This powers activity, notifications and version history. Deleting an item in the app marks it deleted and hides it. Its earlier versions remain in the workspace's change history.
On our current hosted service, docs are also written as Markdown files to our server's disk, as a one-way copy of the doc content.

3.4 Files and attachments

A workspace admin chooses where attachment files are stored: the organization's own Google Drive, OneDrive, or an S3-compatible bucket. The file bytes are stored there, not in our database. Storing attachment files on our own servers ("local storage") is offered only in the self-hosted build. The one thing the hosted service holds on our own servers for a time is the temporary, encrypted audio of a recording you make with Record notes (section 3.12).
We keep the information needed to find and show each file: its name, type, size, checksum, storage location, and the item it is attached to.
Uploads and downloads pass through our servers. While an upload is checked and transferred, it is written to a temporary file on our server that only the service can read. The temporary file is deleted when the transfer finishes or fails. Moving files between storage backends uses the same kind of temporary file.

3.5 Connected accounts and the permissions we request

termynl uses OAuth to connect to Google (including Google Meet), Microsoft, GitHub, Notion and Zoom. We request only the permissions below, each for the stated purpose. Access and refresh tokens are encrypted at rest (AES-256-GCM).

Purpose	Provider	Permissions (scopes)	Used for
Sign-in	Google	`openid email profile`	Confirming your identity, verified email and name.
Sign-in	Microsoft (work or school accounts only)	`openid email profile offline_access User.Read`	Confirming your identity, verified email and name.
Sign-in	GitHub	`read:user user:email`	Confirming your identity and verified email.
File storage	Google Drive	`openid email drive.file`	Storing and reading attachment files. `drive.file` covers only files termynl created, not the rest of the Drive.
File storage	OneDrive	`offline_access openid email Files.ReadWrite.AppFolder`	Storing and reading attachment files in termynl's own app folder only.
Drive (each member, when an admin turns it on)	Google Drive	`openid email drive.readonly`; the first time a person shares a file, a separate grant with `openid email drive.file`, confirmed for that one file in Google's own file picker	Browsing and searching the files the person can see, linking a file to an item, checking whether the person can open a linked file, and Tyn reading a file when the person asks. Sharing gives the item's people view access to that one file. termynl never edits, moves or deletes files and never stores their content.
Drive (each member, when an admin turns it on)	Microsoft OneDrive and SharePoint (work or school accounts only)	`offline_access openid email User.Read Files.Read.All Sites.Read.All`; the first time a person shares a file, `Files.ReadWrite.All`	The same as Google Drive. `Files.ReadWrite.All` is used only to give the item's people view access when the person chooses to share; termynl never changes or deletes files.
Group gate (admins)	Google Workspace	`admin.directory.group.member.readonly admin.directory.group.readonly`	Checking whether members belong to the groups an admin chose.
Group gate (admins)	Microsoft Entra	`GroupMember.Read.All`, `User.Read.All` (application permissions, admin-consented)	Checking whether members belong to the groups an admin chose.
Bringing in Notion pages (Connect Notion)	Notion	No scopes: Notion asks you which pages to share. termynl's Notion integration can only read content, read comments and read user names, never email addresses.	A one-way sync, run when you press it, of the pages you picked into your workspace's docs.
Meetings and calls (each member, when the Meetings module is on)	Zoom	Zoom's per-user, read-only meeting, recording, summary, transcript, chat, notes, docs, whiteboard, clips, Team Chat, calendar, webinar and contact scopes; Zoom Phone call and voicemail scopes only when a person approves them (asked automatically only when Zoom reports a Zoom Phone licence, or when the person presses Set up Zoom Phone; SMS and a contact's phone number are optional there); `meeting:write:meeting`	Bringing what a person can open in their own Zoom into termynl when they ask, or automatically for meetings they link: meetings and their recording links (never the recording itself), Zoom's summaries and next steps, transcripts, in-meeting chat sent to everyone (private messages are dropped), captions, My Notes, and with Zoom Phone their own call summaries, transcripts and voicemail transcriptions; Zoom contacts to find people when inviting or calling (not stored). The one write is creating a Zoom meeting when the person presses Send invites, Call now or Meeting now.
Meetings and calls, Google Meet (each member, when Meetings and Google Meet are on)	Google	`openid email`, `https://www.googleapis.com/auth/meetings.space.readonly`, `https://www.googleapis.com/auth/meetings.space.created`, `https://www.googleapis.com/auth/documents.readonly`	Bringing what a person can open in their own Google account into termynl when they ask, or automatically for meetings they link: which Meet meetings they had and who joined (names only), Gemini notes and their suggested next steps, transcripts (only when the person can open the transcript doc in Google), the link to a recording (never the recording itself), and notes docs the person pastes. `documents.readonly` is used only for the notes and transcript docs Meet names and the docs the person pastes. The one write is creating a Google Meet when the person presses Call now, Meeting now or Send invites.
Pull requests, branches and commits (a workspace admin connects it; GitHub App, off until then)	GitHub	A GitHub App with read-only repository permissions: Metadata, Pull requests, Contents, Checks and Commit statuses, and the organization permission Members (read), used once to confirm that the person connecting an organization is one of its owners	Linking pull requests, branches and commits to tasks and issues by their keys, showing their state, review and check results, and moving a task's status by the rules the workspace chose. termynl never writes to GitHub. It does not read repository files: the Contents permission is what lets GitHub send push notices (branch names and the first line of commit messages).

Google Meet. Each member connects their own Google account for Google Meet, separately from signing in and from file storage; termynl reads only what that person can open in Google. Google access and refresh tokens are sealed (encrypted at rest with AES-256-GCM) and never shown or logged. Google tells termynl when a meeting's notes, transcript or recording is ready through Google Cloud Pub/Sub; those messages carry resource names only, never meeting content, and are kept 7 days to drop duplicates. Transcripts are read from the transcript doc in Google Docs, only when the person can open it; termynl keeps them nowhere but in the doc the person brought them into. A person can disconnect Google Meet at any time in Settings → Google Meet: termynl then deletes its Google Meet tokens and connection, stops importing, and asks Google to delete its event subscription (best effort; an unrenewed subscription lapses at Google within 7 days). A person can also remove termynl in their Google account's third-party access: termynl then marks the connection broken and stops importing, and keeps its sealed tokens and subscription record until the person reconnects or disconnects in Settings, or the account or workspace is deleted. Google Meet connections are deleted when the person's account or the workspace is deleted. What was already brought into docs stays part of the workspace's content.

Google API Services User Data Policy (Limited Use). termynl's use and transfer to any other app of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Google user data is used only to provide and improve the features the person sees and asks for; it is not transferred to others except as needed to provide those features, for security, to comply with the law, or as part of a merger or acquisition with notice; it is never used for advertising; it is never used to develop, improve or train generalized AI or machine learning models; and no human reads it except with the person's consent, for security purposes, to comply with the law, or when it has been aggregated and anonymized for internal operations.

Zoom. Each member connects their own Zoom account; termynl reads only what that person can open in Zoom. Zoom access and refresh tokens are sealed (encrypted at rest with AES-256-GCM) and never shown or logged. A person can disconnect Zoom at any time in Settings → Zoom, or remove termynl in Zoom's App Marketplace; termynl then deletes its Zoom tokens and stops importing. Zoom connections are deleted when the person's account or the workspace is deleted. What was already brought into docs stays part of the workspace's content.

GitHub (code hosting). Off until a workspace admin connects a GitHub account or organization by installing termynl's GitHub App and choosing which repositories to share. termynl then receives events from GitHub for those repositories and stores repository names, pull request titles and numbers, branch names, the first line of commit messages that name a termynl item, GitHub usernames, check names and results. termynl does not store pull request descriptions, code or diffs, and never reads repository files. When Tyn reads a pull request description because you asked it to, that text is sent to the AI provider running the model for the answer. Coding-agent labels. By default, termynl guesses which coding agent (for example Claude Code, Codex or Copilot) likely opened or worked on a pull request. This is an inference, not a fact GitHub reports. It is made from GitHub data (the author account and its type, co-author lines in commit messages, markers and session links in the pull request description, the branch name) and from termynl's own records of who started work on an item with Create branch or a connected app (the person, the tool and the time). The label names the agent, how sure termynl is, and why; when a work start matches, the reason can name the termynl member who started it. Every member of the workspace who can see the pull request in termynl sees the label. An admin can turn the labels off in Settings > GitHub: termynl then stops working out labels for pull requests as they update and hides every label, but it still keeps the work-start records (they also serve the branch names Create branch offers) and the GitHub data listed above. A person can also connect their GitHub name in Settings > Profile (a one-time check; the sign-in token is dropped at once). The app's access tokens are short-lived and kept in memory only. Admins disconnect at any time in Settings > GitHub. On a disconnect termynl also asks GitHub to uninstall its app from that account; this is the one change termynl ever makes in GitHub, and it is best effort: if GitHub does not confirm, termynl says so, and an owner of the GitHub account removes the app in GitHub (an organization's Settings > GitHub Apps, or a personal account's Settings > Applications > Installed GitHub Apps; then termynl > Configure > Uninstall). Removing termynl in GitHub first does the same cleanup in termynl.
Connect Notion. Each person connects their own Notion account. Notion shows its page picker, and termynl can read only the pages you pick there, read only: termynl never changes anything in Notion. When you sync, termynl reads those pages, their databases, open comments, files and the names of people mentioned, and writes them as docs in your workspace (Customer Content). termynl never asks Notion for anyone's email address. Your Notion tokens are sealed (encrypted at rest). Disconnect at any time in Settings > Import: termynl's Notion sign-in is removed and the docs already synced stay. Your Notion grant and tokens are also removed when your account is deleted (we ask Notion to revoke them first) and when the workspace is deleted. You can also remove termynl from Notion's own connections settings.
Drive. Off unless a workspace admin turns it on, per provider. Each person connects their own Google or Microsoft account; termynl then acts only with that person's own access, never anyone else's, never an admin or app-wide permission. For files people link to items, termynl stores the file's name, type, size, provider ids, web address, the owner's display name (never an email) and when it was last modified; never the file's content. Everyone who can see the item sees that name, even if they can't open the file. When Tyn reads a file for a person, the file's text is sent to the AI provider running the model for that answer and is not stored by termynl (it is not in the database, file storage, the audit log, search, backups or saved chats beyond the answer text); the audit log records that the file was read, never its content. When an app the person connected over MCP calls drive_read, termynl returns the file's text directly to that app (the person's own connected app, under its own terms), without an AI answer from termynl, and stores none of it. When the person opens a linked file in termynl's file viewer, its bytes pass through termynl to their browser and are not stored. When a person chooses to share, termynl asks Google or Microsoft, with that person's account, to give the item's people view access to the file; termynl records who was given access (to show who still can't open it and so the workspace can review it) and never removes anyone's access. Drive tokens are sealed (encrypted at rest) and deleted when the person disconnects, is deactivated or removed, or their account or the workspace is deleted (Google is asked to revoke them unless another termynl connection of the same Google account still uses them). Link metadata stays with the item it is on; the record of who was given access stays until the workspace is deleted. Access termynl gave in a drive stays in that drive until its owner removes it.
Group gate. Membership is re-checked on a schedule. Someone who is no longer in a chosen group is deactivated after a grace period. We store when each member was last checked, not the group's full member list.
SCIM provisioning. If an admin connects an identity provider over SCIM 2.0, that provider sends us user records (name, email, active status) and group memberships.
Verified domains. An admin proves a domain with a DNS TXT record. People who sign in with a verified address on that domain can join the workspace automatically.

3.6 Paused email, calendar and contacts module

Earlier versions of termynl let a user connect a Google or Microsoft mailbox and calendar. That connection requested broader permissions: for Google, gmail.modify, calendar and drive.file; for Microsoft, Mail.ReadWrite, Calendars.ReadWrite, Contacts.Read and Files.ReadWrite.
While it was active, termynl synced and stored copies of connected email threads in our database, including subject, sender, recipients, date, a short preview and the message body (HTML was sanitized). It also stored calendar events and contacts, so they could be searched and linked to work items.
Since 2026-09-25 this module is paused. It is hidden from the app and nothing is synced.
On 2026-10-07 we deleted every stored copy of that data from our database: mail threads, calendar events, contacts, shared mailboxes and the activity, comments and attachment records derived from them, and the mail-change subscriptions at Microsoft. Your Google and Microsoft connections themselves stay (we did not revoke them or delete their encrypted tokens): they are also how you sign in, how the workspace stores files in your Drive or OneDrive, and how your profile syncs, and they will carry email, calendar and chat when those features return. You can remove termynl from your Google or Microsoft account's app permissions at any time; signing in and file storage through that account then stop until you connect again. Attachment files that were stored with that data are removed in a later clean-up.

3.7 AI features

Your messages to Tyn, Tyn's replies, and the content Tyn reads through its tools while answering. Tyn conversations are stored in the workspace like other content.
AI usage per user per month (token counts), to enforce the included allowance. We do not show dollar amounts per user.
API keys an admin adds for their own AI provider account, encrypted at rest.
A Firecrawl API key an admin adds for the organization's own Firecrawl account (section 6), encrypted at rest and never shown again, with the date and result of its last check.
When Tyn uses the web: the sources of an answer (titles and links) and the date a Google-grounded answer was given, saved with the chat; and audit entries for each search, page read, crawl and refusal (section 6).

3.8 Billing

Payments are processed by Stripe. Card details are entered directly with Stripe. termynl does not receive or store card numbers.
We store the Stripe customer and subscription identifiers, subscription status, number of paid seats, current period end, and identifiers of processed Stripe events. The billing contact email is shared with Stripe.

3.9 Email we send

We send service email: sign-in links, invitations, account and workspace deletion notices (including the warnings before a cancelled workspace is deleted), security notices, export notices, seat and membership notices, alerts about directory or domain settings, and, unless you, your team admin or your workspace admin turn them off, notification email about work items: being assigned, changes, and being @-mentioned (an item's key and title, who did it and a link; never its description or comments). You choose which notifications email you, and whether they come one by one or as one daily summary, in Settings → Profile; team and workspace admins set defaults and may require or turn off a type. We do not send marketing email.

We keep a delivery log for each message (the recipient, the kind of message, the email provider's message id and the delivery status, never the subject or the content) for 90 days. Addresses that bounce permanently or report a message as spam stop receiving notification email.

3.10 Uploaded files you bring in (Notion exports and Obsidian vaults)

When you upload a Notion export or an Obsidian vault (a .zip, or a vault sent by termynl Sync), its files are staged on our server in a folder of their own that only the service can read, so termynl can show you a preview before anything is written. A sync from Connect Notion keeps what it read from Notion in the same kind of folder while it runs.
The staged files are kept only for that job. They are deleted when the job finishes, fails or is cancelled. A job you upload but never run is cancelled after 7 days and its files are deleted (we check hourly).
What the job writes becomes ordinary docs and files in your workspace, kept like other Customer Content (section 9).

3.11 Websites

termynl.com and docs.termynl.com are static pages. They use no analytics, advertising or tracking scripts. Cloudflare adds a small script to docs.termynl.com that hides email addresses from spam harvesters.

3.12 Voice, dictation, read aloud and recorded notes

What this is. Talk with Tyn (a spoken conversation), dictation (speech turned into text), read aloud (a doc turned into speech) and Record notes (a recording turned into notes). They are off for trials and guests, and a workspace admin can turn each on or off. A person can also turn voice off for themselves.
What we send to Google. The Gemini API, under Google's paid terms (on termynl's account, or on the workspace's own Google key when it uses one, in which case Google acts under the workspace's own agreement with Google and not as our sub-processor), receives the audio you speak or record, the text to be read aloud, and the context Tyn needs (section 6). Audio is sent inline in the request; we do not upload it to Google's file storage, and any file copy Google were to hold would be deleted right after the request. We do not keep audio from a spoken conversation or from dictation: it is processed as it arrives and is not saved. The text of a spoken conversation (what was heard, which can include other people in the room, and Tyn's answers) is saved as a Tyn chat in the person's own space, like a typed chat with Tyn.
Recordings (Record notes). While you record, the audio is sent in short pieces to our servers, where each piece is encrypted at rest with a key that is separate for each recording. It is kept there only until the notes are written, and is then deleted, unless a legal or data hold applies (then it is kept until the hold is lifted). If Google cannot be reached, the audio waits and the notes are tried again for up to 7 days (longer if Keep recordings is set longer), so an outage does not lose your meeting; after that the audio is deleted and you are told.
Keep recordings (optional, off by default). If a workspace admin turns it on, the audio is moved to the workspace's own chosen storage (section 3.4) in 10-minute parts and attached to the notes. It is deleted after the period the admin chose (7, 30 or 90 days), or earlier if an admin discards it. A legal or data hold stops any deletion until it is lifted. If it is off, the audio is deleted once the notes are written.
What we keep from a recording. The notes (title, summary, action items, transcript) are ordinary Customer Content in the place they were filed (section 9); that doc is the record. Our working copies of the transcript and the notes text are deleted as soon as the notes are written there, or when the recording is discarded or fails. For each recording we keep its title, who made it, when and for how long, the meeting it was started from (its title and attendees), where the notes were filed, how many action items they had and whether the consent question was answered, and a record of these events in the audit log.
Consent. Before a recording starts, the app asks the person recording to confirm that everyone present knows. It is a reminder only. The person recording, and their organization, are responsible for getting the consent the law requires, which in some places (for example some U.S. states and countries) means everyone in the conversation must agree. An admin can turn the question off; that change is audited.
On your device. While you record, unsent audio is also kept in your browser (section 4) until it has uploaded.
Usage. Voice and notes use the same AI usage as chat. We record token counts for the usage allowance, not the audio.

4. Cookies and browser storage

We use only cookies that are strictly necessary to sign you in and keep the service secure. We use no analytics or advertising cookies, so we do not show a cookie banner.

Name	Purpose	Lifetime
`termynl_access`	Your signed-in session (short-lived access token). HttpOnly, Secure, SameSite=Lax.	15 minutes
`termynl_refresh`	Renews your session without signing in again. HttpOnly, Secure, SameSite=Lax.	30 days
`termynl_sess`	A non-secret hint (a one-way hash of your account identifier) that tells the app whether this browser's cached data belongs to you. Secure, SameSite=Lax.	30 days
`termynl_oauth_`, `termynl_link_`, `termynl_connect_`, `termynl_dir_`	Protect a sign-in, account-linking, storage-connect or directory-connect flow against forgery while it is in progress. HttpOnly, Secure, SameSite=Lax.	10 minutes
`termynl_notion`	Protects a Connect Notion flow against forgery while it is in progress (sealed, limited to the Notion connect path). HttpOnly, Secure, SameSite=Lax.	10 minutes
`termynl_sso`	Ties a single sign-on attempt to the browser that started it, so another browser cannot finish it. A random value; only a hash of it is stored. HttpOnly, Secure, SameSite=Lax.	10 minutes
`termynl_mfa_pending`	Ties a sign-in that is waiting for its two-factor step to this browser (a random value; only a hash of it is stored). HttpOnly, Secure, SameSite=Lax.	10 minutes
`termynl_mfa_device_*`	Set only when you tick "Trust this device" at a two-factor sign-in: this browser then skips the two-factor step for that account. A random token; we store only its hash. HttpOnly, Secure, SameSite=Lax. You can forget a device in Settings → Sign-in and security.	The workspace's trust length (0 to 90 days, 30 by default)
Cloudflare cookies	Cloudflare may set strictly necessary security cookies (for example, bot protection).	Set by Cloudflare

The app also keeps a local cache of the workspace data you can already see (up to 20 MB, in your browser's IndexedDB) so it loads quickly. The cache is wiped when you sign out or your session ends. Small preferences and a pending invitation link are kept in your browser's local or session storage. When your workspace starts requiring two-factor sign-in, the id of the waiting two-factor step is kept in local storage so your other tabs open the same step. It is used for at most 10 minutes, is useless without the cookie above, and is removed once you sign in or once it is found expired.

Recording audio on your device. While you record notes, the app also keeps the audio it has not yet uploaded in your browser's IndexedDB (a database named termynl-notes). It is not encrypted on your device. Each piece is removed when it has uploaded. If a recording could not finish, the leftover audio is uploaded the next time you open termynl, or removed after 7 days if it cannot be matched to a recording. Signing out while a recording is uploading asks you to confirm first.

5. How we use data and our legal bases

For people in the EU, EEA and UK, these are the legal bases we rely on as controller. For Customer Content, we act on the customer's instructions.

Use	Legal basis (GDPR / UK GDPR)
Creating and running accounts and workspaces, signing you in, storing and showing content, file storage, AI features the workspace enables	Performance of our contract with the customer; our legitimate interest in providing the service to the customer's users
Billing and subscription management	Performance of contract; legal obligation (tax and accounting records)
Service email	Performance of contract; legitimate interests (security notices)
Security, fraud and abuse prevention, rate limiting, audit logs, operational logs	Legitimate interests in keeping the service and its users secure
Complying with law and responding to lawful requests	Legal obligation

We do not sell personal data, share it for cross-context behavioral advertising, or use it for targeted advertising.
We do not train AI models on your data, and we do not make decisions based solely on automated processing that have legal or similarly significant effects on you.

6. AI processing

Tyn works through the same permission checks you do. It acts as the person using it: it can read and change only what that person can, and its changes are made in that person's name and show in activity and history as "name via Tyn". Changes made through connectors and importers such as Zoom, Notion, Obsidian and GitHub, and the note taker, are made in that person's name and show as "name via tool"; the Sync apps and direct edits show just the name. One exception: a GitHub status move for a pull request whose author is not a workspace member (or has not connected their GitHub name) is made by the system and shows as "GitHub" alone.
Changes Tyn holds for you. After Tyn reads text that someone else wrote (a doc, an item or a comment written or last changed by another person, or imported content), risky changes (deletions, moves, sharing, invites, workspace-wide definitions, and changes to items you did not name or have open) wait until you press Apply. After Tyn uses the web, every change waits for Apply. The held changes are kept on our servers in memory only, for up to 10 minutes, and only the person who asked can apply them. The Apply card in the saved chat keeps a one-line label and the state (open, applied, discarded or expired) for each change. The new text of a change is shown only in the open browser tab and is not saved in the chat.
When you use Tyn, we send the AI model provider your message, the conversation so far, instructions from termynl, and the content Tyn reads with your permissions to answer. Each tool result sent back to the model is size-limited.
termynl's accounts first, then your own key. AI runs use termynl's own provider accounts (Anthropic Claude and Google Gemini models) while a person's included usage lasts; after that, a workspace's own provider key is used, under the workspace's agreement with that provider. For runs on termynl's accounts, Anthropic and Google are our sub-processors.
Always your own keys. A workspace can choose to always use its own provider keys; its agreement with the provider then applies to every run, and termynl's provider accounts are not used.
Models on your own key only. Some Anthropic models and all OpenAI models run only on an API key the workspace admin adds for the organization's own provider account. That data is sent under the organization's own agreement with that provider, and those runs are not metered by termynl.
Trial. A trial runs only the basic model of each provider, with no voice, image or video.
Voice, dictation, read aloud and recorded notes are processed by Google's Gemini API on termynl's account (or on the workspace's own Google key, when it uses one), under Google's paid API terms (section 3.12). For runs on termynl's account Google is our sub-processor; for runs on the workspace's own key, Google processes under the workspace's own agreement, as section 7.2 describes. The text of a transcript or note is treated as data to summarize, never as instructions. AI-written notes can be wrong or incomplete.
Under the provider's API terms, Anthropic and OpenAI state that they do not use API inputs and outputs to train their models by default, and Google states that it does not use prompts and responses on the paid Gemini API to improve its products. Providers may keep them for a limited time for purposes such as abuse monitoring. The provider's terms govern that processing.
Web access (off unless an admin turns it on). When a workspace admin turns on Let Tyn use the web and a person keeps it on for themselves, Tyn can search the web and read pages. It is not available in a trial or to guests.
- Tyn's search queries and the addresses of the pages it reads are sent to the AI provider running the model (Anthropic or Google), which runs the search or reads the page on its own systems. Search queries are written by the model from the conversation and can contain personal data or other workspace content you asked about. Text from the pages and search results then enters the conversation, as data, never as instructions.
- termynl's servers do not visit the pages. A site Tyn reads may log the visit, but it sees the AI provider's or Firecrawl's network address, not yours.
- Tyn opens only an address you typed, one a search returned in the same answer, or one you confirm. If you turn on Let Tyn open pages without asking (when your admin allows it), Tyn also opens an address that appears, exactly and in full, in text it read for that answer.
- Google-grounded answers. When a Gemini model answers with Google Search, Google provides search suggestions that we must show with the answer. We show them, as Google provides them, in a sandboxed frame below the answer's sources, only to the person who asked, and we never store them. A saved chat keeps only the answer text and the source links of such an answer, and the answer text is removed after two years (the question and the links stay). Exports and backups the customer has already made, including backups to its own storage, keep what they copied and are outside this automatic removal. Google keeps grounding prompts and responses for a limited time under its terms (30 days at the time of writing).
- Firecrawl, with the workspace's own key. An admin can add the organization's own Firecrawl API key. Tyn then uses Firecrawl to search (for models with no search of their own), to read pages, to save a page as a doc and, if the admin allows it, to crawl up to 10 pages of a site. Queries, page addresses and the page content Firecrawl returns pass through our servers to and from Firecrawl under the workspace's own agreement with Firecrawl. Firecrawl is the customer's own service (section 7.2), not our sub-processor. termynl never provides, pays for or bills Firecrawl.
- Each search, page read, crawl, refusal, confirmation and Apply is recorded in the workspace audit log with the query (shortened) or the full page address, never page or answer text.
Connected apps (MCP). Any MCP client, such as Claude Code, can connect over OAuth 2.1 after you approve it on a consent screen. It then acts as you, within the scopes you granted (termynl:read, termynl:write, termynl:admin). Its changes show in activity as "via" the app, and apps that registered themselves are marked "unverified app". Authorization events are recorded in the audit log. You can revoke an app at any time in Account → Connected apps. Data the app reads is then handled by that app and its provider under your own terms with them.
External agents. A workspace admin can register an external agent endpoint. Messages sent to it go to the address the admin chose.

7. Who we share data with

7.1 Sub-processors

Sub-processor	Purpose	Data
Cloudflare	DNS, CDN, secure tunnel and edge proxy in front of all termynl sites and the API; email-address obfuscation on the docs site	All traffic to and from our sites and API, including IP addresses and request data
Stripe	Payment processing and subscription billing	Billing contact, payment details (collected by Stripe directly), subscription and seat data
Anthropic	AI models run on termynl's account, including web search and reading web pages for Tyn	Prompts and the context Tyn reads, as described in section 6; search queries and page addresses
Google (Gemini API, Google LLC)	AI models run on termynl's account, including voice, dictation, read aloud and recorded notes, and web search (Grounding with Google Search) and reading web pages for Tyn (not runs on a workspace's own Google key)	Prompts and the context Tyn reads, as described in section 6; for voice features, the audio you speak or record and the text to be read aloud (section 3.12); search queries and page addresses
Google Cloud Pub/Sub (Google LLC)	Delivering Google Meet's event notices (a meeting's notes, transcript or recording is ready, someone joined a call started from termynl) to termynl	Google resource names and event types only, never meeting content
Resend	Delivery of service and notification email	Recipient address and the content of each message (for example sign-in links, and item keys and titles in notifications)
SMTP2GO	Fallback delivery of service email (our previous email provider)	Recipient address and message content
Hosting	Our hosting infrastructure in the United States, operated by us	All service data

We will update this list before we add or replace a sub-processor.

7.2 Services the customer chooses

These act on the customer's own account and under the customer's own terms, not as our sub-processors: Google and Microsoft (sign-in, file storage, group checks, and Drive browsing, linking and sharing on each person's own account), GitHub (sign-in), the customer's own identity provider for single sign-on (SAML or OpenID Connect), Notion (Connect Notion, with each person's own Notion account), Zoom (meetings and calls a member connects with their own Zoom account), Google Meet and Google Docs (meetings and notes a member connects with their own Google account), GitHub (code hosting), connected by the workspace's admin, the customer's S3-compatible storage provider, Anthropic, Google or OpenAI when used with the customer's own API key, MCP clients a user connects, external agent endpoints an admin registers, Firecrawl (web scraping and crawling, with the workspace's own Firecrawl API key), and the audit log streaming destinations an admin configures (the customer's own log system or the service it chooses, such as a SIEM).

7.3 Other disclosures

Within your workspace: owners and admins can see members' names, emails, roles and status. Members see content in the teams and projects they can access.
Legal requirements: we may disclose data when the law requires it, or to protect the rights, property or safety of our users, the public or us. Where the law allows, we will tell the customer first.
Business transfers: if termynl is sold, merged or reorganized, data may transfer to the successor, which remains bound by this policy's commitments for data collected under it.

8. International transfers

We are based in the United States and host the service in the United States. If you are in the EU, EEA, UK or Switzerland, your data is transferred to the United States. Where required, we rely on appropriate safeguards for these transfers: the European Commission's Standard Contractual Clauses (with the UK Addendum for UK data), or a recipient's certification under the EU-U.S. Data Privacy Framework and its UK and Swiss extensions.

9. How long we keep data

Customer Content is kept for as long as the workspace exists, including the change history of deleted items. Workspace owners and admins can export it (JSON and files) in the app at any time while the subscription is active and for 30 days after it ends; an owner exports the whole workspace, and an admin who is not an owner exports only the spaces they can read. Members' personal items are left out of an export unless a workspace owner chooses to include them. Only the person who started an export can download it, and each export is deleted after 7 days. An owner can delete the workspace in the app: everything in it, including the files termynl stores, is deleted automatically 30 days after the request (any owner can cancel until then); the subscription won't renew and ends when the workspace is deleted. A cancelled workspace is deleted automatically 60 days after its subscription ends; its owners and admins are emailed when it ends and on days 30, 45 and 59, and starting a paid subscription again before then cancels the deletion. A deletion can be paused while a legal obligation requires us to keep the data (a legal hold). Files in the customer's own Google Drive, OneDrive or S3 storage stay there.
Recordings. Audio of a recording is deleted on our servers once the notes are written; if Google could not be reached it is kept while the notes are retried, for up to 7 days (or the Keep recordings period if longer), then deleted. With Keep recordings on, kept audio is deleted after the period the workspace admin chose (7, 30 or 90 days) by termynl from the workspace's storage; a legal or data hold pauses deletion. Audio from a spoken conversation and from dictation is not saved. Deleting an account or a workspace also deletes that person's or workspace's recordings on our servers.
Web access. The Firecrawl key is kept encrypted until an admin removes it (then it is wiped, not kept) or the workspace is deleted; it is never included in an export. Changes Tyn holds for Apply, and the list of addresses Tyn may open in an answer, live in memory only (at most 10 minutes) and are never written to disk. In a saved chat, the answer text of a Google-grounded answer is replaced after two years with "This answer used Google Search and was removed after two years." (the question and source links stay), in the chat and in its edit history, and an older copy of the chat saved again later is removed the same way; a legal or data hold pauses this. Each removal is recorded in the audit log. Workspace exports and backups the customer already made (including backups to its own storage) are outside this automatic removal. Audit entries about web access follow the audit log retention.
Your account. You can ask to delete your account in Settings → Profile (or through the request_account_deletion MCP tool):
1. We email a confirmation link to your primary address. The link is valid for 24 hours and works once.
2. When you confirm, the deletion is scheduled for 30 days later. Your connected apps are revoked and your other sessions are signed out. You can cancel at any time during those 30 days.
3. After the 30 days, your account's personal data is deleted automatically: sign-in methods, identity records, profile and profile picture, preferences, connected-app grants and provider connections. Your other sessions and connected apps are signed out when you confirm; the remaining session records are deleted within 30 days after the purge. Your work items are kept by each workspace: your personal items (the private space only you could see), the items assigned to you and the items you created are handed to a member a workspace admin picks (by default the workspace owner), who can then see your personal items; if nobody else is in the workspace, your personal items are deleted. Mail, calendar events and contacts synced through your account, and everything attached to them (including shared mailboxes), are deleted, never handed over. Stored attachment files are removed in a later clean-up. Files you stored in your own Google Drive or OneDrive stop opening in termynl. What else stays: content you created in shared spaces (it belongs to the workspace), the history of who did what (it is not rewritten), audit entries about your account (without your email address), and your address in our email delivery log for up to 90 days. A deletion can be paused while a legal obligation requires us to keep the data (a legal hold); it cannot be cancelled while on hold.
If you are the only owner of a workspace that has other members, you must transfer ownership first. Content you created in a workspace's shared spaces belongs to that workspace and stays there, under the customer's control.
Single sign-on records: the connection settings stay until an admin removes SSO or the workspace is deleted; your SSO link stays until an admin resets it, the workspace sets SSO up again or changes its identity provider (issuer, entity id or client id: every link is deleted then), or your account is deleted (if the workspace removes SSO, the link stays but cannot be used to sign in). Sign-in requests (up to 10 minutes), hand-off records (up to 2 minutes) and the assertion-id memory are deleted when they expire; the rate-limit memory for audit entries after an hour. Audit entries follow the workspace's audit log retention. Records of a 7-day grace period for a person are kept so it does not restart.
Two-factor records: your passkeys, authenticator secret and backup codes are kept until you remove them, an admin resets your two-factor authentication, or your account is deleted. A trusted device expires after the workspace's trust length (at most 90 days). Waiting two-factor sign-ins and setup steps expire after 10 minutes and are deleted periodically; counters of failed two-factor tries are deleted after a day.
Sessions: an access token lasts 15 minutes and a session can be renewed for up to 30 days. Session records (device and coarse IP prefix) are deleted automatically 30 days after the session ends or is signed out.
GitHub records: the pull request, branch, commit, check and key-count records termynl stores from a connected GitHub account are kept until an admin disconnects that account (or GitHub reports the app removed), until a repository stops being shared, or until the workspace is deleted. On a disconnect, termynl deletes the branches and commits, and every pull request no task or issue links to. A pull request that a task or issue links to stays on that item as history (its title, number, author and last known state), marked as no longer updating, until the item or the workspace is deleted. Webhook delivery ids are kept 30 days. A person's connected GitHub name is kept until their account is deleted. Work-start records (who started work on an item with Create branch or a connected app, with which tool, and when) are kept until the workspace is deleted; when a member's account is deleted, they no longer name that person. Audit entries are not deleted on a disconnect: the GitHub entries in the audit log (repository names, pull request numbers, GitHub usernames, never titles, descriptions or code) are kept like every audit entry, for as long as the workspace exists.
Audit log streaming: a destination's settings are deleted when an admin removes it or the workspace is deleted. Entries waiting for a destination are deleted once delivered, when the destination is removed, or, past 100,000 waiting (10,000 refused), oldest first. What a destination received is kept under the customer's own terms with that service.
Connected-app tokens: access tokens last 1 hour and refresh tokens 30 days, rotating, with a hard limit of 90 days per authorization. Expired tokens are deleted periodically once they have been expired for a day. The connected-app audit log and the membership audit log are kept for security and accountability for as long as the account or workspace exists.
Staged upload files: deleted when the job ends, fails or is cancelled; a job never run is cancelled and its files deleted after 7 days (section 3.10).
Notion connection: kept until you disconnect it in Settings > Import, or your account or the workspace is deleted.
Paused mail, calendar and contacts data: deleted on 2026-10-07 (section 3.6).
Logs: our policy is to keep operational and security logs (our servers, web server and database) for 90 days and then delete them. The email delivery log is kept 90 days.
Backups: we back up the database, including before each software deployment; our policy is to keep each backup for 1 year and then delete it. Deleted data may remain in a backup until that backup is deleted.
Billing records are kept as long as tax and accounting laws require.

10. Security

Traffic to our sites and API is encrypted in transit with TLS.
OAuth tokens, customer AI provider keys and storage credentials are encrypted at rest with AES-256-GCM.
Two-factor authentication: passkeys and security keys are stored as public keys only; authenticator app secrets are encrypted at rest with AES-256-GCM; backup codes and trusted-device tokens are stored only as one-way hashes. Sensitive actions (such as changing the workspace's two-factor policy or resetting someone's two-factor authentication) ask for a fresh two-factor check, and failed checks are limited to 5 per 15 minutes.
Single sign-on: the identity provider's signature on every sign-in is verified against the certificates in the workspace's saved metadata (only strong signature algorithms are accepted); each assertion can be used once; the client secret of an OpenID Connect connection is sealed with AES-256-GCM; the provider's identifier is stored in the link only as a one-way hash; sign-in routes are rate limited.
Session refresh tokens, sign-in links, invitations, ownership-transfer and deletion links, and connected-app tokens are stored only as SHA-256 hashes.
Workspace content is isolated by tenant with PostgreSQL row-level security, which is enforced even for the application's own database role.
Our internal staff tooling uses a separate database role that has no access to content, identity or token tables. It sees billing and membership metadata only, and every change it makes to a workspace's billing status is logged.
termynl does not offer staff access to customer workspaces for support. If we add it, it will require the customer's permission and be limited in time.
Access to the underlying infrastructure is limited to the operator. We access Customer Content only when needed to operate or secure the service, to comply with law, or at the customer's request.
Other measures include rate limiting, audit logs, file-type checks on uploads, and short-lived access tokens.

No system is perfectly secure. If a personal data breach occurs, we will notify affected customers without undue delay. Where we are the controller, we will notify the relevant supervisory authority within 72 hours where the GDPR or UK GDPR requires it, and notify affected individuals and regulators as required by applicable U.S. state breach-notification laws.

11. Your rights

11.1 EU, EEA and UK

You have the right to access, correct, delete or export your personal data, to restrict or object to its processing, and to withdraw consent where we rely on consent. You also have the right to lodge a complaint with your local data protection supervisory authority (in the UK, the Information Commissioner's Office).

If we are required to appoint a representative in the EU or the UK, we will name them here.

11.2 California and other U.S. states

Notice at collection (California). The categories of personal information we collect are those in section 3: identifiers (name, email, account ID, coarse IP prefix), customer records (billing status), internet or network activity (session and security logs), and professional information (work email, organization and role). Account sign-in data is the only sensitive personal information we collect, and we use it only to provide and secure the service. We collect this information from you, from your organization, and from the sign-in and identity providers you use. We use it for the purposes in section 5 and keep it for the periods in section 9.
We do not sell or share personal information (as those terms are defined in the CCPA/CPRA), and we do not use it for targeted advertising. There is nothing to opt out of, and we treat Global Privacy Control signals consistently with that.
California residents have the right to know, access, correct and delete their personal information, and not to be discriminated against for exercising these rights.
Residents of other states with consumer privacy laws, such as Virginia, Colorado, Connecticut, Utah, Texas, Oregon, and Maryland (the Maryland Online Data Privacy Act, effective October 1, 2025), have similar rights under those laws, including to appeal our decision on a request. To appeal, reply to our decision and ask us to reconsider. Where these laws exempt information processed in a business-to-business context, we still honor reasonable requests.

11.3 How to make a request

Email hello@termynl.com. We will verify your identity, usually by confirming control of your account's email address, and respond within the time the applicable law requires (one month under the GDPR, 45 days under most U.S. state laws). You may use an authorized agent where the law allows. If your request concerns Customer Content in an organization's workspace, we will refer it to that organization and support its response.

12. Children

termynl is a business service and is not directed to children. It must not be used by anyone under 16. We do not knowingly collect personal data from children under 13 in the United States or under 16 in the EU, EEA or UK. If we learn that we have, we will delete it.

13. Data processing agreement

Business customers that need a data processing agreement for their use of termynl can request one at hello@termynl.com.

14. Changes to this policy

We will post any change on this page and update the "Last updated" date. For material changes, we will notify workspace owners by email or in the app before the change takes effect.

15. Contact

HODY, operator of termynl, Maryland, USA · hello@termynl.com