Privacy Policy

In short

Audio is captured only in live mode, only during a meeting you started. With live mode off, which is how it arrives, Troctor asks macOS for no privacy permission and there is no audio anywhere in the app. Switching it on asks for the system audio permission and nothing else: no microphone permission is ever requested, and no recording indicator appears, because capturing what your speakers play is not something macOS marks with the orange dot. Nothing tells the other people in the meeting that transcription is running. That is your job, not the operating system's.

Transcription happens at Soniox, on our account. There is no speech-to-text on your Mac and none on our servers. In live mode the audio goes from your Mac to Soniox and comes back as text, over a socket your Mac holds directly, using a temporary key our backend minted for that meeting. You need no account with them. Troctor also still works from transcripts you already have, exported from the tools that produced them, and that path involves no audio and no vendor at all.

Your screen is captured only when you press Capture, and only the box you draw. Until 16 September 2026 this said the screen was never captured, and it was true. Since then, a meeting's Context dialog has a Capture button: it opens the Mac's own crosshair, and what you draw a box around is attached to that meeting so an answer can read what somebody is sharing. Troctor asks macOS for the Screen Recording permission once, when it starts, with a request that takes a one-pixel thumbnail of each display and discards it at once; refuse it and nothing else changes, and the button says it is off. Nothing else in the app uses that permission: listening does not, there is no capture on a timer or in the background, and a static test holds that by name. A captured picture is stored on your own Mac beside the meeting, goes to the model only with a question you ask in that meeting, and is deleted with the meeting or from its Context tab.

Your vault never reaches us. It is a folder of Markdown files on a disk you chose. The search index is derived from those files and sits in Troctor's own folder in your user library, along with any recordings live mode has written. None of it is ever uploaded, and there is no upload step in the app to trust us about. What can reach us is narrower than that and narrower than it was: only what you attached to the meeting you are asking in, and what has been said in that meeting. Every other meeting on the disk stays where it is, and a question is not matched against them at all.

When you ask a question, your question and that meeting's own material go to our backend, which forwards them to a model vendor on our account. That is the only route there is. Which vendor depends on the model you picked, and the choice of vendor is ours rather than yours.

What we do hold is the paperwork of running a private beta: the form you filled in to ask for a key, your licence and the Macs it is activated on, one line each time you download the build, a closed list of counts and timings from the app, one report after each meeting of how the assistant behaved in it, with no words in it unless you choose to share them, and a count of the answers and the transcription minutes we paid for.

Who we are

Troctor is a product of Globyskytek LLC ("we", "us"), a limited liability company registered in North Carolina, United States. For the purposes of data protection law, Globyskytek LLC is the controller of the personal data described here.

Our registered address is Globyskytek LLC, #2150, 207 W Millbrook Road, Suite 210, Raleigh, NC 27609, United States. You can reach us at privacy@troctor.com.

What never leaves your Mac

Importing, indexing, searching and reading citations all work with the network switched off entirely. Two things need a connection: generating an answer, because every model runs on our keys behind our backend, and live mode, because transcription happens at a vendor.

What leaves when Troctor listens

This section covers live mode only. If you never switch it on, none of it applies to you and nothing in it happens.

One thing about its maturity, stated here rather than left to the roadmap, because it belongs next to the disclosure rather than away from it: live mode is in daily beta use and still changes quickly: the live path is reshaped most weeks in response to what real meetings surface. That is not a reason to read the rest of this section as hypothetical, since the code is in the build you installed and the moment you switch it on the audio described below is what leaves. It is a reason not to depend on it yet.

What is captured, and what macOS asks you first

Two channels, chosen by you, each with its own macOS permission. Nothing is requested at install or at launch; a permission is asked for the first time you start a meeting with that channel switched on.

Who said what comes from the vendor's speaker diarisation, which labels voices Speaker 1, Speaker 2 and so on within that meeting. The labels are per meeting and carry no identity: nothing ties Speaker 2 today to any person or to Speaker 2 tomorrow. An earlier design captured your microphone as a second connection and used the channel itself to tell you apart from the room; that option is gone, and one connection per meeting is also half the transcription cost.

What goes to the transcription vendor

The vendor is Soniox. While a meeting is running, Troctor opens one connection per channel and sends:

• The audio itself, as raw 16 kHz mono samples in tenth-of-a-second frames. Unedited and unfiltered: everything the channel heard for as long as the meeting ran.
• A temporary key, the model name, the audio format, and the languages you said to expect.
• A list of terms you typed, if you typed one. Product names, people, acronyms, to help it spell them.

Nothing else. No vault content, no file names, no account of yours with us, and no identifier of ours. The transcript comes back over the same connection and is written into that meeting, which is to say into your vault, on your disk, and into the recording described above.

The key is ours, and it is temporary. Your Mac asks our backend for one when a meeting starts, our backend exchanges our real Soniox key for one that expires in sixty seconds and can do nothing but open a stream, and your Mac then holds the socket itself. The audio does not pass through our servers at any point, and it is worth saying why that is the design rather than an accident: relaying it would put every word of every meeting through a process we own, and add a hop to a delay measured in tens of milliseconds. What crosses our side is a request for a key and, while the meeting runs, a count of seconds. Never a word of it.

This does change one thing that used to be said here. Soniox was previously a company you had an account with; it is now a vendor of ours, on our key and our bill, so it is named under who we share with rather than kept off that list. What Soniox retains from a stream is governed by their own terms.

What goes to a model, and when

Live mode occasionally puts a suggestion on screen, which means one model call. It is rarer than a sentence: a line has to look like a question, a claim, a figure or a date; a rate limit has to be clear; retrieval has to find something in your vault; and the model has to decide there is anything worth interrupting you for, which it is instructed to say no to by default.

When one is made it carries the last six lines of the live transcript, the line that set it off, up to four passages from your vault and up to two excerpts from what you attached to the meeting. Never audio. The model never receives audio at any point in this product.

It travels exactly as a question you typed does: through our backend, to the vendor behind the model selected for that meeting, and it spends credits from the day's allowance, so a live meeting can consume part of that allowance without you typing anything. The model can be set for the meeting alone, and the assistant can be turned off entirely, in which case no model call is made for any reason.

The window it draws on

Suggestions appear in a small always-on-top window over your call. It is a window like any other, so sharing your whole screen shares it. It used to be built with setContentProtection applied, which asks macOS to exclude a window from screen recording and from screen sharing, and that stopped working on macOS 15: every window is flattened into one image before capture now, and ScreenCaptureKit, which is what Zoom, Teams, Meet and QuickTime use, reads that image. We removed the feature on 9 September 2026 rather than keep a setting that worked on some Macs and quietly did nothing on the rest. What keeps the panel out of the picture, on every version of macOS, is sharing the single window you are presenting rather than your whole display, because macOS captures a chosen window on its own and leaves out anything drawn over it. A second display works too. The security page is where we set out why we will not sell any of this as a way of being undetectable. The window also never takes the keyboard unless you press the shortcut that opens its ask box.

What is kept, and by whom

One further trace, and it is a count rather than content. If Troctor crashes with a transcription connection still open, it writes a small file so the next launch can notice, because a connection nobody closed keeps costing until the vendor's own limit. When that happens the app reports two numbers to us if usage reporting is on: how many channels were open and roughly how many minutes ago it started. Never which meeting, never a word of what was said.

What leaves after a meeting

When a meeting ends, the app sends us one report of how the assistant behaved in it, if usage reporting is on. It exists because we cannot sit in your meetings, and a meeting is the only place the assistant's judgement can be seen: whether it answered when it should have, stayed quiet when it should have, and how long it took. Counts of answers cannot show that; the order of events can. It is the same switch that governs the events above, described on the activation screen and in Settings under Send anonymous usage counts, and turning that off discards any report not yet sent.

The report is a closed list, applied in the app when it is written and again on our server when it arrives, so a modified copy of the app cannot send more than an unmodified one. In full, it holds: an identifier for the meeting, when it started and ended and why it ended; which channels were listened to (the speakers, the microphone, or both); which assist mode and which of our model ids was in use; totals of turns, distinct voices, answers, quiet moments, failed answers, streams, reconnects, rotations, dropouts and billed minutes. Then, for every finalised turn of the transcript: its number, its second within the meeting, its channel, the meeting's own speaker number (never the vendor's label, never a name), and how many characters it was. For every decision the assistant made: which turn it was made on, its second, whether it answered or stayed quiet, the reason it stayed quiet as one of twelve fixed codes, whether you asked the question yourself, the model, how many milliseconds the answer took, how many turns were in its window, the lengths of the question and the answer in characters, how large the request was in bytes and how many pictures were attached to it (never the pictures), a short error code if it failed, and whether it was stopped. And what the listening itself did: how long each of the three waits inside pressing Listen took (opening the audio, setting up transcription, connecting), each stream starting and how long that took in total, and when each stream closed: how it ended (our own word, or the transcription service's error code and its request id), how far the service had fallen behind the audio at worst, how much audio was waiting to be sent at worst, how much of the audio was above a loudness floor, and how many tokens came back; being replaced by a fresh one (how long the replacement listened beside it first, how many voices were matched across the seam, and whether a voice afterwards had to be guessed), reconnecting and how many attempts, dropping out and recovering, the chosen voices changing or being carried, going idle, stopping; and on each turn, which of the meeting's streams heard it. Times, counts, codes and lengths. Not a word of what was said, and not the request sent to the model.

A second switch, off until you turn it on, adds the words. It sits under the first in Settings and reads Also share my meeting transcripts and the assistant's answers with Troctor. With it on, the same report also carries the text of every turn, the question the assistant considered at each decision and the answer it gave, each cut at four thousand characters, and a report too large to store drops the words and says so rather than dropping the meeting. We ask for this because the shape of a meeting shows that the assistant answered at the wrong moment and only the words show why. Other people in your meetings are in that text, which is why the switch is separate, off, and worded as it is. A report that carries words while claiming the switch was off is refused whole on arrival.

Either kind is kept for 90 days and then expires automatically, with the expiry written onto the document as it is stored. Only an admin account can read one, through a list that shows summaries with no words in them whatever a report holds, and a view of one meeting at a time. Nothing in a report can be read by any client, including the app that sent it.

What leaves when you ask

One request, made only when you press ask. What is in it is the same whichever model you chose:

• Your question, as you typed it.
• What you attached to that meeting, and what has been said in it. Nothing is read from the rest of your vault while answering; that path is built and switched off for the beta. Each excerpt carries the file or the speaker, the date and the timestamp it came from, so the answer can cite it.
• Whatever you attached to that meeting: files you dragged in, text you pasted, and the transcript of the meeting the thread was started from, if it was started from one.
• The standing instructions you wrote for that meeting, if you wrote any.
• Up to eight earlier messages from the same meeting, so a follow-up makes sense on its own.

Nothing else, and nothing at any other time. The rest of your vault is not sent, and meetings that did not match are not sent. One correction to a sentence this page used to carry: the name of a file you attach is sent, because the model has to be told what it is reading. The path it came from is not. Before anything goes anywhere, the composer shows you the size of the request as a percentage of the model's context window, itemised by part, so this is a list you can check rather than one you have to trust.

An earlier version of this page said that a weak question sent nothing at all, because retrieval was scored against a floor and below it the model was never called. That gate was removed in v0.1. The model is now called every time you ask, so every question you type is sent, whether or not Troctor found much to answer it with.

Where the request goes, whichever model you picked

The request is posted to https://www.troctor.com/api/v1/chat, which is our own backend. It carries the model id you selected and nothing about a vendor, because the app does not know which vendor answers. Our backend checks that your licence is still good, spends the model's cost from the day's allowance, and forwards the same messages to that vendor over the OpenAI-compatible chat protocol using our API key. The answer streams back through us to your Mac.

Stated once and plainly, because it deserves better than being distributed across a page: on the free tier your question and the excerpts from your meetings transit a server we operate. The free tier is now the only tier, so that sentence covers every question you ask. They exist in that server's memory for as long as the answer takes, and they are not written to our database.

What is written, once per answer, is a single usage record holding the vendor model name, the input and output token counts, whether those counts were measured or estimated, how many milliseconds it took, and whether it failed. That is the whole record. Not the question, not the answer, not an excerpt, not a fragment of one, not a hash of any of it. The same token counts are added to a per-licence daily total, which is what enforces the allowance. Both writes are in functions/src/chat.ts, which is worth reading rather than believing.

One exception, which we would rather name than have someone find. When the vendor refuses a request outright, our server writes the first 300 characters of the vendor's error body to its operational log, because without that an outage cannot be diagnosed. Some vendors quote part of the request back inside that body. Those entries go to our Cloud Logging rather than to any database of ours and are never shown to you or to anyone outside the project, but it is the one path on which a fragment of a question could land in a log line, and it is cheaper to say so here.

Which vendor sits behind a model, and what that vendor calls it, are deployment parameters on our side rather than anything fixed in the app, because vendors rename and retire models on their own schedule and an installed build cannot be redeployed. The models offered during the beta are Groq Turbo and Groq Instant on Groq, GPT (fast) on OpenAI, Grok 4.6 on xAI and Claude Haiku on Anthropic. Rows for Google and a second OpenAI model exist in the same table and are switched off. The app fetches that list from us, so it can change without a new build, and this page names the current vendors rather than permanent ones. We will update it when they change.

The daily allowance

2,000 credits per licence per day, during the beta. An answer costs one credit on the free model, two on GPT (fast), four on Claude Haiku and six on Grok 4.6, so a day is 2,000 answers or 333 depending on what you pick. It is counted per licence rather than per device, so three Macs on one key share one allowance, and it resets at midnight UTC. When it runs out the next question is refused before anything is sent anywhere, with a message saying when the allowance comes back and whether a cheaper model can still afford it. Credits are spent at the moment a request is accepted rather than when it succeeds, and they are not returned if the vendor then fails. There is nothing you can add to raise the limit, because there is no key to add.

What used to be different

Until recently you could pick Claude, GPT, Gemini, Groq or a local model in Settings, paste your own key, and have the request go from your Mac straight to that provider with nothing of ours in the path. That option is gone. The key storage, the vendor clients and the settings screen that held them were all deleted, so there is no configuration in which a question avoids our backend. What you get in exchange is that there is no vendor account to open, nothing to paste, and no key of yours on disk to leak. We think that is the better trade for a pilot, and it is a real trade rather than a free improvement, which is why it is written here rather than left for you to notice.

Troctor Next, in the browser

Everything above describes the Mac app, whose promise is that your meetings stay on your machine. Troctor Next is a separate product at troctor.com/next, and its promise is close to the opposite, because its point is the opposite: you record a conversation in the browser in order to share it, as a live link, or with named people, and a conversation you can open from any browser is a conversation stored on our servers. The two products share your account and licence and nothing else; nothing here changes what the Mac app does. If you never open Troctor Next, nothing in this section happens.

What is captured

Your microphone, the one thing the Mac app never captures is the first thing Next asks for, through the browser's ordinary permission prompt, only after you press Record. System audio is not captured in the browser, and neither is your screen. The audio streams from your browser directly to Soniox on the same sixty-second minted keys the Mac app uses, so on its way to transcription it does not pass through our servers. What comes back, the finalised text, is published to our database as it is spoken, because appearing live on the page you shared is the product.

Following along, on a shared page

A shared conversation offers Follow along: press it, read the transcript out loud, and the page highlights the word you are on. It needs no account, because the link you were sent is what grants it, and while it runs your microphone streams to Soniox on the same short-lived minted keys everything else here uses. The difference from recording is what happens to the words: nothing is stored anywhere. Your voice is not saved, not added to the transcript, not shown to the person who shared it with you, and not visible to us; the recognised words exist for the instant it takes to move a highlight in your own browser and are then gone. Nothing starts until you press the button and grant the microphone, it stops when you press Escape or close the page, and it stops itself after a few minutes of silence.

What we store, per conversation

Summaries travel like questions do. When a summary is written, the transcript goes through our backend to a model vendor on our keys, exactly as a question from the Mac app does: relayed, not stored, with a usage record and nothing of the words. The transcript itself was already stored, because storing it is what Next is.

Deletion is real. Delete forever, in the app, removes the conversation for everyone: the transcript, the summary, the search copy, and the recording from our storage. Bin first, so a slip is recoverable; purge on delete.

AI Chat reads your own conversations, the ones you recorded or imported, and nothing else unless you say so. Settings has a switch, "Conversations shared with me", off unless you turn it on, that lets it also read what other people shared with you. What it reads travels the way a summary does: through our backend to a model vendor on our keys, relayed and not stored there.

Your conversations are not used to train models, and are not used to improve Troctor unless you say so. Settings has a switch, "Help improve Troctor", off unless you turn it on. With it on, a conversation you record from then on may be read by Troctor's own people, the recording and its transcript, to measure and improve how accurately Troctor transcribes, and for nothing else: never to train a model, never shared, never sent anywhere it would not have gone anyway. It is stamped on each conversation at the moment it is recorded, so turning it off later stops it for new conversations and does not reach back, and turning it on later does not open old ones. The default is off and stays off for anybody who never touches it.

Integrations, when you connect them

Next can deliver a finished conversation to services of yours, Slack, Notion, a webhook endpoint you name, and Google Drive; it can read a calendar you connect, Google or Microsoft Outlook, to show what is coming up; and it can import recordings you choose from your own Zoom cloud recordings or from a dedicated Dropbox folder. The calendars are covered in their own sections, and Zoom and Dropbox in their own, because reading your accounts deserves more than a bullet. All of it is off until you connect a service, and nothing is delivered automatically until you switch auto-send on, per service.

• What we store: the credential you provided, a Slack webhook URL, a Notion token and page, your endpoint's URL, or the Google or Microsoft credential described below, on our servers. It is never shown back to any browser, ours included, and it is deleted when you disconnect.
• What a delivery carries: the conversation's title, date, duration, owner name and summary, plus its link only when the link is switched on. Google Drive deliveries also carry the transcript and the recording, as files, because Drive is where files go. The webhook payload never includes the transcript.
• Whose hands it lands in: the service you connected, under that service's own terms. A delivery is you disclosing your conversation to a place you chose; we are the courier, not a new custodian.

Troctor Voice, the phone receptionist

Troctor Voice answers a venue's inbound phone line, holds the conversation, books tables and, where the venue has switched it on, takes orders for pickup or delivery. It is in a closed beta with a small number of restaurants. If you are a caller who rang one of those venues, this section is about your call. If you run one of those venues, it is about your workspace too, and the Voice data terms are the contract underneath it: they say that your callers' details are yours rather than ours, name every company that touches them, and set out what happens to all of it when you leave.

The audio path is different from every other Troctor product, and we say so plainly. The Mac app streams meeting audio from your own machine to a transcription vendor without touching our servers. A phone call has no Mac to start from. When you ring a venue that uses Voice, your call reaches us over the phone network (carried by Telnyx), the audio is handled in real time by call infrastructure we operate (built on LiveKit), speech is turned into text by Soniox or Deepgram (whichever engine the workspace runs), the reply is composed by a model at OpenAI (or at Google, where a workspace is set to run one of theirs) and spoken by Cartesia. The audio passes through infrastructure we run. It is processed live and it is not kept: we do not record calls, and there is no recording setting to switch on in this beta.

Callers are told at the start. The very first thing the agent says on every call identifies it as an AI assistant, says the call is transcribed, and offers a way out: say "no recording" and the agent takes a message with nothing kept. That announcement is ours, and it is the same at every venue. It is one sentence held in the system, spoken word for word whoever you rang: there is no field in a venue's console that could reword it, no switch that could turn it off, and no setting we intend to add. A venue cannot soften it, shorten it, move it later in the call or opt out of it, and that is the design rather than an oversight, because it is the sentence that makes the rest of the call fair to you. We keep a technical receipt for every call proving the announcement finished before transcription began.

Some callers are asked one more thing. Several US states, California, Florida, Illinois, Maryland, Massachusetts, Pennsylvania and Washington, require everyone on a call to agree before it is recorded or transcribed rather than just one person. We are in North Carolina, which does not, and a venue's own agreement does not cover a caller in a state that does. So when the number you are calling from carries an area code belonging to one of those states, the agent asks you one question after the announcement and before anything is written down: is it alright to keep a transcript of this call. If you say no, nothing you say is stored. The agent takes your message the way a person at the counter would, passes it to the venue, and no transcript of that call exists afterwards, on our side or theirs. You can still book, still order, still be rung back.

An area code is not a location, and we know it. A Chicago number rings from Denver, people keep the number they had at nineteen, and a mobile says nothing about where its owner is standing. So the rule is deliberately over-inclusive: it asks more callers than it strictly has to, because the alternative is guessing where you are from your phone number, which is both less accurate and more intrusive than simply asking. This is the newest part of Voice and it is going in during the closed beta, which makes it the one paragraph of this section describing something we are adding rather than something that has run since the first call. Responsible Use names the same states for the Mac app, and the reasoning is the same in both places.

What we store from a call: the transcript, a short summary and outcome produced by a model, the caller ID as the phone network delivered it (shown to the venue the way any office phone shows it), any booking made (name, phone number, party size, date and time, and any note you asked to pass to the kitchen), and the consent receipt described above, which holds a salted one-way hash of the caller's number rather than the number itself. What we deliberately do not build: caller profiles across calls, voiceprints, or any analysis of how a caller sounds. If you say a card number aloud the agent will not ask for one and does not want one; payment happens at the venue.

Orders, and the texts about them. An order you place by phone (the items, your name, the phone number you gave, and a delivery address if there is one) is stored in that venue's workspace the way a booking is, so the kitchen can make it. If you gave a phone number, Troctor may text that number from a Troctor number about that order and nothing else: the order number when the order is placed, a word when it is ready, and a word if the kitchen moves the time, changes the order or has to cancel it. The venue can switch these texts off. There is no marketing in them, they stop when the order is done, and every one of them names the venue and the venue's own phone number. Reply STOP to any of them to receive no more texts from Troctor, or HELP for the venue's number; message and data rates may apply. The phone numbers callers give are used for the call, the booking or the order they gave them for, and are never sold or shared with third parties for marketing or promotional purposes.

How long it stays: transcripts are deleted by an automatic job after 90 days. Bookings, orders and the messages taken for a venue belong to that venue's workspace and last as long as it does. Consent receipts are kept for four years and then deleted by a job of the same kind, because they exist to prove the announcement was played if anyone ever asks, and four years is roughly how long somebody has to ask. A receipt is deliberately not a record of who rang. It holds the times, which version of the announcement was spoken, what you said in reply, and a salted one-way hash of your number rather than the number itself, which means it can confirm that the caller on a particular call heard the disclosure and cannot be turned back into a list of phone numbers.

Getting a venue's data deleted, and the button that does not exist. There is no delete button in the venue console, and we would rather say so than have somebody hunt for one. What exists is us. A venue writes to privacy@troctor.com from an account on the workspace, and within 30 days we delete the workspace and what sits under it: the call records, any transcript still inside its ninety days, the bookings, the orders, the messages and the menu. Ask for a copy first if you want one, because afterwards there is nothing to copy. The one thing that may outlive the rest is the consent receipts, to the end of their four years, because they are the proof that those calls were disclosed and they hold no number that identifies anybody. And archiving is not deletion, which is worth saying plainly because the two sit near each other in our own console: archiving a venue stops the line being answered and hides the workspace from its staff, and everything under it stays exactly where it was until someone deletes it.

Model vendors do not get free rein. Call transcripts go to the model vendors named above only to produce the reply and the summary, on our keys, under the same terms as the rest of Troctor: we do not use your calls to train models, and we choose vendor settings that do not retain content for training where the vendor offers that control.

This is a beta. The honest consequence is that details here will change as we learn, and when they do this section changes with them, dated like every other change to this page.

Google user data: Calendar and Drive

Troctor Next can connect to Google Calendar and Google Drive with Google sign-in. This section is the complete account of that data. If you connect neither, none of it applies.

We request two permissions, each only when you connect its feature: calendar.events.readonly, a read-only view of your calendar events, and drive.file, which lets the app create files and see only the files it created, Google's own permission model makes the rest of your Drive invisible to us, which is why we chose that scope over a broader one.

Google user data is not sold, is not used for advertising, is not shared with anyone except as described above, and is never used to train AI or machine-learning models, calendar and Drive data does not reach a model at all: the model sees the conversation's transcript, which was recorded by you in Troctor Next, never anything read from Google.

Troctor's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

Microsoft user data: Outlook Calendar

Troctor Next can connect Outlook Calendar with Microsoft sign-in. It is the Microsoft twin of the Google Calendar connection above, and the same discipline applies word for word: if you never connect it, none of this happens.

We request three permissions from Microsoft: Calendars.Read, a read-only view of your calendar; User.Read, which tells us the address of the account you connected, shown on the integration's card, and used to leave you out of the attendee suggestions; and offline_access, which is what lets the connection persist between visits. Troctor never creates, edits or deletes an event.

Microsoft user data is not sold, is not used for advertising, is not shared with anyone, and is never used to train AI or machine-learning models, calendar data from Microsoft, like Google's, does not reach a model at all.

Zoom user data: cloud recordings

Troctor Next can connect your Zoom account to import your own cloud recordings as conversations. If you never connect Zoom, none of this happens. Troctor has no meeting bot: it never joins, records, or attends a Zoom meeting. It only fetches recordings that already exist in your Zoom cloud, and only the ones you individually choose.

We request two permissions from Zoom: user:read:user, which tells us the address of the account you connected, shown on the integration's card; and cloud_recording:read:list_user_recordings, a read-only view of your cloud recording list. Troctor never creates, edits or deletes anything in your Zoom account.

Zoom user data is not sold, is not used for advertising, is not shared with anyone except as described above, and is never used to train AI or machine-learning models. The AI summary sees the transcript of a recording you chose to import, never your recording list or anything else read from Zoom.

Dropbox user data: your Troctor folder

Troctor Next can connect your Dropbox to import recordings you place in one specific folder. If you never connect it, none of this happens. The connection uses Dropbox's App Folder access, which means Troctor can see exactly one folder, Dropbox/Apps/Troctor, and is technically incapable of reading anything else in your Dropbox.

We request three read-only permissions: account_info.read, which tells us the address of the account you connected, shown on the integration's card; files.metadata.read, the names, sizes and dates of files in the app folder; and files.content.read, the ability to download a file from that folder when you import it. Troctor never creates, edits or deletes anything in your Dropbox.

Dropbox user data is not sold, is not used for advertising, is not shared with anyone except as described above, and is never used to train AI or machine-learning models. The AI summary sees the transcript of a file you chose to import, never your folder listing or anything else read from Dropbox.

What we collect

When you ask for a beta key

The form on the download page writes one record: your email address, your name, what you do, your company if you give one, which meeting tools you already use, roughly how many meetings a week you have, the note you wrote about what you would want to ask, and where you arrived from (the query string on the link you followed, or the referring page, truncated). The record is stored under an identifier derived from your address, so submitting the form twice updates a timestamp rather than creating a second entry. Only your email address is required.

If you are let in and sign in

Sign-in is handled by Firebase Authentication. We store your email address, your name if your sign-in provider supplies one, your account status, and the licence attached to it.

The licence record holds the key itself, your email address, its status, its plan, how many machines it allows, when it was issued and when it expires, and how many activations it currently has. The only plan value that exists is beta. There is no payment processor, no card details, no invoice and no subscription tier, because the beta is free and there is nothing to bill.

Each Mac you activate

Activation exchanges your key for a per-device token, and creates one record per machine:

Each time you download the build

One row in an audit log: your account identifier, your email address, the licence, the version you downloaded and the time. Download links are signed and valid for ten minutes, and this log is what lets a leaked link be traced back to the account that requested it.

Usage reporting from the app

Counts, durations and short identifiers, on by default. The complete list is the next section, in full rather than in summary.

Each answer we serve, and each meeting you transcribe

Counters, all written by our backend rather than by the app: one usage record per answer holding the model name, token counts and timing, a running total of credits for the day against your licence so the allowance can be enforced, and, for live mode, the seconds of connection reported while a meeting runs plus a count of how many connections that licence has opened today. None of them has a field capable of holding anything you wrote or anything anybody said. The answer records are itemised in the next section.

Feedback you send from the dashboard

Your account identifier, your email address, the message you wrote, the kind of feedback you picked and your app version.

When you email us

Whatever you put in the email, kept so we can answer you and remember the conversation if you write again.

This website

No advertising cookies, no analytics tags and no third-party trackers on any page. Our host records standard server logs including IP address and user agent, retained briefly for security and abuse prevention. The waitlist form counts submissions per IP address to keep bots off it, in a short-lived rate-limit record.

Usage reporting in full

Every event carries the event name, your device UUID, your licence identifier, the app version and a timestamp. Beyond that, each event may carry only the properties named against it below. This is the entire list, and it is the same list that exists in the app's source.

The last four are new, and they are about Troctor rather than about you. Our server can only count requests that reached it, so a request that never arrived, a Listen that took twenty seconds to start, and a meeting that died halfway are all invisible from our side. They carry a duration, a count of channels, an HTTP status and our own refusal codes. None of them can carry what a meeting was about, who was in it, or what you asked.

Four names that this page used to list are gone from it. ask_gated measured the confidence gate, and when that gate was removed in v0.1 the event was taken out of the app and out of the server's allow-list in the same change. citation_opened, insight_shown and answer_rated were listed here while nothing in the build sent them, which overstated what is collected, so they are off the list until something actually emits them.

One further event is written by our own server rather than by the app, and it is the only one the switch in Settings does not govern. chat_served is recorded once per answer, and carries our model id and the vendor model string behind it, the credits it cost, the input and output token counts, whether those were measured or estimated, how long it took, and whether it failed. It exists because every answer is money out of our pocket and we need to know how much. No client can send it, and it is stored alongside the rest with the same 90-day expiry. There is no longer a way to opt out of it while still asking questions, because there is no longer a path to a model that does not go through us.

The list is closed, which is a stronger guarantee than filtering. A property not named above is dropped rather than inspected, so question, file, speaker, title, text, email, query and vault cannot reach us on any event, and a test fails the build if any of them is ever added. The same list exists again in the server that receives events and is applied a second time on arrival, so a modified copy of the app cannot send more than an unmodified one. The security page describes how that is enforced and tested.

Events are kept for 90 days and then expire automatically. Turning reporting off in Settings also discards anything queued and not yet sent, rather than letting one last batch go.

One thing the same switch governs is not an event. The report sent after each meeting is a single document with three lists in it rather than a name and a few numbers, so it has its own endpoint, its own closed schema applied on both sides, and its own row in the retention table. It is described in full above, under what leaves after a meeting, because that is where somebody deciding whether to leave the switch on would look.

Our sign-in and dashboard pages in a browser send one more thing, and it is smaller than everything above. When a page cannot reach us, or fails to run, it posts two words: which page it was (signin, action, dashboard or admin) and what happened (network, timeout, server, refused, expired, script or unsupported). No address, no identifier, no message, no page address, no error text. Both lists are closed on the page and again on our server, so nothing outside them can be sent even by a modified copy of the page, and what arrives is added to a counter rather than stored as a record, so there is nothing kept that could describe one visit. This exists because sign-in was once broken for days while every number we had said everything was fine: the failure was in the page, so our server was never called, and a server cannot count a request that never arrived.

What this data cannot tell us: what you asked, what was in any meeting, what your files are called, who you meet with, or what your vault contains. It can tell us that a question took eleven seconds, that an import of forty files produced thirty-eight meetings, and that answers are failing more often on one app version than another. That is what it is for.

How we use it

• To decide who to let into the beta, and to email you a key.
• To confirm a licence is valid and to hold it to three machines.
• To serve you the build and to know which account each download went to.
• To answer your emails and read your feedback.
• To find out where the app is slow, where imports fail, and what the answers and the transcription cost us to run.
• To keep the service from being abused, through rate limits and the hidden field on the waitlist form.
• To meet legal obligations.

We do not sell personal data. We do not share it with advertisers. We do not build advertising profiles. We do not train models on anything, and we have nothing from your meetings that we could train on.

Legal bases

If you are in the UK, EU or another region applying similar law:

On usage reporting specifically, because it is the one that deserves the argument rather than the label: our interest is knowing whether a beta product works before more people rely on it. The balance rests on what the data is. It is counts, durations and short fixed identifiers, tied to a device UUID and a licence rather than to anything you said, and it cannot contain a question, a file name, a person's name or a line of a transcript. You can object at any time by turning it off, the switch is shown at activation before the first event is sent, and turning it off discards what has not been sent.

We do not rely on consent anywhere in this policy, and there is no cookie banner on this site, because nothing here runs on consent.

Who we share with

Here is the list, and what each one receives. The first two are infrastructure providers, bound by contract to process data only on our instructions. The next two are the vendors that do the work a question or a meeting needs, under their own terms as well as ours. The last two exist only if you connect them:

What we do not share is anything from your vault, because we do not have it. The passages a question retrieves reach a model vendor by way of our backend and are not written down on either side of that hop by us. Everything else on your Mac, including any recording live mode wrote, stays there.

The current list of providers is available on request from privacy@troctor.com, and we will give notice before adding a new one. We may also disclose information where the law requires it, or to protect our rights, safety or property. If a valid legal request arrives, we will tell you unless we are prohibited from doing so.

How we protect it

Some of what this policy describes is sensitive by any reasonable definition: the words people said in a meeting, and the credentials you grant us for Google, Microsoft, Zoom and Dropbox. This section says what actually protects them, mechanism by mechanism, rather than asserting that we take security seriously.

How long we keep it

What you can do yourself

There is no single button in Troctor that erases everything, and we would rather say that plainly than let you go hunting for one. Here is what actually exists:

• Delete the vault. It is your own folder of your own files. Drag it to the bin like anything else. Nothing of ours has to agree, and nothing breaks elsewhere.
• Delete the app's folder. Troctor's folder under ~/Library/Application Support holds the search index, the device UUID, the stored licence, any queued usage events and any recordings live mode has written. Removing it removes all of them.
• Remove the licence from a Mac. Settings, then Licence, then "Remove from this Mac". Your vault and index stay exactly where they are. Note that this does not free the seat: releasing a machine so the seat can be reused is a separate action in your dashboard.
• Leave live mode off. It arrives off and stays off until you switch it on for a particular meeting. Revoking the microphone and system audio permissions in System Settings, under Privacy and Security, takes the capability away from the app entirely, whatever it is asked to do.
• Delete a recording, or never make one. Open the meeting, and each recording is listed with its size beside Show in Finder and Delete. The switch beside them stops the audio being written for future meetings, in which case only the transcript is saved.
• Decide what a meeting may spend. The assistant in a live meeting has three settings, and off means no model call is made for any reason, including a question you type into the panel. That is the control that stops a meeting reaching a model at all.
• Turn usage reporting off. Settings, then Usage reporting. Anything queued and unsent is discarded at the same time.

For anything we hold on our side, email privacy@troctor.com and we will do it.

Your rights

Depending on where you live, you may have the right to see the data we hold about you, correct it, delete it, receive a copy in a portable format, or object to certain processing. You also have the right to complain to your data protection authority.

If you're a California resident, you have rights under the CCPA and CPRA to know, delete, correct and opt out of sale or sharing. We don't sell or share personal information as those terms are defined, and we won't discriminate against you for exercising any right.

To make a request, email privacy@troctor.com. We'll reply within 30 days and may need to verify who you are first.

Worth knowing what such a request can and cannot reach. Most of what you would want deleted was never ours to hold: your meetings, your questions, the answers you got and any recording of a call all live on your own disk. Questions passed through our backend, but they were relayed rather than stored, so there is no copy of them for us to delete and none for us to produce. A request to us covers the waitlist entry, the account and licence, the activation records for your Macs, the download log, the usage events and the allowance counters. It cannot reach a recording on your Mac, which is yours to delete in the app. Troctor Next is the exception in the other direction: its conversations and recordings are on our servers precisely so they can be shared, so a deletion request, or the Delete button in the product, which is faster, really does reach them, transcript, summary, search copy and audio alike. Audio sent to Soniox during a meeting never passed through us, so there is nothing here to delete; what they hold is governed by their terms, and we will pass on a request if you send us one.

Troctor Voice is the part where your request has two addresses, and it is worth reading before you send it. If you rang a restaurant that uses Voice, what exists is the transcript of that call for its ninety days, a short summary of it, the number the phone network showed us, and whatever you gave the restaurant in order to do business with it: your name, a callback number, an order, a delivery address, a booking. That is the most sensitive material anywhere in this product, and almost none of it is ours to decide about. It belongs to the restaurant. They decide what is kept and what is deleted, and we hold it for them and act on what they tell us, which is the ordinary arrangement between a business and the software it runs its phone on. In the language the law uses, the restaurant is the controller and Troctor is the processor, and the whole of that arrangement is written out in the Voice data terms.

Either address works, and neither is a dead end. Ask the restaurant, and they can cancel a booking or an order themselves in their own console straight away, and tell us to erase what is left of the call. Ask us at privacy@troctor.com, name the venue and roughly when you rang, and we will tell you what is held for that call, put the request to the restaurant, and carry it out as soon as they instruct us, or straight away where the law puts the duty on us rather than on them. Two honesty notes on that. We will not quietly erase a restaurant's records because somebody emailed us claiming to be a caller, so expect to be asked to verify the number you rang from. And we will not let a request die in silence either: if a venue does not answer us, we will tell you that, and tell you who they are, so you can go at it from the other side. What no request can do is find you across venues, because there is nothing to search on. We build no caller profiles, keep no voiceprints, and the consent receipt holds a salted hash rather than your number, so a phone number is not a key that opens anything here.

International transfers

We're based in the United States and our providers may process data there or elsewhere. Where data moves out of the UK or EEA we rely on Standard Contractual Clauses or another approved safeguard.

Children

Troctor isn't intended for anyone under 16, and we don't knowingly collect their data. If you believe a child has given us information, write to us and we'll remove it.

Changes

If we make a material change we'll update the date at the top of this page and, for anything significant, email account holders before it takes effect. If we ever start collecting something new, it will appear in the lists above before it is collected, not after.

Contact

Questions about any of this go to privacy@troctor.com, or by post to Globyskytek LLC, #2150, 207 W Millbrook Road, Suite 210, Raleigh, NC 27609, United States.