What a Permission Prompt Actually Grants

A permission prompt grants a capability, not a purpose. When you tap Allow on microphone access, the operating system stops blocking that app from opening the microphone — it does not record what the app then chooses to do with it, and it does not hold the app to the reason given in the prompt. The sentence explaining why the app wants access is written by the developer, and nothing in the system checks it against behaviour.

That gap is the single most useful thing to understand about installing an AI companion app on a phone you also use for everything else.

The prompt is a switch, and the explanation is marketing

Modern mobile platforms gate a fixed list of sensitive capabilities behind a user tap: microphone, camera, photo library, contacts, calendar, precise location, notifications, local network, health data, and a few others. The prompt you see has two parts. The buttons come from the operating system and are enforced. The line of text above them comes from the app’s own manifest and is enforced by nobody.

Read the explanation as a claim, not a constraint. “Microphone access is used for voice chat” tells you what the developer says the feature is for. Once granted, the same switch covers any use of the microphone while the app’s rules allow it — a different feature next release, an always-listening mode added later, an analytics library that samples audio levels. None of that requires a fresh prompt, because the capability has already been granted.

This is not an accusation about any particular app. It is a description of how the permission model works, and it is why the interesting question is never “does this app deserve access” but “what would this app be able to do if I stopped trusting it tomorrow”.

What each capability actually reaches

The capabilities that matter most for a conversational app are broader than their names suggest.

Microphone covers everything the microphone can hear, which includes the room, not just your voice. There is no platform notion of “only speech directed at the app”.

Photo library is the one where the platforms diverge most. Some versions grant access to the whole library at once; some let you hand over a specific selection, so the app receives only the images you picked and cannot enumerate the rest. If your phone offers the selected-photos option, it is almost always the right choice for a chat app, because a companion app has no reason to browse.

Contacts is worth refusing almost reflexively. A conversational app rarely needs your address book, and the address book is other people’s data, not only yours — names, numbers, relationships, sometimes addresses and birthdays. Granting it makes a decision on behalf of everyone in it.

Notifications looks harmless and is not a data capability at all, but it changes what your phone displays on a locked screen. That is a separate surface with its own tradeoffs, covered in notification previews and your lock screen.

Local network access, which some apps request for device discovery, is unusual in a chat app and worth a second look if you see it.

The permissions that are never prompted

The most misread part of the model is what does not generate a prompt. A prompt exists only where a platform decided one should. Everything else is available to any installed app by default.

An app can generally see, without asking: your device model and operating system version, your language and region settings, your time zone, your screen dimensions, your network type, and the IP address every request arrives from. It can time how long you spend on a screen, count how often you open it, and record which buttons you press. It can generate a stable identifier for your install and use it to join sessions together.

None of that is a loophole — it is the default surface of installing software. It is also enough to infer a great deal, which is why “we only collect data you explicitly provide” is a claim about one category and not about the whole picture. Your approximate location, for instance, does not require the location permission at all; see location without the location permission.

Grant late, grant narrow, and check afterwards

Permissions are not a one-time decision, and treating them as reversible is the practical move.

Decline first, and let the feature ask. If you deny microphone access at install and later want voice, the app will prompt again when you tap the voice button. Denying costs you nothing except a second tap later, and it means you only grant capabilities to features you actually use.

Choose the narrow variant when one exists. Selected photos instead of full library. Approximate location instead of precise. Notifications without previews. The narrow options exist because platforms added them under pressure, and they are usually one screen deeper than the default.

Revoke without uninstalling. Every mobile platform has a per-app permission screen in Settings where you can turn a capability off after the fact. Well-built apps degrade gracefully; badly built ones break or nag. Either result tells you something.

Then verify with the platform’s own log. Both major platforms now record when an app actually used a sensitive capability, which is a much better source than the app’s description of itself. Reading that log is its own small skill, covered in reading your phone’s privacy dashboard.

What this does not tell you

Permissions govern what an app can reach on your device. They say nothing about what happens to the data after it leaves. A companion app with no permissions granted at all still receives every message you type, because typing into a text box is not a permission — it is the product. The keyboard you type with is a separate actor again, discussed in what your keyboard can see.

So permission hygiene is a floor, not a strategy. It limits collateral collection — the room audio, the photo library, the address book — and it is genuinely worth doing. It does not limit the core of what you have chosen to share, and no setting on your phone will.