AI meeting summary privacy: what actually leaves your Mac

AI meeting summary privacy comes down to one door

Every honest privacy claim has an exception. Make a tool show you the exception before you believe the rest of the sentence. Most of what Savory does never touches a network: capture, transcription, the people library, and search all run on the machine in front of you, and none of it ever leaves your hardware. That side of the story lives in full on the privacy page and in the piece on on-device transcription. This post is about the exception.

AI meeting summary privacy is not really a question about walls. It is a question about one door, because the optional AI summary is the only feature in Savory that sends anything off your Mac. Everything else you do in the app leaves no trace beyond your own hardware. One door, and it stays shut until you open it.

There is a design decision underneath that. Rather than scatter network calls across the app wherever they happened to be convenient, the whole summary path is funneled through one place you can audit. A single door is a thing you can inspect, gate, and reason about. A hundred small ones are a thing you have to trust.

To be exact about the walls before we leave them: your audio is captured and transcribed on your own machine, the transcript and the people around it stay in a local store, and search runs against that store without a round trip. None of that is what this post defends. This post defends the one place where that pattern is broken on purpose.

So the rest of this is a tour of that door. What opens it, what passes through it, what gets stripped on the way out, and what, honestly, does not. If you remember one thing from this, remember that nothing goes through the door unless you are the one who sends it.

Off until you open it

The summary feature ships off. A fresh install records, transcribes, and files meetings without ever composing a single network request, and it will keep doing exactly that forever if you never change a setting. Summaries are opt-in, off by default, and decided per meeting.

Off by default is a phrase every product uses, so here is the concrete version. A transcript-only meeting stays transcript-only until you explicitly ask for a summary of that specific meeting. There is no global switch that quietly turns your whole library into outbound traffic, and no background job that summarizes things while you sleep.

There is a reason it is per meeting and not a blanket setting. Most meetings never need a summary. A one-on-one you remember fine, a standup that ran five minutes, a call that ended in a decision you already acted on: sending those to a model would be cost and exposure with no return. Making the choice small and local keeps the default at nothing sent.

This is also why the free tier makes no calls at all. Summaries run on your own API key, so on a plan with no key attached there is simply nothing to send and no way to send it. The absence of network traffic is not a policy we are promising to honor. It is what physically happens when there is no key to authorize a request, and you can see where the tiers draw that line on the pricing page.

The feature itself, the key topics, decisions, and action items with owners, is described on the summaries page. Here we care only about the plumbing behind it: the moment you tap generate, and what physically happens next.

Your key, your call

The first thing that happens when you tap generate is that Savory reaches for a key you supplied. Summaries are bring-your-own-key: you paste in credentials for your own OpenAI or Gemini account, and Savory uses them to make the call on your behalf. No key means no call is ever made. That is not a feature flag you can forget to set. It is the literal precondition for the code path to run.

When the call does run, the text goes directly from your Mac to your own provider account. It does not stop at a Savory server along the way, because there is no Savory server in this path today. The request originates on your machine and terminates at OpenAI or Gemini under your credentials.

That arrangement has a plain consequence worth stating out loud. The summary is billed to you, rate-limited by you, and governed by the account you already have. Savory is the thing that assembles the request and guards it, not a broker sitting in the middle taking a cut of your text.

Bring-your-own-key is not only a billing decision. It means Savory never has to hold a shared credential that could be drained, leaked, or subpoenaed, and it means you can rotate or revoke access on your provider's dashboard without asking us for anything. The key lives on your own machine, not on a server we operate. When the door is keyed to something only you hold, we cannot open it on your behalf even if we wanted to.

But your account is not the same thing as safe to send raw. A transcript is a dense object, full of the kind of strings you would not want copied into a third party's logs by accident. So before the text leaves, it goes through a scrubber.

What the scrubber removes, and what it doesn't

The scrubber makes a pass over the transcript and removes four specific kinds of identifier: email addresses, phone numbers, runs of sixteen digits shaped like a card number, and UUIDs, the long machine-generated ID strings that show up in shared links and internal tools. All four are pattern-shaped, which is exactly why they can be found and stripped reliably before anything is sent.

Each summary records how many identifiers it stripped. That per-summary redaction count is not decoration. It is a receipt. It means the scrubbing is a measured event you can look at after the fact, not a claim you are asked to take on faith.

Now the part most privacy pages quietly skip. The scrubber does not remove spoken names, physical addresses, Social Security numbers, or dates of birth. If those things were said in the meeting, they are in the transcript, and they are sent verbatim. It would be easy to imply otherwise on a marketing page, and it would be false.

Attendee names are not an oversight, either. They are kept on purpose. A summary that says 'Speaker 2 will own the forecast' is useless, so real names are deliberately included as labels, and inline speaker names in the transcript itself are a macOS and Meetings-mode feature. The trade is honest: the summary is useful precisely because it knows who said what, and that means names cross the door.

So do not read the scrubber as anonymization, because it is not that. It removes four classes of machine-readable identifier and nothing more. The right mental model is a filter that catches the strings you would most regret leaking automatically, not a curtain that hides who was in the room or where they live.

Two more passes before the send

Scrubbing is not the only thing that runs before the request goes out. A prompt guard makes a second pass over what is about to be sent, layered on top of the scrubber rather than standing in for it. Two passes, not one, on the way to the door.

There is also a spend cap that runs pre-flight. Before the call is made, Savory checks the request against a cost ceiling, so a pathologically long transcript or a runaway loop cannot quietly turn into a large bill on your provider account. The cap runs first, before any tokens are spent.

The order matters, so it is worth naming. The transcript is scrubbed first, then the prompt guard reviews what scrubbing produced, then the spend cap clears the request against a ceiling, and only then does anything reach the network. Each step runs on your machine, before the door, so a failure at any one of them stops the send rather than chasing it out afterward.

Neither of these changes the honest limits above. A prompt guard and a spend cap are gates on the door, not new walls behind it. They exist so that the one path in the app that can send text off your Mac is the most scrutinized path in the app, not the least.

Where the text lands, and whose rules apply

Once the scrubbed text reaches OpenAI or Gemini, it is in their hands under their terms. Because you are using your own API key, the request is governed by your provider's data and retention policy, whatever that happens to be for your account and your region. That is a genuine boundary, and pretending otherwise would be its own kind of dishonesty.

This is the edge of what Savory can promise. The guarantee is scoped to two things: what the scrubber strips before sending, and the opt-in gate that keeps the door shut until you open it. What a third party does with the text after it arrives is that third party's contract with you, not one Savory can make on their behalf.

Which provider, and therefore whose terms, is your call as well. Because the key is yours, you pick OpenAI or Gemini based on the account and the region you already trust, rather than inheriting whichever backend a vendor happened to wire up. That is more setup than a single hosted button would be. It is also the reason there is no single hosted button holding everyone's transcripts in one place.

That is not a dodge. It is the accurate shape of the situation. If your provider's retention terms matter for a given transcript, and for some transcripts they genuinely should, read them the way you would read any vendor you hand data to. Savory's job is to make sure the text that reaches them is opt-in, scrubbed, guarded, and sent under your own account. It is not to quietly rewrite the policy on the other side of the door.

The path we haven't built yet

It is worth being just as clear about what does not exist yet, because it is easy to assume it does. There is no Savory-operated summary backend today. A hosted or metered summary path, where you would pay Savory instead of wiring up your own provider key, is planned, not shipped.

Today the shape is simple and direct: text goes from your Mac to your own provider account, and that is the only shape there is. When a hosted path does arrive, it will be a different door with its own guarantees to describe, and we will describe them plainly rather than let anyone assume the old shape still holds.

When we do build a hosted path, it will have to earn the same scrutiny this one gets. A Savory-operated backend would mean we hold the key and the traffic, which is a heavier promise than scrubbing, gating, and letting you send under your own account. We are not going to ship that quietly and let the word summary keep meaning what it means today. If the shape changes, the page changes with it.

We mention the unbuilt path here for the same reason we listed what the scrubber ignores. A privacy story is only trustworthy to the degree it tells you where its edges are. A roadmap dressed up as a shipped feature is just a nicer way of being wrong.

Read the door, not the brochure

If you want to check any of this, the test is a close cousin of the one that works for the walls. Leave your API key out, and no summary call can be made no matter how many times you tap generate. Add a key, ask for one summary, and watch the redaction count tell you how many identifiers it stripped on the way out.

The strongest version of a privacy claim is one you can verify without trusting the person making it. The walls, capture and transcription done locally, are close to physics. The door is narrower and more deliberate: opt-in, keyed, scrubbed, guarded, and pointed at your own account. Both are stated the same way, in plain language, so you can check either one for yourself.

None of this asks you to like the trade. You are allowed to decide that even one scrubbed, opt-in, keyed request is one too many, and to never turn the feature on. That is a supported way to use Savory, not a degraded one. The transcript and the people library are the product; the summary is the one optional step that reaches past your own hardware.

If you want the feature-level version of all this, the summaries page walks the same door from the product side. Read it, look at what the scrubber does and does not touch, and then decide for yourself whether to open the door at all.