Mac Voice-to-Text Permissions: What's Safe

Q: Why does voice-to-text need Accessibility permission?

To simulate a Cmd+V paste keystroke that delivers transcribed text to your active app. Without Accessibility, the app can transcribe but can't insert text anywhere. Accessibility doesn't grant access to read screen or files; only keyboard simulation and UI element role detection.

Q: Is granting Microphone access dangerous?

Microphone scope is narrow: the app can only read audio while running. macOS shows mic-active indicator in menu bar. Risk is low if you trust the app to handle audio appropriately. For on-device tools like MetaWhisp, audio never leaves your Mac.

Q: What does Accessibility permission actually let an app do?

Simulate keyboard input, read UI element names and roles via Accessibility API, detect focused app, register global hotkeys. Does NOT grant access to read screen pixels, file contents, network connections, or microphone audio — those are separate permission categories.

Q: How do I revoke permissions from a voice-to-text app?

System Settings → Privacy & Security → click each category → find app → toggle off. For full cleanup of no-longer-trusted app: uninstall, delete ~/Library/Application Support/AppName/, check ~/Library/LaunchAgents/ for leftover background processes.

Q: Why do cloud-based voice apps have a worse privacy posture?

On-device apps only need to be trusted to handle audio locally (Microphone + Accessibility). Cloud apps add entire network path — TLS keys, server-side processing, retention policies, subpoena exposure, vendor staff access. Materially larger surface area.

🔒🎙️

macOS Permissions for Voice-to-Text Explained

Required: Microphone

For auto-paste: Accessibility

Red flag: Full Disk Access

Never share: Screen Recording

TL;DR: A voice-to-text app on Mac needs exactly two permissions: Microphone to capture audio and Accessibility to paste transcribed text into other apps. Anything beyond that — Full Disk Access, Screen Recording, network access (for cloud apps) — is either a red flag or a specific cloud-feature requirement you should verify. Apple's macOS permissions model isolates each permission so you can grant Microphone without granting access to your files or screen. This guide explains what each permission actually lets an app do, why MetaWhisp only asks for Microphone and Accessibility, and how to spot apps that overreach.

Mac voice-to-text app permissions panel showing required Microphone Accessibility versus dangerous Full Disk Access Screen Recording with safety annotations

What macOS Permissions Does Voice-to-Text Actually Need?

A well-architected voice-to-text app on Mac needs exactly two macOS permissions. Anything more should make you suspicious. 1. Microphone permission — Required to capture audio from your built-in or external mic. Without this, the app can't record speech to transcribe. Granted via System Settings → Privacy & Security → Microphone. The permission scope is narrow: the app can only read audio from microphone inputs while it's running. 2. Accessibility permission — Required to simulate a Cmd+V paste keystroke that delivers the transcribed text to your active app. Without this, the app can transcribe but can't insert the text anywhere — you'd have to manually copy from the app's own window each time. Granted via System Settings → Privacy & Security → Accessibility. Those are the only two permissions a voice-to-text app fundamentally needs. Apps that ask for more are either:

Cloud-based and need network access (which is granted by default; no separate permission required)
Trying to do something beyond core voice-to-text functionality
Poorly architected with broader-than-necessary access requests

I'm Andrew Dyuzhov, solo founder of MetaWhisp. I designed MetaWhisp to use only Microphone and Accessibility because anything beyond those two creates unnecessary attack surface and privacy risk. This guide explains each macOS permission in detail and how to evaluate whether a voice-to-text app's permission requests are appropriate.

The macOS permissions model uses a per-permission opt-in design that's fundamentally different from the all-or-nothing approach on Windows or older Linux distributions. Each TCC (Transparency, Consent, and Control) permission has its own consent prompt and can be revoked independently per the official Apple privacy documentation. This means a voice-to-text app can be granted Microphone access while being explicitly denied access to your Documents folder, Photos, Contacts, Calendar, or screen contents. The architectural separation is what makes Apple Silicon Macs materially safer than older platforms for running untrusted software — even a malicious voice-to-text app that obtained Microphone permission can't read your tax returns because Files & Folders access is a completely separate permission gate. The catch is that some apps ask for broader permissions than they need, hoping users will grant them without reading the prompt. Treat every permission request as an explicit choice, not an automatic yes.

Why Does My Voice-to-Text App Want Accessibility?

The Accessibility permission is the one users most often question. It sounds invasive — "Accessibility" implies broad access to everything on screen. The technical reality is narrower. What Accessibility actually grants:

Ability to simulate keyboard input (Cmd+V paste, function-key presses, character input)
Ability to read the names and roles of UI elements via the macOS Accessibility API
Ability to detect which app is currently focused
Ability to register global hotkeys that work in any app

What Accessibility does NOT grant:

Reading the contents of text fields beyond what's needed for accessibility (e.g., the value of password fields is hidden)
Reading screen pixels (that's Screen Recording, separate permission)
Reading file contents on disk (that's Files & Folders or Full Disk Access)
Network access
Microphone access (separate)

For voice-to-text specifically, Accessibility is needed for one specific purpose: pasting the transcribed text into the currently-focused app. The app uses NSPasteboard to write text to the clipboard, then uses Accessibility's keyboard simulation to send Cmd+V to the focused window. This is the only way to deliver text to apps that don't expose direct text-input APIs — which is most apps, especially Electron-based ones like Slack, VS Code, Discord, and Obsidian.

Why this matters: Apple's text-insertion APIs only work for native macOS apps using NSTextView. Modern apps built on Electron, Chromium, web views, or cross-platform frameworks (Qt, Tauri) don't expose those APIs. The Accessibility-based paste approach is the universal fallback that works in every app. Voice-to-text tools that don't request Accessibility have to limit themselves to a narrow set of native apps, which defeats the purpose of being a system-wide tool.

What's the Difference Between Files & Folders and Full Disk Access?

Apple's Files & Folders permission has two flavors, and the difference matters:

Files & Folders (specific) — Grants access to specific folders like Desktop, Documents, Downloads, iCloud Drive. Each folder is a separate toggle. The app can only read/write the folders you explicitly enable.
Full Disk Access — Grants access to everything: system files, hidden user-Library contents, other users' folders, kernel extensions, even encrypted Time Machine backups. This is the most powerful permission on the Mac.

A voice-to-text app should never need Full Disk Access. If the app saves transcripts to disk, it needs access only to the specific folder where it writes (e.g., `~/Library/Application Support/AppName/`), which doesn't require Full Disk Access — it's the app's own sandbox by default. Apps that request Full Disk Access fall into a few categories:

Backup tools (Time Machine, Carbon Copy Cloner) — Legitimate need
Antivirus / endpoint security — Legitimate need
System utilities (CleanMyMac, OnyX) — Sometimes legitimate
Voice-to-text apps — Never legitimate, always a red flag

If a voice-to-text app asks for Full Disk Access, deny it and look for another tool. Apple's Security framework documentation explicitly recommends that apps request only the minimum permission necessary for their stated function.

The Full Disk Access permission deserves more scrutiny than any other macOS permission because it bypasses Apple's per-folder consent model entirely. Once granted, an app can read every file in your home directory, including SSH keys in ~/.ssh, browser cookies and session data in ~/Library/Application Support/, password manager databases, encrypted disk image metadata, and even files belonging to other user accounts on the same Mac. The damage from a compromised Full-Disk-Access app is roughly equivalent to a malicious admin on the system. Apple specifically warns developers in the file system permissions documentation that Full Disk Access should only be requested when no alternative API can accomplish the legitimate use case. For voice-to-text, no alternative is needed — voice-to-text apps don't need to read any files outside their own sandbox. An app requesting Full Disk Access for voice transcription is either incompetently engineered or actively malicious.

macOS permissions scope diagram showing Microphone Accessibility Files Folders Full Disk Access expanding access levels for voice-to-text Mac apps

Which Voice-to-Text Apps Ask for What Permissions?

Quick reference table of what permissions each major Mac voice-to-text app requests:

App	Microphone	Accessibility	Network	Other
MetaWhisp	Yes	Yes (auto-paste)	No (free tier)	None
Wispr Flow	Yes	Yes (auto-paste)	Yes (cloud)	None
SuperWhisper	Yes	Yes (auto-paste)	Optional (cloud mode)	None
MacWhisper	Yes	No	No (local)	Files (export folder)
Otter.ai	Yes	No (web only)	Yes (cloud)	Calendar (for auto-join)
Apple Dictation	Built-in	Built-in	Optional (standard mode)	None

None of these legitimately request Full Disk Access. If any app you're considering asks for it, that's a strong signal to look elsewhere. The Calendar permission for Otter.ai is specifically for its OtterPilot auto-join feature, which reads your calendar to find meetings to join. If you don't use auto-join, deny Calendar access — Otter still works for manual recording.

How Do I Audit a Voice-to-Text App's Permissions?

Before installing any voice-to-text app, check what permissions it requests. Three ways to audit:

Read the app's privacy policy — Reputable apps disclose what permissions they request and why. Vague or missing privacy policies are a red flag.
Check the App Store privacy nutrition label — For Mac App Store apps, Apple requires developers to declare data collection categories on the listing page. Direct-download apps (Gumroad, vendor websites) don't have this requirement, so you have to dig deeper.
Install in a separate user account first — Create a test user on your Mac, install the app there, observe what permissions it requests at first launch. Revoke any unexpected requests before granting access from your main account.

After installation, audit permissions via System Settings:

System Settings → Privacy & Security → Microphone — see which apps have mic access
System Settings → Privacy & Security → Accessibility — apps that can paste keystrokes
System Settings → Privacy & Security → Files & Folders — folder-by-folder file access
System Settings → Privacy & Security → Full Disk Access — the dangerous one; should be empty or near-empty
System Settings → Privacy & Security → Screen Recording — voice apps should NEVER be here
System Settings → Privacy & Security → Camera — voice apps should NEVER be here

Revoke any unexpected permissions. The app may break, which tells you exactly what it was doing — better to know than to leave broad access granted blindly.

Pro tip: macOS shows a brief "App X is using your microphone" indicator in the menu bar when an app has the mic active. Watch for this indicator unexpectedly — if your voice-to-text app shows mic-active when you didn't trigger recording, something is wrong. Same for camera (orange dot near the green Touch ID indicator on M-series MacBooks).

Does MetaWhisp Need Full Disk Access?

No. MetaWhisp uses only Microphone and Accessibility permissions. It does not need, request, or use:

Full Disk Access
Files & Folders (specific folders)
Screen Recording
Camera
Calendar
Contacts
Photos
Location

The app saves its model files and settings to its own sandbox at `~/Library/Application Support/MetaWhisp/`, which doesn't require a separate permission — sandbox access is granted by default to any app for its own container. For users who want to verify this, MetaWhisp runs entirely on-device with no network calls during transcription (Pro tier cloud features are opt-in and require explicit user authentication). You can monitor network activity with Little Snitch or run the app in airplane mode to confirm. See the full MetaWhisp privacy policy for the formal disclosure.

The combination of "Microphone + Accessibility only" with "no network calls during transcription" is the minimum-permission configuration for a system-wide voice-to-text tool. This matches the threat model that healthcare practitioners, legal professionals, journalists, and security-conscious developers actually have — they need voice-to-text that captures audio (Microphone), delivers text to apps (Accessibility), and demonstrably doesn't have any path to exfiltrate data anywhere else (no network, no Files & Folders). MetaWhisp's architecture was specifically designed around this minimum-permission constraint because voice-to-text users in regulated industries can't use tools that require broader access. The trade-off is fewer cloud features in the free tier, which is a deliberate choice — users who need the cloud features can opt into MetaWhisp Pro, which requires explicit account authentication for the network feature scope. The architectural separation between free on-device and Pro cloud means downgrading from Pro keeps all free-tier privacy guarantees without reinstalling.

What Permissions Do Cloud-Based Voice-to-Text Apps Add?

Cloud-based voice-to-text apps (Wispr Flow, Otter.ai, OpenAI Whisper API) have the same Microphone + Accessibility baseline but add network-related capabilities. These don't show up as separate macOS permissions but matter for privacy:

Outbound network connections — The app sends audio to the vendor's servers. macOS doesn't prompt for this; network is granted by default. Block at the firewall layer (Little Snitch) if you want explicit control.
Authentication tokens — The app stores cloud session tokens, often in macOS Keychain. Granting Keychain access is per-credential, not per-app.
Background sync — Some cloud apps run a background process that periodically syncs even when the app isn't actively used.

The key difference between on-device and cloud apps from a permissions standpoint: on-device apps only have to be trusted to handle audio locally (which Microphone + Accessibility lets them do); cloud apps have to be trusted to handle audio across the entire network path from your Mac to their servers and back, including everything stored along the way. For HIPAA-bound, attorney-privileged, or otherwise sensitive content, the cloud path is generally only acceptable with a signed Business Associate Agreement or equivalent legal protection. The HHS HIPAA Security Rule provides the formal compliance framework that governs these decisions for healthcare. See our HIPAA speech-to-text guide for the compliance specifics.

macOS permissions audit workflow diagram for voice-to-text apps showing System Settings navigation and cleanup paths

How to Spot a Suspicious Voice-to-Text Permission Request

Red flags to watch for when an app requests permissions:

Full Disk Access requested for "feature compatibility" — never legitimate for voice-to-text
Screen Recording requested for "audio capture" — audio capture only needs Microphone, not Screen Recording
Camera requested for "future features" — never grant speculative permissions; revoke when re-asked specifically
Contacts or Calendar without auto-join feature — only Otter and similar meeting-transcription apps legitimately need these
Network access for an "offline" app — if the marketing says "100% offline" but the app makes network calls, the marketing is misleading
Vague permission descriptions — Apple lets developers write custom strings for permission prompts. "We need this for your experience" is a non-answer; reputable apps explain specifically what each permission does

When in doubt, deny the permission, try to use the app, and see what breaks. If functionality you don't care about breaks, leave the permission denied. If core functionality breaks, you can re-grant it after deciding whether the use case justifies the access.

Voice-to-text app permission evaluation decision tree flowchart showing Full Disk Access Screen Recording Camera red flags versus safe Microphone Accessibility grants on Mac

What If I Already Granted Too Much Access?

If you previously granted broad permissions to a voice-to-text app you no longer trust, the cleanup process:

Open System Settings → Privacy & Security
Click through each category: Microphone, Accessibility, Files & Folders, Full Disk Access, Screen Recording, Camera, Calendar, Contacts, Photos
Find the app in each list
Toggle off any permissions you don't want it to have
The app may prompt to re-grant the next time it needs the permission; deny again if it asks for something inappropriate

For step-by-step screenshots, Apple's own Mac privacy settings guide walks through every category. The Wikipedia entry on TCC covers the technical background for security-curious users. If the app was potentially malicious or you're security-conscious, the more thorough cleanup:

Uninstall the app (drag to Trash, empty Trash)
Delete app data folders: ~/Library/Application Support/AppName/, ~/Library/Caches/com.developer.AppName/, ~/Library/Preferences/com.developer.AppName.plist
Check ~/Library/LaunchAgents/ and ~/Library/LaunchDaemons/ for any leftover launch agents from the app
Restart Mac to clear any in-memory artifacts
If you suspect the app may have accessed credentials, rotate sensitive passwords and API keys

For voice-to-text apps specifically, audio recordings are usually held in RAM and discarded after transcription, so there's no persistent audio artifact to worry about for most apps. But if the app had Full Disk Access, treat the cleanup more seriously — assume any file in your home directory may have been read. For incident-level concerns where you suspect a compromised app may have exfiltrated data, the broader playbook from the NIST Cybersecurity Framework applies: contain (uninstall and revoke), eradicate (delete artifacts), recover (rotate credentials), and learn (audit what other permissions you've granted to similar tools). The CISA personal cybersecurity guidance offers a consumer-friendly version of the same playbook for users who aren't security professionals.

Frequently Asked Questions About Mac Transcription Permissions

❓

What permissions does a voice-to-text app on Mac need?

Exactly two: Microphone (to capture audio) and Accessibility (to paste transcribed text into other apps). These two cover the entire core workflow of a system-wide voice-to-text tool. Anything more — Full Disk Access, Screen Recording, Camera, Contacts — is either a specific feature requirement you should verify or a red flag.

❓

Why does voice-to-text need Accessibility permission?

To simulate a Cmd+V paste keystroke that delivers the transcribed text to your active app. Without Accessibility, the app can transcribe but can't insert text anywhere — you'd manually copy from the app's own window each time. Accessibility doesn't grant access to read your screen or files; it only grants keyboard simulation and UI element role detection for the focused window.

❓

Should I give a voice-to-text app Full Disk Access?

No. Voice-to-text apps never legitimately need Full Disk Access. The permission grants read access to everything in your home directory — SSH keys, browser session cookies, password manager databases, encrypted Time Machine metadata. An app requesting Full Disk Access for voice transcription is either incompetently engineered or actively malicious. Deny it and look for another tool.

❓

Is granting Microphone access dangerous?

Microphone access scope is narrow: the app can only read audio from microphone inputs while it's running. macOS shows a brief indicator in the menu bar when any app uses the mic. The risk is low if you trust the app to handle the audio appropriately (not upload to vendor servers without consent). For on-device tools like MetaWhisp, the audio never leaves your Mac. For cloud tools, you're also trusting the network path.

❓

What does Accessibility permission actually let an app do?

Simulate keyboard input (Cmd+V paste, function keys, character input), read the names and roles of UI elements via the macOS Accessibility API, detect the currently focused app, and register global hotkeys that work in any app. It does NOT grant access to read screen pixels, file contents, network connections, or microphone audio — those are separate permission categories that must be granted independently.

❓

Does MetaWhisp need any unusual permissions?

No. MetaWhisp uses only Microphone and Accessibility — the minimum-permission configuration for a system-wide voice-to-text tool. It does not request Full Disk Access, Screen Recording, Camera, Calendar, Contacts, Photos, or Location. The app's model files and settings live in its own sandbox folder which doesn't require separate permission. Verifiable by running in airplane mode or monitoring with Little Snitch.

❓

How do I revoke permissions from a voice-to-text app?

System Settings → Privacy & Security → click through each category (Microphone, Accessibility, Files & Folders, Full Disk Access, etc.) → find the app → toggle off permissions. The app may prompt to re-grant when it needs a permission; deny again if the request isn't justified. For full cleanup of a no-longer-trusted app, uninstall plus delete ~/Library/Application Support/AppName/ and check ~/Library/LaunchAgents/ for leftover background processes.

❓

Why do cloud-based voice apps have a worse privacy posture?

On-device voice-to-text apps only need to be trusted to handle audio locally (Microphone + Accessibility). Cloud-based apps add the entire network path from your Mac to vendor servers — TLS keys, server-side processing, data retention policies, potential subpoena exposure, vendor staff access. Even with strong vendor practices, the surface area is materially larger. For HIPAA, attorney-privileged, or otherwise sensitive content, on-device is the safer default.

About the Author

Andrew Dyuzhov is the solo founder and CEO of MetaWhisp, a free on-device voice-to-text app for macOS that runs Whisper large-v3-turbo on Apple Neural Engine. He architected MetaWhisp around the minimum-permission constraint (Microphone + Accessibility only, no Full Disk Access, no Screen Recording, no network during transcription) because voice-to-text users in regulated industries can't use tools that require broader access. This article reflects hands-on review of macOS Privacy & Security settings, the Apple developer security documentation, and the permission models used by competing voice-to-text apps on Mac. Connect on X or GitHub.