"Hear everything I say, and be able to type into every app I use." Read that back and notice it's the spec for both a dictation tool and a keylogger.
The Ask
Firekeeper needs two permissions that should make a thoughtful user pause. Microphone — it can hear you. Accessibility — it can read the focused element in other apps and act on them. Every dictation app needs exactly these, and so does malware. There is no clever architecture that removes the need; a tool that types what you say must be able to hear and to type. What you can control is asking for nothing beyond that, and behaving in a way that justifies the grant.
The Permission Surface Is a Design Output
Microphone REQUIRED -- it has to hear you
Accessibility REQUIRED -- selection, target context, robust insertion
Input Monitoring AVOIDED -- design chose flagsChanged over an event tap
Automation AVOIDED -- no AppleScript unless one app profile demands it
Network SCOPED -- only the provider you selected, never by default
Notice Input Monitoring is avoided, not accepted as a cost of doing business. That's the earlier hotkey decision paying a dividend here: because activation observes modifier flags instead of intercepting the event stream, the app never has to ask "can I watch every keystroke?" Permission surface isn't fixed by your feature list — it's an output of your architecture, and you can design it down.
Ask Honestly, and Early
Two habits make the ask fair. First, request the microphone at launch rather than ambushing the user mid-dictation — a permission prompt firing the instant you start talking is both startling and guarantees you miss the first words. Second, make the state legible: a Setup panel showing live permission status with buttons that open the right System Settings pane, so the user always knows what they've granted and can revoke it. An app that's cagey about what it holds has already lost the argument that it deserves to hold it.