Apple Says It's Tightening Full Disk Access | Cropsly

Apple says it's tightening Full Disk Access controls on macOS, and the reason is specific: AI agents are scanning file systems in ways the original permission model never anticipated. TechCrunch reported that the changes target the blanket access patterns local agents use to read user data, with new prompts, scoped grants, and audit requirements rolling out across macOS updates.

If you're building on-device agents that touch the file system, this breaks your current architecture. Not in theory. In production.

What Full Disk Access Actually Granted

Full Disk Access was never a sandbox escape. It was a broad entitlement that let signed apps read protected directories: Mail, Messages, Safari data, Contacts, Calendar, and the contents of other apps' containers. You toggled it in System Settings, the user clicked allow, and your process could traverse ~/Library with minimal friction.

That worked when the consumer of that data was a human-operated app. A backup utility reads your Mail folder. A search indexer scans your Documents. The user understands what they authorized because they can see the app doing something legible with the data.

AI agents break that contract. An agent that reads your Messages database to summarize conversations, then sends a compressed representation to a local model or an API endpoint, is doing something the user can't easily audit. Apple's concern is that the permission grant and the data exfiltration happen at different trust boundaries, and the user has no visibility into the second step.

The Redesign That's Now Mandatory

The agents we've built at Cropsly for macOS, including the on-device pipeline behind RunHotel, don't need Full Disk Access for their core function. But several of our /services/ai-agents engagements last year assumed it was available for context gathering. That assumption is now a liability.

The new pattern is scoped access through Security-Scoped Bookmarks and PowerBox-style file dialogs. Instead of requesting Full Disk Access at install time, you ask the user to grant access to specific files or directories when the agent needs them. The system returns a bookmark you can resolve later without re-prompting.

The tradeoff is real. Security-Scoped Bookmarks expire. They're tied to the app's code signature and can invalidate after updates. If your agent persists a bookmark across a version bump, you'll get a nil URL and a permission error on next access. You need to handle that gracefully, re-prompt, and log the failure so your observability pipeline catches it.

For agents that need broad context, like a local RAG pipeline indexing a user's project files, this means you're now managing per-directory grants as a first-class data structure in your agent's state.

What Changes in Your Permission Architecture

Your agent's permission layer can't be a binary toggle anymore. It needs to track which directories are authorized, when authorization was granted, and whether the grant is still valid at runtime.

We've started modeling this as a capability table in the agent's configuration. Each entry maps a scope (directory path or bookmark URL) to an expiration timestamp and a re-prompt policy. When the agent tries to access a path, the capability resolver checks the table first. If the entry is missing or expired, the agent surfaces a permission request to the UI layer instead of crashing or silently failing.

This is more code than a single if hasFullDiskAccess() check. But it's also more honest about what the agent is doing, and it maps cleanly to the audit logs Apple now expects.

The API Contract Shift

The deeper change is in the API contract between your agent and the OS. Full Disk Access was implicit: grant once, read forever. The new model is explicit per-resource, per-session, and potentially per-invocation.

If your agent calls out to a /services/custom-models inference server or a /services/voice-ai pipeline, the data flowing through that contract now needs to carry provenance metadata. Where did this file come from? When was access granted? Is the grant still active?

Without that metadata, you can't build a reliable audit trail. With it, you can answer the question Apple's new controls are really asking: not "can this agent read the file?" but "should this agent have read this file at this moment, and can you prove it?"

Practical Steps for the Transition

Audit every macOS agent you have in production. List which ones request Full Disk Access and which files they actually read. For most agents, the access surface is smaller than the grant implies, and scoped bookmarks will cover the gap.

For agents that genuinely need broad access, like backup or indexing tools, expect to build a permission negotiation flow that explains to the user why the access is needed and what happens to the data. Apple's tighter controls mean the user will see more prompts, and poorly explained prompts get denied.

If you're scoping a new /services/on-device-ai project or planning a migration, our /services/ai-consulting team can help you map the permission model before you write the agent loop. You can also use our /tools/ai-cost-estimator to model the inference budget, and reach out through /contact for a deeper review.

This week, open your macOS agent's entitlements file and check whether com.apple.security.files.user-selected.read-write is set. If your agent relies on Full Disk Access instead of user-selected file access, that's the first thing to fix before Apple's tighter controls hit your release branch.