Every AI meeting assistant creates a new copy of some of the most sensitive information a company produces.

Product roadmaps. Personnel discussions. Customer objections. Security concerns. Financial plans. The informal explanation behind a decision that never makes it into the official document.

The meeting-assistant category tends to talk about what it can extract from those conversations: transcripts, summaries, action items, insights, and organizational memory. The less comfortable question is what happens to the underlying conversation after the work is finished.

Where does it live? Who can retrieve it? How long does the vendor retain it? What happens when an employee leaves? Can a link unintentionally make it public? Can one customer enumerate another customer’s meetings? Does a supposedly temporary conversation quietly become permanent infrastructure?

Those questions are not theoretical. Publicly acknowledged incidents across the category show what can happen when meeting content, metadata, credentials, permissions, and sharing rules are allowed to accumulate inside a centralized service.

They also explain several architectural decisions we made at Earmark.

Earmark captures audio from the user’s device without sending a bot into the meeting. Raw audio is processed for transcription but is not retained as a permanent recording. A meeting can be preserved in the workspace when the organization wants durable memory, or run in Temporary Mode when it should not become part of that long-term history. At the same time, the desktop app can automatically save the transcript as a plain Markdown file on the user’s own machine.

Those capabilities are related, but they solve different problems.

Temporary Mode limits how long Earmark retains the meeting. Local Markdown prevents Earmark from becoming the only place where the user’s meeting context can exist. Together, they let a company distinguish between vendor retention and user ownership instead of treating every conversation as another permanent cloud object.

The safest record in a vendor’s database is often the record the vendor was never expected to keep forever.

That does not make Earmark immune to security risk. It does not eliminate consent requirements, endpoint security, access control, cloud-processing risk, or the responsibility to protect locally stored files. It does mean the architecture can reduce the number of sensitive records that remain inside a centralized meeting database long after their immediate purpose has passed.

The public record across Earmark’s competitive set shows why that distinction matters.

Earmark separates processing, retention, and ownership

Most meeting tools collapse three decisions into one:

1. The service processes the meeting.

2. The service retains the meeting.

3. The service becomes the primary place from which the user can retrieve it.

Earmark separates them.

Audio is captured from the device, not by a meeting bot

Earmark captures microphone and system audio through its desktop application. Nothing joins the Zoom, Google Meet, Microsoft Teams, Webex, or in-person conversation as a separate participant.

The audio is streamed to AssemblyAI over an encrypted WebSocket connection for real-time transcription. According to Earmark’s security documentation, the raw audio is not stored after the transcript is generated.

This is device-side capture, but it is important to be precise: device-side does not mean that all processing happens locally. The audio originates on the device and is streamed for transcription. The architectural benefit is that Earmark does not need a cloud-controlled meeting participant, calendar bot, conference credential, or external bot account to enter the call.

That removes an entire class of bot-specific behavior: bots attempting to join the wrong meeting, bots remaining after the inviting participant leaves, exposed conference identifiers being used to send a notetaker into active rooms, and meeting-platform permissions becoming part of the assistant’s attack surface.

It does not remove the user’s responsibility to disclose or obtain consent when required. Because Earmark is not visible as another participant, the person using it must follow the laws and organizational policies that apply to the conversation.

The meeting does not have to become permanent cloud memory

Standard Earmark meetings remain available in the workspace until they are deleted, subject to the organization’s retention policies. That is useful when the conversation should contribute to a project, become searchable later, or provide evidence for future agents.

But not every meeting belongs in organizational memory.

Personnel conversations, exploratory strategy sessions, sensitive customer discussions, quick internal syncs, and early-stage brainstorming may be useful while they are happening without deserving permanent retention.

Earmark’s Temporary Mode allows the meeting to function normally while it is active. Live transcription, agents, templates, and artifact generation still work. When the meeting ends, the record automatically enters Earmark’s deletion lifecycle. It can be recovered for 30 days, after which the meeting, transcript, tasks, artifacts, and participant records are permanently purged.

Workspace administrators can enforce Temporary Mode across every new meeting rather than relying on each employee to remember to select it.

That 30-day recovery period means “temporary” should not be misrepresented as instantaneous deletion. The record is soft-deleted first and permanently removed after the recovery window. The meaningful architectural distinction is that the service is not expected to retain it indefinitely.

The durable record can belong to the user instead of the vendor

Earmark’s desktop app also automatically saves meeting transcripts as Markdown files. This is enabled by default for both standard and temporary meetings, with files saved by default to:

~/Documents/Earmark/Meeting Transcripts/

The location can be changed to another folder inside the user’s home directory. Each file includes structured metadata followed by the transcript in a plain-text format that tools such as Claude Code, Claude Cowork, Codex, Cursor, local search utilities, and knowledge-management systems can read directly.

There is no export workflow, proprietary document format, API credential, or active Earmark subscription required to open a Markdown file.

At first, Temporary Mode and local autosave might appear contradictory. One deletes the cloud record while the other creates a local record. In practice, they represent two independent decisions:

This separation matters. A company may not want a sensitive transcript retained indefinitely in a SaaS database but may still need a controlled copy inside its own device-management, filesystem, backup, or document-governance environment. Another company may decide that a particular conversation should leave no durable transcript at all.

Earmark supports both outcomes without pretending they are the same policy.

Local storage introduces its own responsibilities. A Markdown transcript can be copied, emailed, synced to iCloud or another backup service, indexed by a local agent, or exposed by a compromised endpoint. Moving custody from a vendor-controlled database to the user’s filesystem does not make the file magically secure. It changes who controls the file, which policies apply to it, and whether access depends on the vendor’s service remaining available.

That distinction - between eliminating risk and relocating control - is important throughout this review.

What the public record shows

The publicly documented incidents across Earmark’s competitive set fall into several different categories. Some were genuine authorization or credential failures. Others were sharing defaults that behaved as designed but produced an unexpected disclosure. Several are unresolved legal allegations rather than established incidents.

Granola: four acknowledged technical vulnerabilities

Granola deserves credit for maintaining a public security-report index. As of this review, it includes three postmortems and one researcher-contribution report.

Transparency is a positive signal. It does not make the underlying failures irrelevant.

An exposed AssemblyAI credential made beta transcripts accessible

A TestFlight version of Granola’s iOS app used an unauthenticated feature-flag endpoint that returned a long-lived AssemblyAI API key. Anyone who obtained that credential could query AssemblyAI’s transcript endpoint, enumerate transcript identifiers, and retrieve transcripts created through that integration.

Tenable documented the vulnerability in TRA-2025-07 and rated it medium severity.

According to Granola’s postmortem, the credential had been exposed since November 27, 2024. Granola moved transcription server-side on December 16, but the original key remained unintentionally available from the endpoint.

Tenable attempted to contact Granola twice in February 2025. Those messages were missed. The two organizations established contact on March 10, Granola received the technical details on March 11, and the company removed and revoked the credential that day.

AssemblyAI was used by Granola’s invite-only iOS beta rather than the company’s production macOS application. Granola reported that 333 beta testers were potentially affected. A later log review found that Tenable’s IP address had accessed 29 transcripts belonging to 16 external testers during a 12-minute testing window. Tenable said the access was part of its controlled validation and that it did not retain the transcript data.

Granola found no evidence of additional unauthorized access and notified the 333 beta users.

The architectural lesson extends beyond Granola. A third-party credential embedded in a client or returned by an unauthenticated configuration endpoint effectively becomes a shared credential for anyone who can retrieve it. The security of every associated transcript then depends on a secret that is no longer secret.

Earmark also uses AssemblyAI for transcription, which makes this incident directly relevant to us. Our security cannot rest on the reputation of a subprocesser alone. Provider credentials must remain server-side, be narrowly scoped, monitored, scanned for accidental exposure, and rotated when necessary. Raw audio should not be retained simply because a provider integration makes retention possible.

Earmark’s decision not to store raw meeting audio reduces the material available after processing, but it does not excuse weak credential management. Data minimization and secret management are complementary controls.

Corporate-domain matching could admit unmanaged Google accounts

Granola’s workspace auto-join feature once treated possession of an email address on a company domain as proof that the account was managed by that company’s Google Workspace.

Historically, Google allowed people to create unmanaged personal Google accounts using addresses that looked like corporate accounts. A former employee who retained one of those accounts could therefore appear to belong to the organization and potentially join a Granola workspace when automatic domain-based admission was enabled.

Granola’s June 2025 postmortem says a customer reported the issue on May 16. Granola changed its admission logic to require explicit Google Workspace membership and deployed the correction on May 23.

Database reviews found no unmanaged accounts inside customer workspaces and no unauthorized access beyond the reporting customer’s testing.

This was an authorization vulnerability, but the public evidence does not establish a victim or a data breach.

The lesson is that identity must be derived from an authoritative organizational signal, not inferred from the shape of an email address. This remains true regardless of retention architecture. Temporary data can still be exposed during its lifetime if the wrong person is admitted to the workspace.

Removed users retained valid Granola sessions

A separate identity-lifecycle problem occurred when an employee’s Google account was suspended, deleted, or disconnected from Granola.

The organization-level identity had been removed, but the person’s existing Granola session remained valid until the user explicitly logged out.

Granola’s session-logout postmortem identified 187 people who had lost or removed their underlying Google connection since November 2024 but could still access historical notes and transcripts through an active Granola session.

Desktop and iOS fixes were released on May 28, 2025, followed by a web-session correction on June 2. Granola then automatically logged out the affected accounts.

The company did not identify malicious use in its public report. The access-control failure was nevertheless real: the organization revoked an identity, but the meeting service did not immediately honor that decision.

This is where retention changes the blast radius. When a meeting platform holds years of historical conversation, a stale session can provide access to years of accumulated context. If sensitive meetings are automatically purged after a defined period, the same access-control failure still matters, but less historical material remains available.

Retention is not a substitute for immediate session revocation. It determines how much data a revocation failure can expose.

A crafted notification could navigate the desktop app to an untrusted page

In June 2026, a researcher found that a malicious Granola user could manipulate a profile name so that it appeared as a link inside a desktop notification. If the target clicked it, the Granola app could navigate to an external page. The app’s navigation model could then allow that page to reach the user’s signed-in session and locally available data.

Granola’s researcher-contribution report describes several prerequisites. The attacker needed access to a private-note link they did not already control, had to trigger an access-request notification, and needed the target to click the crafted content.

Granola sanitized user-controlled notification text, added an untrusted-navigation guard, corrected a bypass found during retesting, and received confirmation on June 29 that the vulnerability had been remediated.

The company found no affected users and no exploitation beyond the researcher’s proof of concept.

This incident is particularly relevant to products that interact with local data. Local-first functionality is not automatically safer if an application’s webviews, deep links, navigation rules, or agent permissions allow untrusted content to cross into the local environment.

Earmark’s local Markdown design gives users control over their files, but it also requires us to maintain a strong boundary between untrusted meeting content and local execution. A transcript may contain URLs, code, instructions, or adversarial content. Local agents should treat that material as data, not as trusted commands.

tl;dv: a cross-tenant meeting index and a path into live calls

The most consequential publicly documented technical issue in this competitive set is tl;dv’s 2026 Firebase authorization failure.

An independent researcher reported that any authenticated tl;dv user could query the platform’s Firestore meetings collection across customer boundaries. The records included creator email addresses, conference identifiers, meeting providers, timestamps, and recording status.

The researcher’s technical account says the exposed collection contained 181,874 meeting records associated with 84,312 users and 35,003 email domains. Government domains from 23 countries appeared in the data.

That does not mean 181,874 private transcripts were publicly exposed.

The researcher reported that collections containing private transcripts, recordings, clips, and notes correctly rejected the same cross-tenant access. In a sample of 27,334 meeting identifiers, more than 1,000 resolved to content that users had separately configured as public. The authorization failure made those public objects easier to enumerate; it did not independently make every private transcript public.

The active-meeting risk was different. Records marked as currently recording exposed conference identifiers that could be used to locate live calls. The researcher entered two meetings using those identifiers: one associated with a Malaysian educational institution and another involving a U.S. university.

As Dark Reading reported, knowing the conference identifier did not necessarily bypass Google Meet or Microsoft Teams admission controls. Some meetings were open. In other tests, an organizer manually admitted an unfamiliar participant that appeared to be a notetaker.

The human admission step limits what the tl;dv flaw accomplished technically. But the vulnerability still exposed a directory of active meetings and gave an attacker a credible identity to present at the door.

The researcher and tl;dv disagree about the remediation timeline. The researcher says the issue was first reported on January 28 and remained reproducible through July. tl;dv says it fixed and independently validated the original vector, while the August disclosure used a different path through the same Firebase-backed area. The company says that second path was closed within 24 hours.

In its public response, tl;dv acknowledged that meeting identifiers, conference IDs, participant emails, and domains had been accessible. It stated that passwords, billing information, account data, private recordings, private transcripts, and private AI notes were not exposed by the vulnerability.

tl;dv said it would remove Firebase from this portion of its architecture and improve its vulnerability-reporting process. Its CTO also acknowledged that the company had failed to keep the researcher adequately informed.

The fair conclusion is not that tl;dv leaked 181,874 transcripts. It is that a cross-tenant authorization failure exposed a large, centralized meeting index, made public meeting content easier to enumerate, and created a practical route for attempting to enter active conversations.

Earmark’s botless architecture reduces the specific live-call risk because there is no Earmark-controlled meeting participant to dispatch into an exposed conference room. A conference identifier is not required for Earmark to capture audio from the user’s device.

Temporary Mode addresses the other half of the lesson. A centralized index becomes more consequential as it accumulates years of meetings. Automatically removing records that do not need to persist reduces the long-term value of such an index to an attacker.

Neither decision eliminates the need for strict tenant isolation. Temporary records still require correct authorization while they exist, and standard meetings retained for organizational memory remain sensitive. The principle is simply that the system should not accumulate more exposure than the customer has intentionally chosen.

Otter.ai: when a transcript outlives the attendee

In September 2024, researcher Alex Bilzerian attended a Zoom meeting with venture investors. He left before the investors continued with an internal discussion.

Otter continued recording until the meeting itself ended. Because the meeting was configured to share its transcript automatically with invited guests, Bilzerian later received the entire transcript, including the portion recorded after he had departed.

He told The Washington Post that the contents changed his opinion of the firm and ended the prospective deal.

Otter responded that customers control the service’s sharing permissions. Automatic sharing can be disabled, and organizations can restrict sharing to people inside the same workspace domain.

Those facts matter. The evidence does not show an external attacker, broken authentication, or cross-tenant access. Otter distributed the transcript through a configured product pathway.

The incident is still security-relevant because the product’s recipient logic was based on the calendar invitation rather than the portion of the meeting each recipient actually attended. A person who leaves a room would not normally expect to receive notes from the confidential conversation that followed.

This is a product-semantics problem: who counts as a participant, when their access begins, when it ends, and which portion of the record they should receive.

It is also a retention problem. A transcript cannot be distributed later if no transcript is retained. That does not mean every meeting should disappear; many meetings need a durable record. It means retention and distribution should both be intentional rather than automatic consequences of inviting an assistant.

With Earmark, a sensitive meeting can be processed in Temporary Mode and removed from the service’s long-term history. The user can generate the required decision, follow-up, or artifact during the conversation without necessarily turning the complete transcript into a permanent shared object.

If the user wants a private local record, Markdown autosave provides one under the user’s control. If no durable transcript is appropriate, local autosave should be disabled or the file deleted. Temporary cloud retention and local persistence are separate choices.

Granola: when “shared” quietly means “public to the link”

In April 2026, The Verge reported that Granola’s default sharing option allowed anyone possessing a note link to view the shared page without signing in.

The pages were unlisted and were not intended to appear in search results. Granola had not published every customer note openly on the web. A user first had to share the note, and another person needed to obtain the resulting URL.

But once that link left the intended channel, possessing the link was sufficient authorization.

The shared page could contain the meeting summary and quoted portions of the transcript. Access to the complete transcript required explicit collaborator permissions inside Granola.

Granola’s current sharing documentation offers “Anyone with the link,” “Only my company,” and “Private” options. For Free and Business plans, changing the default affects future notes rather than retroactively changing every existing note. Enterprise administrators can enforce organization-wide sharing rules, including retroactive changes. Granola now recommends using the most restrictive sharing level compatible with the workflow.

This was not evidence of an authentication bypass. It was a permissive product default whose meaning could be misunderstood.

Local Markdown takes a different approach to portability. Instead of creating a vendor-hosted public page, Earmark writes a file to the user’s device. The user can move that file into the company’s existing document system, repository, agent workspace, encrypted storage, or collaboration environment.

That avoids making an Earmark URL the permanent gateway to the conversation. It does not prevent the user from sharing the Markdown file carelessly. The difference is that the sharing boundary is the organization’s chosen filesystem and tooling rather than a public-by-link page controlled by the meeting vendor.

Fireflies.ai: a transparency problem rather than a system breach

In November 2025, Fireflies co-founder Sam Udotong described how he and co-founder Krish Ramineni manually joined and took notes during more than 100 early customer meetings while appearing as “Fred,” the AI assistant they were attempting to build.

Business Insider reported that Ramineni said the testers were friends who knew humans were involved, although they may not have understood how much of the process was manual.

Inc. highlighted an apparent contradiction between Udotong’s account of the founders taking notes themselves and a separate company statement that the platform had operated without human reviewers from the beginning.

The episode matters because people may speak differently when they believe software is processing the conversation rather than another human listening behind the interface.

It is not a documented compromise of Fireflies’ current production system. The sources do not establish that meeting information escaped the service or was misused. It belongs in the public record as an early transparency and trust event, not as a technical breach.

The architectural lesson is broader than Fireflies. “AI processed” is not a sufficiently precise description of what happens to a conversation. Customers should know which providers receive data, whether people can access it for support or quality review, whether it is retained, and whether it contributes to model training.

Earmark states that customer meeting content is not used to train AI models. Raw audio is not stored after transcription. Those commitments should remain explicit, testable, and reflected in subprocesser agreements—not left as assumptions created by the interface.

The recurring problem is accumulation

These incidents look different on the surface.

Granola exposed a subprocesser credential. Another Granola flaw failed to end sessions when the underlying identity disappeared. tl;dv exposed a cross-tenant index of meetings and conference identifiers. Otter sent a transcript to someone who was no longer present. Granola’s link-sharing default made possession of a URL sufficient authorization.

But they share a structural characteristic: the service had accumulated sensitive objects, relationships, or permissions that remained valuable after the live conversation ended.

A retained transcript becomes something that can be exposed.

A centralized meeting index becomes something that can be enumerated.

A persistent session becomes a route into years of historical context.

A permanent public link becomes an access-control decision that may outlive the person who created it.

A long-lived provider credential becomes a key to every object created through that integration.

Accumulation is not inherently wrong. Organizational memory is one of the most valuable things a meeting assistant can create. Earmark itself supports Projects, shared context, permission-aware retrieval, and agents that reason across prior conversations.

The mistake is treating accumulation as the unavoidable default for every meeting.

The architecture should make it possible to preserve conversations intentionally and discard them intentionally. Security teams should not have to choose between “the product is useful” and “the product retains everything.”

Why Earmark’s architecture matters

Earmark’s architecture does not guarantee that no incident can occur. What it does is create controls at the points where the public record shows risk accumulating.

No retained raw-audio archive

Earmark does not keep raw meeting audio after transcription. If an attacker compromises the transcript layer, that remains serious, but there is not also a permanent library of voice recordings waiting behind it.

This matters because raw audio contains more than words. It contains voices, tone, background conversations, emotional cues, and potentially biometric characteristics. Not retaining it removes an entire class of durable material from the service.

Temporary Mode limits long-term cloud exposure

A temporary meeting remains fully functional while it is happening and then automatically enters the deletion lifecycle. After the 30-day recovery window, the meeting and its associated transcript, artifacts, tasks, and participant data are permanently removed.

That means sensitive meetings do not have to remain indefinitely available to future stale sessions, authorization failures, search indexes, public links, subpoenas, internal misuse, or vendor compromise.

The control can be enforced at the workspace level, which is crucial. A security policy that depends on every employee remembering to make the right choice during every meeting is not much of a security policy.

Botless capture removes the cloud participant

Because Earmark captures from the device, it does not need to receive conference credentials and send a vendor-controlled participant into the call.

That reduces exposure to bot-admission errors and meeting-identifier attacks. It also allows Earmark to work across meeting platforms and in person without requiring a new integration with every conferencing service.

Botless does not mean invisible use is always appropriate. It means meeting capture is controlled from the user’s device rather than through an external participant.

Local Markdown breaks the dependency on a permanent SaaS silo

When a meeting ends, the Earmark desktop application can write the transcript to the user’s filesystem as a Markdown file.

The file is portable, searchable, human-readable, and directly usable by local agents. The user does not need to ask Earmark’s API for permission to access their own conversation. If the customer stops using Earmark, the files still work.

This also gives organizations another retention pattern: use Earmark temporarily for live transcription and artifact generation, allow the vendor-side record to expire, and preserve only the local file or finished artifact inside systems the organization already controls.

That is not “zero storage.” It is user-controlled storage rather than indefinite vendor-controlled storage.

Retention can match the meeting instead of the product

A roadmap review may deserve long-term organizational memory. A sensitive HR conversation may not. A customer discovery call might need a retained evidence trail. A casual brainstorm may need only a decision or a few tickets.

The architecture should not force all four conversations into the same retention model.

Earmark can preserve standard meetings, automatically remove temporary meetings, save a local transcript, generate only the necessary artifact, or avoid a long-term local copy. Those choices let organizations apply different policies to different categories of conversation.

What Earmark is not claiming

The wrong conclusion from this research would be:

Competitors have experienced incidents, therefore Earmark is safe.

Every product that processes sensitive meeting context carries risk, including Earmark.

Device-side capture creates endpoint responsibilities. Local Markdown files must be protected by device encryption, access controls, backup policies, data-loss-prevention tools, and responsible agent permissions.

Temporary meetings exist in Earmark during processing and remain recoverable during the 30-day soft-delete window. They still require encryption, tenant isolation, access control, secure subprocessers, and operational monitoring.

Botless capture does not notify other participants. Users and organizations remain responsible for consent, disclosure, privacy, and workplace requirements.

No-training commitments must be supported by contracts, subprocesser controls, and internal practices.

Plain Markdown is portable partly because it is easy to copy. That is useful for ownership and agent workflows, but it also means users can move sensitive transcripts outside approved systems if endpoint governance is weak.

The architectural claim is narrower and more defensible:

Earmark allows customers to receive the value of live meeting intelligence without requiring every meeting to become a permanent record inside Earmark.

That is a meaningful reduction in exposure. It is not an exemption from security work.

What buyers should ask every meeting-assistant vendor

The incidents in this review suggest a practical set of questions for evaluating any meeting assistant, including Earmark.

1. Does every meeting have to be retained? Ask whether the product supports temporary processing, automatic deletion, differentiated retention policies, and workspace-level enforcement.

2. What remains after deletion? Understand soft-delete windows, backups, embeddings, generated artifacts, participant records, support copies, and subprocesser retention. “Deleted” should have a defined lifecycle.

3. Is raw audio retained? Distinguish between transient audio processing and a permanent recording library.

4. Can customers keep their own portable copy? A local or standard-format export reduces vendor lock-in and lets the organization govern its meeting data using existing systems.

5. Can one tenant enumerate another tenant’s meetings? Test authorization across meetings, participants, transcripts, recordings, clips, search results, public objects, exports, and live status feeds.

6. What can a conference identifier reveal or unlock? Meeting IDs, join URLs, calendar metadata, and active-recording status should be treated as sensitive even when the conferencing platform has a waiting room.

7. Are third-party credentials ever shipped to a client? Provider keys should remain server-side, narrowly scoped, monitored, scanned for exposure, and rotated.

8. Does identity revocation end every active session? Removing a user through Google Workspace, Microsoft Entra ID, Okta, or another identity provider should terminate access without waiting for manual logout.

9. Who receives the transcript when attendance changes? The product should distinguish between invitees and actual attendees and understand when someone joins or leaves.

10. What does a sharing link authorize? Ask whether authentication is required, whether links expire, whether policies apply retroactively, whether pages are indexed, and whether links can be centrally revoked.

11. Can untrusted meeting content reach the local environment? Desktop navigation, deep links, webviews, rendered HTML, downloaded files, and local agents need strong boundaries.

12. How are nonusers informed? Ask how consent is handled, whether speaker recognition is used, whether nonusers can request access or deletion, and whether a visible bot is being treated as the only form of notice.

13. Is meeting content used for model training? The answer should cover the vendor and every AI or transcription subprocesser.

14. What happens when a researcher reports a vulnerability? A monitored disclosure channel, acknowledgment target, remediation owner, status communication, and retesting process are security controls.

15. What has the company publicly disclosed before? A detailed postmortem proves that something failed, but it can also show that the company knows how to investigate, contain, and explain an incident. Silence is not proof of a spotless history.

The meeting should create the work - not an unnecessary permanent liability

The value of a meeting assistant is not the size of the transcript archive it can accumulate. The value is what the organization can do with the conversation.

Sometimes that means preserving the meeting as durable, permission-aware organizational memory. Sometimes it means generating a PRD, decision log, customer follow-up, or set of tickets and then allowing the underlying conversation to disappear.

Sometimes it means keeping a local Markdown transcript that the user’s own tools and agents can work with. Sometimes it means keeping no transcript at all.

Those should be deliberate choices.

The incidents across Granola, tl;dv, Otter, and the wider category demonstrate how centralized meeting data can become vulnerable through credentials, authorization rules, identity lifecycles, public links, and recipient logic. The unresolved lawsuits show that retention and processing also create legal questions even when no attacker is involved.

Earmark’s answer is not to pretend meeting data can be made risk-free. It is to avoid requiring a permanent vendor-controlled record as the price of receiving value from the conversation.

Capture can begin on the device. Raw audio does not need to become a stored asset. A meeting can operate temporarily. The vendor-side record can be purged automatically. The user can keep a portable Markdown copy locally when that is the right outcome—or decline to create a durable copy when it is not.

Meeting intelligence should be useful for exactly as long as the customer intends.

Anything longer should be a choice.

Editorial note: This article is based on publicly available information. “Temporary” refers to Earmark’s documented deletion lifecycle: meetings enter soft deletion after completion and are permanently purged after a 30-day recovery window. Local transcript autosave is a separate setting and may create a durable copy on the user’s device.