AI Assistants Want OS Privileges

Update: Apple says Full Disk Access is too broad for agents

Apple just confirmed the central argument of this article.

On October 2, the company published a short developer notice called "Updates to Full Disk Access in macOS".

It is four paragraphs long.

It is also a fairly large concession.

Apple says Full Disk Access was created largely so backup apps could work. It lets software sidestep normal controls and reach data across the Mac. According to Apple, some developers now use that permission in ways that can expose files, mail, messages, and browsing history without users fully understanding what they granted.

Then Apple names the thing that changes the stakes:

Agents.

As software becomes more capable and autonomous, Apple says the risk grows substantially. The company plans to change macOS so this level of access can only be granted through "very explicit user action."

Good.

But that is a direction, not yet a security architecture.

Apple did not announce which macOS release will contain the change. It did not explain whether access will become more granular, how long grants will last, what users will be able to revoke, or whether agents will receive a new API designed around individual tasks.

So the important question is not whether the permission dialog becomes harder to click.

It is whether Full Disk Access remains the permission at all.

A scarier dialog is not the fix

Explicit consent is better than accidental consent.

It still does not solve the agent problem.

Full Disk Access is an app-wide, ambient permission. Once granted, it can outlive the specific reason the user had in mind. An agent may later receive new prompts, open new tools, encounter hostile content, or interpret an ambiguous instruction in a way nobody anticipated when the checkbox was approved.

Consent at installation is not consent to every future agent decision.

Apple already has a better pattern elsewhere in macOS. For sandboxed apps, its file-access model can let a user choose a specific file or folder and grant read-only or read-write access to that selected resource.

That is much closer to what agents need.

Not:

"Trust this app with the computer."

But:

"Let this agent read this folder for this task, until this task ends."

The distinction sounds small.

It is the entire product.

The Messages plugin is now the obvious test

The Apple Messages plugin described below makes the tension concrete.

OpenAI says the plugin works locally and asks for review before sending by default. TechCrunch reported that setup requires Full Disk Access. None of that means OpenAI misused the permission.

It means the operating system gave a focused feature a very broad key.

Reuters connected Apple's announcement to complaints about Meta's Muse accessing private messages; Meta disputed that account. We do not need to settle that dispute to see the platform problem.

If a useful assistant needs one of the Mac's broadest permissions to search messages, the permission model is carrying more risk than the feature actually requires.

Apple's notice also raises a less discussed point: communication data belongs to more than one person. Giving an assistant access to your messages can expose the words, identities, and context of people who never clicked the permission dialog.

The user's consent matters.

It is not the only privacy interest in the room.

What agent permissions should look like

An agent-native permission model should be boringly specific.

• Resource-scoped: one conversation, folder, calendar, or account instead of the entire disk.
• Action-scoped: reading and searching should not automatically include writing, sending, deleting, or changing settings.
• Just in time: ask when the task needs access, not during setup when the future use is abstract.
• Time-limited: expire the grant after the task, session, or a clearly stated period.
• Attributable: show which agent, tool, and instruction caused the access.
• Auditable: let the user see what was read or changed and why.
• Revocable: make access easy to remove without uninstalling the product or hunting through several settings panels.

And the rules should apply to Apple as well as third parties.

That last part matters because security and competition are now tangled together. Apple can be completely right that agent access needs stronger controls while also benefiting from a system where rivals depend on permissions Apple defines.

The answer is not universal access for everyone.

It is a common set of narrow, well-instrumented capabilities that Apple and competing assistants must use on equal terms.

Europe's interoperability fight, discussed in the original article below, makes more sense through that lens. "Open the platform" should not mean giving every assistant a master key. It should mean exposing the useful system actions through permissions designed for the actual job.

The real lesson

Full Disk Access is a compatibility escape hatch built for software such as backup tools.

It is not a native capability model for autonomous agents.

Apple's announcement is welcome because it recognizes that autonomy changes the risk. A more deliberate grant can stop some users from approving a dangerous permission casually.

But a harder click is transitional.

The operating system has to become the permission broker between the user's intent and the agent's next action.

The agent should ask for the file.

Not the computer.

The Short Version

The AI assistant war is becoming an operating-system fight.

Not someday.

Now.

On July 16, the European Commission adopted legally binding measures under the Digital Markets Act that tell Google how it must open parts of Android and Google Search to rivals. One part covers Android interoperability for AI assistants. The other covers access to ranking, query, click, and view data from Google Search.

That sounds like Brussels paperwork.

It is actually a product map.

The Commission says Android is used by more than 60% of mobile users in the EU. It says third-party AI services need access to Android features such as voice commands, actions across apps, live translation, speech-to-text, reply suggestions, and contextual information like a recently visited place.

In plain English:

If Gemini can live deep inside Android, rivals should not be stuck at app level forever.

That is the story.

AI assistants are not just chatbots with nicer voices. To be useful, they need operating-system privileges: wake words, notifications, app intents, local files, screen context, browser state, calendars, messages, maps, payments, and a way to act across the phone without feeling like a web page trapped in a rectangle.

The model matters.

The OS decides what the model can touch.

And once the assistant can touch things, the platform owner suddenly has enormous power.

Very normal future. The default assistant setting is now industrial policy.

Update: Messages is the OS-privilege test

One month later, OpenAI has made the argument less abstract.

On August 20, OpenAI shipped an Apple Messages plugin for the ChatGPT desktop app on macOS. The plugin can read and search Messages chats on a Mac, draft replies, and send messages through Apple's Messages app. It works in ChatGPT Work and Codex, and OpenAI says it is available on all plans in the macOS desktop app.

That sounds like a small feature.

It is not.

Messages are not just another data source.

They are the user's social graph, plans, reminders, emotional context, obligations, little lies, old receipts, half-decisions, running jokes, logistics, and "wait, what did I promise them?" memory.

An assistant that can search messages is not just answering from documents.

An assistant that can send messages is not just writing text.

It is reaching into one of the most intimate action surfaces on the computer.

This is exactly what I meant by OS privileges.

The permission model is the product now

OpenAI's own plugin guide is careful about the boundary.

The Apple Messages plugin only works in Codex and ChatGPT Work, not ordinary ChatGPT chats. For this release it only works in the Apple Silicon build of the macOS desktop app, and it is not available on web, mobile, Codex CLI, or the IDE extension. Users have to grant macOS permissions before ChatGPT can read Messages. By default, ChatGPT asks the user to review the message and recipients before sending.

Good.

Also: look at how much product design is hiding inside that paragraph.

Which surface can use the plugin?

Which device architecture?

Which macOS permissions?

Which chat mode?

Which send approvals?

Can a workspace admin disable it?

What happens when persistent approval is turned on?

OpenAI's guide warns that persistent approval removes the user's final review before ChatGPT sends a message as them. It also notes a known issue where tasks that disable approval prompts may be unable to show the confirmation needed to send.

That is the story.

Not "AI can text now."

"The assistant's usefulness depends on an approval model fragile enough that the docs have to explain where it breaks."

This is not a criticism. It is what real agent products look like.

Once the assistant can act in personal software, the product is no longer only the model or the prompt box. It is the permission boundary, the revocation path, the admin control, the local-versus-cloud data rule, and the final human checkpoint before the message leaves your machine.

TechCrunch reported that OpenAI said the plugin does not create a full index of the user's messages, runs locally on the device, and stores message content locally unless the user chooses cloud conversation storage. The same report also noted that setup requires Full Disk Access.

That is the tradeoff in one sentence:

To make an assistant useful, you give it a terrifyingly useful permission.

Apple still has the easiest version

The funny part is that this is also an Apple story.

OpenAI can integrate with Messages on the Mac by going through the permissions and automation paths macOS exposes. That matters. It gives ChatGPT a route into a native Apple communication surface without becoming Siri.

But it is still not the same thing as owning the OS.

It does not work on iPhone, where most people actually live inside Messages. It does not become the default assistant. It cannot redesign the system permission model. It cannot decide how every app exposes intents. It cannot quietly sit next to every notification unless the platform allows that.

So the plugin proves both sides of the assistant war.

Rival assistants can sometimes reach deep surfaces through plugins, permissions, and desktop automation.

Platform owners still decide where the deepest surfaces are, how stable they are, and whether they exist on the devices that matter most.

That is why the assistant fight keeps turning into an OS fight.

Model quality gets you the draft.

Operating-system access decides whether you can send it.

What Europe is actually forcing

The Commission is not saying "make Android open, vibes-wise."

It is specifying categories of access.

For Android, Google must give third-party AI service providers effective interoperability with key Android features. The Commission's Q&A says the measures cover eleven features, including voice commands, actions within and across apps, live translation, speech-to-text, and contextual suggestions.

Those are not decorative features.

They are the difference between:

"Open this app and ask the chatbot."

And:

"Hey assistant, answer this message, book the ride, translate the call, summarize what I am looking at, and do the next step in the app I already have open."

That second version is the product people actually want.

The Search side matters too. The Commission says Google must give eligible search services, including AI chatbots, access to certain ranking, query, click, and view data. The idea is to let rivals improve their own search and AI-search products without needing to recreate Google's behavioral data advantage from scratch.

That is a big deal.

Search data is not just an old internet asset.

It is training signal, ranking signal, intent signal, freshness signal, and product-distribution signal. In an AI assistant world, search becomes less like a page of links and more like a task substrate. The assistant needs to know what people ask, what they click, what they ignore, and which answers actually help.

No wonder Google is unhappy.

Google's response argues that the decisions risk privacy, security, and product quality. It says forced data sharing and interoperability can expose users to new risks and weaken safeguards.

Some of that is self-interested.

Some of it is also true.

Opening agent-level access to a phone is not like opening a weather API.

It is closer to deciding who gets keys to the building.

The assistant is not an app anymore

This is the mental shift.

Most AI companies still talk like the assistant is a destination.

Open ChatGPT.

Open Claude.

Open Gemini.

Ask the thing.

That is useful, but it is not the endgame.

The endgame is the assistant as a layer over the user's digital life.

That means the assistant has to operate where the user already is. It needs to understand the message on screen, the page in the browser, the meeting on the calendar, the route in Maps, the photo the user just took, the app that is currently active, the file the user is editing, and the notification that arrived thirty seconds ago.

An app can ask for permissions.

An operating system can orchestrate context.

That is why Google and Apple have an advantage.

Gemini can become part of Android. Siri can become part of iOS. Microsoft can push Copilot through Windows. Google can connect Gemini to Search, Chrome, Android, Gmail, Docs, Maps, and YouTube. Apple can connect Siri to local device context, privacy controls, sensors, and app intents.

A rival assistant can be smarter and still feel worse if it cannot reach the right surface at the right time.

That is the uncomfortable product truth.

Model quality gets you into the conversation.

OS access lets you do the job.

Apple is the shadow story

The Google ruling lands at an awkward moment because Apple has been saying a similar thing from the other side.

Apple says some of its new Siri AI features will not initially launch in the EU because of DMA concerns. The company has argued that the law's interoperability requirements could force it to compromise privacy and security.

Again, there is strategy in that answer.

Apple does not want regulators telling it how to expose deep iOS capabilities.

But the tension is real.

An assistant that can read your screen, take actions in apps, understand personal context, and move across services is powerful because it is intimate. The same access that makes the assistant useful also makes it dangerous if the wrong actor gets it, if permissions are unclear, if logs are weak, or if the model follows the wrong instruction.

That is exactly why the GPT-Red story matters, but from a different angle.

That story was about testing agents before the internet attacks them.

This one is about where those agents are allowed to live.

The deeper the assistant goes into the OS, the more the security model becomes the product.

Europe is effectively saying:

"You cannot reserve the useful hooks for your own assistant forever."

Google and Apple are effectively saying:

"If you force those hooks open, you had better accept the security consequences."

Both sides have a point.

Annoying, but true.

This is not just about Google Search

It is tempting to treat the Search-data part as an old antitrust fight with AI seasoning.

That misses the shift.

Search data is becoming assistant fuel.

If an AI assistant is going to answer questions, recommend actions, compare products, summarize current events, route users to services, and maybe complete tasks directly, then search is no longer just a results page.

Search becomes one of the assistant's senses.

Google's advantage is not only that it has a search engine. It has decades of query behavior, ranking feedback, freshness signals, spam knowledge, local intent, shopping patterns, and the muscle memory of users asking Google first.

AI search rivals want that signal.

Regulators see that signal as a moat.

Google sees that signal as its product, its privacy obligation, and its competitive edge.

All three can be true.

The hard part is that "share search data" sounds simple until you ask:

• Which data?
• How fresh?
• At what granularity?
• With what anonymization?
• For which competitors?
• Under what security rules?
• Can the data be used to train models?
• Can Google protect users from re-identification?
• Can rivals build anything meaningful if the data is too aggregated?

This is not a clean open-data story.

It is the messy beginning of AI-search infrastructure regulation.

Very relaxing.

The platform owner has the easiest agent

The simplest way to understand the fight is this:

The best AI assistant is probably the one closest to the user's real context.

That creates a platform-owner problem.

If Google controls Android, Google can make Gemini feel native. If Apple controls iOS, Apple can make Siri feel native. If Microsoft controls Windows, Microsoft can make Copilot feel native. Everyone else has to ask permission.

That permission can be technical.

It can be commercial.

It can be buried in APIs.

It can be shaped by privacy rules, app-store review, background-execution limits, browser defaults, notification policies, file access, local model APIs, voice invocation, and a thousand small decisions that never look like "AI competition" until the assistant cannot do the thing.

This is where regulation becomes product design.

The DMA is not training a model.

It is deciding which model gets to stand near the user's digital nervous system.

That is why this story matters more than a normal platform fight.

If agents become the interface, platform defaults become agent defaults.

And agent defaults are going to be extremely valuable.

What builders should take from this

If you are building an assistant, do not think only in terms of model capability.

Think in terms of reachable surfaces.

Can your assistant be invoked at the right moment?

Can it see the right context?

Can it act in the right app?

Can it explain which permission it needs?

Can it operate without asking for the entire phone?

Can it read a thread without indexing a life?

Can it send a message without making "always allow" the lazy path?

Can the user revoke access cleanly?

Can an admin disable the risky surface without breaking the rest of the workflow?

Can another app trust its action?

Can a regulator understand the control?

Those questions are now part of the product.

If you are a platform owner, the lesson is harsher:

Your AI assistant APIs are not just developer features.

They are competition policy, security architecture, and distribution strategy at the same time.

That is an awful combination.

It is also the real job.

The next assistant war will not be won only by the model that answers best in a blank chat.

It will be won by the system that can safely stand closest to the user's real life.

Europe just reminded Google that "closest" is not supposed to mean "only ours."

The rest of the industry should pay attention.

The AI assistant is becoming the operating system's most important guest.

And guests, apparently, now require regulatory architecture.