AI Agents Development Company: Apple's FDA Shift

What did Apple change about Full Disk Access?

Apple said it is changing macOS privacy settings so users clearly understand the risks before granting Full Disk Access (FDA). Any AI agents development company building desktop assistants should take note. Its developer announcement names no app and, in the coverage we reviewed, gives no technical detail.

The stated reason is direct. Apple wrote that some developers use FDA in ways that expose "files, mail, messages, and even browsing history" without users' full knowledge, and that for communication apps this can compromise the privacy of the people on the other end of a conversation.

Apple also said that as AI agents become more capable and autonomous, the risks of this level of access will "grow substantially". Ars Technica's report is the source for the sequence of events below. We are writing from the public record, not from inside any of these companies.

Why did the Meta Muse incident matter?

A columnist said Meta's Muse agent sent an unsolicited notification referencing a private Messages thread, even though they had never knowingly granted that access. The dispute turned on what "opt in" really means for a system-level permission.

Columnist Jason Aten described the incident in Inc. Meta's CTO replied that Muse reads Messages only if macOS Full Disk Access is granted and a Messages connector is enabled.

Security researcher Patrick Wardle questioned that framing. His point: with FDA, any non-root file is readable, so an app-level connector toggle is a UI preference, not an enforcement boundary. Meta only repeated its original statement when asked. That gap, between a product toggle and what the operating system actually allows, is the lesson for anyone building agents.

What does Full Disk Access actually expose?

FDA exposes everything a non-root process could read: chats, mail, browser history and cookies. It does not distinguish between the three files an agent needs and the three thousand it does not.

Wardle's description, quoted in the Ars report, lists "browsing history, browser cookies, chats, etc etc etc." Once the grant exists, the only thing limiting the agent is its own code and its own prompt.

That is a weak control. Prompts drift, models change, and a connector that is "off" in settings may still sit behind a process that can open the file. For a buyer reviewing a vendor, the question to ask is not whether a feature is opt in. Ask what the process can read when every toggle is off.

How should an AI agents development company scope permissions?

Scope each data source as its own grant, enforced outside the model. If a feature needs one mailbox folder, give it a token for that folder, not a disk-wide permission.

At Viithiisys, which has shipped software since 2007, we treat agent access the way we treat service accounts in any production system. Each connector gets a least-privilege credential, a named owner and a read log. The model never holds the credential; a thin tool layer does, and the tool layer refuses out-of-scope requests whatever the prompt says.

The trade-off is real. Narrow grants mean more setup, more consent screens and some features that feel slower than a single broad permission. You accept that friction deliberately, because the alternative is an agent whose reach nobody can state in one sentence.

Which permission models can an agent use?

There are four common models, and they differ sharply in blast radius. Each is described below by what the agent can reach, what enforces the limit and how it fails.

• System-wide grant (such as FDA).
• Reach: nearly every non-root file.
• Limit: only the app's own code.
• Failure: a bug or injected instruction reads anything.
• App-level toggle on top of a system grant.
• Reach: the same files as above.
• Limit: a UI setting.
• Failure: the toggle is not an OS boundary.
• Per-source API or connector token.
• Reach: one service, within one scope.
• Limit: enforced by the service provider.
• Failure: token theft within that scope.
• Sandboxed process with brokered access.
• Reach: only what a broker passes in.
• Limit: the OS sandbox plus the broker.
• Failure: more engineering effort up front.

Apple documents the App Sandbox for the last pattern. For most agent products, the per-source token and the sandboxed broker are the defensible choices.

What fails when an agent holds broad access?

The agent becomes a target. Anyone who can influence its input, or take control of it, inherits everything it can read.

Ars reported that Wardle disclosed a Muse configuration that let any app or code on a Mac, including commands injected through ClickFix attacks, take full control of the assistant. From there an attacker could reach the same resources Muse could.

This is the failure mode we plan for in any agentic build: not the agent misbehaving on its own, but someone else steering it. Broad access turns a prompt injection from an annoyance into a data breach.

How do you test an agent's permission boundary?

Seed a sandbox account with canary data in every source the agent should not touch, run realistic tasks, then search logs and outputs for any trace of those canaries. A single hit means the boundary leaks.

Test three paths. First, normal use with every connector disabled. Second, adversarial input: instructions hidden in an email, a calendar invite or a web page. Third, regression after each model, prompt or connector change, since behaviour shifts without any code diff.

This is ordinary QA and testing work applied to a new surface, and it is cheap compared with explaining an unsolicited notification to a customer. It also produces evidence: a dated test log that a security reviewer or regulated client can inspect.

Does this matter beyond macOS desktop apps?

Yes, as a design principle, though Apple's announcement concerns macOS only. Mobile platforms already use per-app sandboxing, so the same mistake shows up there as over-broad OAuth scopes and connectors instead.

If you build a mobile app with an embedded agent, or a web application that connects to a user's mailbox, the question is identical: what is the narrowest scope that makes the feature work?

Any mobile application development company or web development company building agent features should be able to answer that per feature. The stakes rise in regulated work. A healthcare software development company handling patient messages cannot treat "the user toggled it on" as sufficient consent, because the other people in those threads never agreed to anything.

When should you hire an AI agents development company?

Bring one in when the agent will touch sensitive data, when you lack someone who has shipped production agent systems, or when you need a permission model reviewed before launch.

Viithiisys has delivered 500+ projects for clients in six countries. They include Paytm, Snapdeal, IKEA, Nestle, Shiprocket and Vikram Solar. Our engineering is in Mohali, with an office in Markham, Ontario. You can check the details in our case studies.

As a software development company, our AI agent development work starts from the permission model, not the prompt. For a bounded first release, we deliver a working MVP in 30 days against a fixed scope.

If your agent idea touches a workflow where data access is unclear, start with the broken workflow assessment. If you already have a build in flight and want a second opinion on its permissions, contact us and we will scope the review after a discovery call.