Apple Tightens macOS 'Full Disk Access' Controls As AI Agents 'Substantially' Increase Risk (techcrunch.com) 51
Apple says it will tighten macOS Full Disk Access controls as increasingly capable AI agents raise the risks of apps gaining broad access to users' files, messages, mail, and browsing history. TechCrunch reports: Days after a journalist claimed that Meta's Muse app on Mac read their private messages -- a claim that Meta disputed -- Apple announced that it's introducing additional controls around a setting called "Full Disk Access" on macOS. The feature was designed to allow backups to function properly, but AI agents have now increased "the risks associated with this level of access," Apple said. [...] In Muse's case, the AI optionally allows users to enable Full Disk Access. This setting, Apple explains, gives an app permission to access files, mail, messages, and even browsing history.
"Some developers are using Full Disk Access in ways that could put users at risk, exposing everything on their systems... without users' full knowledge and understanding," Apple said in a new blog post aimed at developers. The company says that, going forward, it will introduce new controls aimed at ensuring that users who "genuinely wish to grant an app this extraordinary level of access" can do so only with "every explicit user action."
"Addressing this is critical. As AI agents become increasingly capable and autonomous, the risks associated with this level of access will grow substantially. We are committed to ensuring users clearly understand these risks before granting such access, so they can make informed decisions about their own data and privacy," Apple wrote.
"Some developers are using Full Disk Access in ways that could put users at risk, exposing everything on their systems... without users' full knowledge and understanding," Apple said in a new blog post aimed at developers. The company says that, going forward, it will introduce new controls aimed at ensuring that users who "genuinely wish to grant an app this extraordinary level of access" can do so only with "every explicit user action."
"Addressing this is critical. As AI agents become increasingly capable and autonomous, the risks associated with this level of access will grow substantially. We are committed to ensuring users clearly understand these risks before granting such access, so they can make informed decisions about their own data and privacy," Apple wrote.
Correct. And oh, no. (Score:5, Interesting)
But they're right - if you assume that a significant fraction of Mac users are going to install some sort of third-party interface with an LLM, it is either significantly extend and harden the security perimeter deeper into the OS or your customers will routinely have everything exfiled as a matter of course, and it would just be cheaper to make iCloud into an anonymous FTP site.
And given Zuckerbook's demonstrated willingness to brazenly, actively subvert [arstechnica.com] OSes, I'm willing to bet they're going to go Russian on their subjects, er, customers, anyway. ("You probe with bayonets: if you find mush, you push.")
It will probably be what finally pushes me to a Linux laptop, though. I'm old, I spend a lot of time at the shell. I like Macs because they're great unix workstations, still. But I don't see how you can accommodate both people like me and people who need to be protected not only from themselves, but from Zuckerbook and worse.
And they're a much bigger market than people like me. And "AI is the Footure."
Re: (Score:2)
And that's a problem Linux will probably not have.
Re: Correct. And oh, no. (Score:5, Interesting)
Until systemd decides otherwise.
Re: Correct. And oh, no. (Score:3, Interesting)
What if systemd becomes the LLM? Or gets rewritten in an LLM? Or some other way of integrating LLM that Iâ(TM)d not likely think of that only becomes a disappointment when systemd mandates it?
Re: Correct. And oh, no. (Score:3)
Systemd could manage your LLMs like Ollama, because I genuinely don't know where the line is with systemd.
Re: (Score:2)
>Or gets rewritten in an LLM?
It'll get rewritten in rust by an LLM. Then no one will be able to understand the code.
Re:Correct. And oh, no. (Score:4, Interesting)
FWIW, I have two user accounts for different purposes. I once had three, but I stopped doing that one. My main user account has read access to the specialized one, but that one doesn't have any access permissions to the main one. It can be a bit of a nuisance, but it feels (and should be) a lot safer.
Not on macOS (Score:2)
Apple seems to require user to OK agents .... (Score:1)
abulafia says he would not install the LLM, Apple would regardless of the type of user 'harden' the OS.
No, it seems that Apple is requiring the user to explicitly allow agents to have access. For example the new version of Xcode has the ability to be controlled by an AI agent. First time I ran the new version it asked if I wanted to allow agents to use Xcode. The options were always, only when Xcode is already running, never.
Re: (Score:2)
I don't know why you're concerned about what happens to the Mac, the whole Mac vs. windows vs linux/unix workstation has been dead now for some time. We now live in a fully connected world where most users are connected through web browsers and are the intended victims.
And the entire computing model itself in fundamentally broken. We need a model where nothing is permitted except what is explicit based on identifying who you are, an identity that is distributed and internet-based. We've known this has be
Re: (Score:2)
This particular story is an exception to that. Remote software, accessed through a web browser, normally does not have read/write access to your local filesystem. But people are granting local filesystem access to proprietary AI services.
I think that granting such access is .. wow. I wouldn't do it, though I can see how if you use a specialized account for it, and if you're confident that
Re:Correct. And oh, no. (Score:5, Informative)
This looks like the final cell-phonification of the Mac. I'm bummed.
How do you figure that? From the Apple post: "Going forward, we will introduce additional controls to ensure that users who genuinely wish to grant an app this extraordinary level of access can only do so with very explicit user action. "
It's already a OS controlled permission today. You will still be able to enable it for an app if you really want, they just want to make tighten the gate up to make sure you really want to and don't blind-click though. Seems like a reasonable compromise to me.
Re:Correct. And oh, no. (Score:4, Funny)
This looks like the final cell-phonification of the Mac. I'm bummed.
How do you figure that? From the Apple post: "Going forward, we will introduce additional controls to ensure that users who genuinely wish to grant an app this extraordinary level of access can only do so with very explicit user action. "
The word was *every*. *Every* explicit user action.
Oh, bloody hell. I just got rage-baited by incompetent Slashdot editors.
Good night. I'm done for the day.
Re: Correct. And oh, no. (Score:2)
Re: Correct. And oh, no. (Score:2)
Because Apple does not apply these rules to their own apps. The permissions are designed to scare users into thinking something is unsafe, while the Apple-version will do the same things, but run with no restrictions or warnings.
This has been their playbook for years. Whether it's blocking background audio from websites like YouTube so users couldn't effectively use YT Music without Apple grabbing 30% from an app, then one year launching Apple Music.. To preventing third-party Siri co
Re: Correct. And oh, no. (Score:2)
Re: (Score:2)
iPhoneification of Macs has been going on for a long time. For example in older OSX versions I could rip out all of the emojii fonts by simply changing changing their permisisons and deleting them, but that's been impossible to do for years.
Or look at System Settings....that god-awful flat awkward scroll-scroll-scroll-scroll design is straight from IOS.
Re: (Score:2)
This looks like the final cell-phonification of the Mac. I'm bummed.
If this happens, this thirty-year Mac user will be leaving the platform. Full stop. So will just about everyone else within months to single-digit years.
This approach didn't work with Gatekeeper in Mac OS 7. It didn't work for Windows XP. It won't work for modern Mac OS, either. Here's why: CONSTANT PROMPTING MAKES SECURITY WORSE.
Prompting users over and over again to allow or deny actions makes security WORSE. Period. It means that users are constantly being nagged, and constantly having to decide w
Re: (Score:2)
I hereby retract everything I just said. The entire post was based on a misunderstanding caused by Slashdot's editors adding a single extra letter.
What a difference an 'e' makes. I was imagining every single file access causing a UAC dialog.
Yikes.
Well, no, I don't retract the last paragraph. They should still kick Meta's garbage agent off the platform until Meta can get security right.
Re: (Score:2)
Yeah, "very". They're going to make it like sudo where when you give permission to a program to write protected files once it has it forever after.
No, wait, that isn't how it works, is it?
Re: (Score:2)
Yeah, "very". They're going to make it like sudo where when you give permission to a program to write protected files once it has it forever after.
No, wait, that isn't how it works, is it?
That's how it already works. But you can request the permission from the user with a pop-up. Presumably a "very explicit action" means going into the Settings app and turning it on by hand.
But that's going to do exactly nothing. The app will tell them that they have to do this, and the users, having no idea how dangerous it is to give an AI unrestricted access to their device, will do it anyway, and we'll be right back to where we are now. And the next step will be "See, we can't allow full disk access."
Re: (Score:2)
Oh, also, each agent runner should have:
But this is the trivial part.
Re: (Score:2)
It's not. Full disk access is sticky. When you grant it, the app has it until you go into settings and revoke it. It's not like sudo, it's like running that app as root, with no permission required after the first time. On Linux to get the same effect you have to edit a text file with root permissions and give the program passwordless sudo privileges, which should make any competent Linux users' hair stand on end.
Re: (Score:2)
It's not. Full disk access is sticky. When you grant it, the app has it until you go into settings and revoke it.
You're interpreting it in the context of typing "sudo" on the command-line granting a one-time permission. And the original statement from Apple (after correcting the "every -> very" error in the summary) makes it clear that this is *not* what is being proposed, so if that was the original poster's intent, then it was incorrect.
The way I interpreted the original sentence — "They're going to make it like sudo where when you give permission to a program to write protected files once it has it foreve
Re: Correct. And oh, no. (Score:1)
Iâ(TM)m old and not worried about giving up MacOS over this. Apple will add a cryptic CLI method for disabling this that normies wonâ(TM)t have a clue how to do themselves. As always, Iâ(TM)ll do whatever I want with my Macs and my kid wonâ(TM)t have a clue how to fuck up hers.
Re: (Score:2)
Yeah, because Linux totally doesn't have any files or folders that you have to give special permission for programs to alter.
Re: (Score:2)
Watch for it in the mail.
Sounds like more granularity options ... (Score:1)
This looks like the final cell-phonification of the Mac. I'm bummed.
Don't worry, it's not. MacOS already requires that a user give explicit permission to an app that wants full disk access. It kind of sounds like Apple is going to have greater granularity than the current options of your app's writable folder and everything.
LOL wut? (Score:3)
"As AI agents become increasingly capable and autonomous..."
The literal definition of an AI agent is software that is fully autonomous, an AI agent cannot "become increasingly autonomous".
No user should ever install software like this for any reason. The greater concern is how vendors will sneak this garbage onto systems despite users' best efforts.
Re: (Score:3)
AI agents have different level of access. You can of course give it automatic access and let it delete all your files if it needs more disk space, but you can also have it ask you for every action, for not whitelisted actions, or restrict which files it can access. Different software implements different controls, but most have a "YOLO" mode and a more sane mode that doesn't allow it to delete your hard drive without asking.
Re: LOL wut? (Score:2)
Re: (Score:2)
There's also nothing about "AI agent" that says "fully autonomous" but that shouldn't get in the way of wild speculation and some good pedantism.
Re: (Score:2)
Good pedantism is correct and elucidating. This is someone pretending to be pedantic.
Re: (Score:2)
Excellent pedantism sir!
Re: LOL wut? (Score:2)
The literal definition of an AI agent is software that is fully autonomous, an AI agent cannot "become increasingly autonomous".
What?? No it isn't. Yes they can.
You can remotely use them exactly the same way you'd use one locally, prompt it and it does things for a bit, like you drive the agent on your Mac from your phone. You can also schedule prompts to run, or you can have some event driven setups. There's a wide variety of modes with different event types and schedule frequencies.
Autonomy never was black and white, it still isn't. Besides that misunderstanding, they're still gaining capabilities too, like driving gui apps, and p
Missing the obvious solution (Score:3)
I feel like these AI processes should be launched as a separate unprivileged user and group. Only when you change the file permissions should they be able to access your files. This avoids possible flaws in agent interfaces and hands off the responsibility to the OS. Why are simple solutions like this so hard to grasp?
Re: (Score:2)
Why are simple solutions like this so hard to grasp?
Because not every (many!) MAC user understands the problem.
Re: Missing the obvious solution (Score:2)
Sometimes we run agents in containers, and sometimes that's super inconvenient.
It's not a bad idea to make a separate local account though, and use a git remote for coordination like you would with a coworker. Even with that I'm still going to use AI from my own account while I'm working there though. There's really no excuse not to have strong sandboxing for processes inside an account.
Re: (Score:2)
It's hard to grasp because Susan From Accounting doesn't have any conception of access control. It is easier, maybe even faster, for her to click "Allow" on the admin elevation prompt, or whatever it is, rather than learning about the architecture of multi-user OSes.
Sandbox/containers (Score:2)
Re: Sandbox/containers (Score:2)
Yup and you can tap a button to use a cloud instance in ChatGPT/Codex, it's built right in. Setup GitHub once and do interesting things from a remote container.
People still need to use agents with their local files. It's the system you're working from, and unless everything you do is software development shaped and on a git server then the agent would probably need access to your local environment for you to do anything with it.
Y'know what ELSE Apple could do? (Score:1)
If they were really, truly concerned about protecting me from rogue AI?
They could allow me not to have to jam their own AI down my throat for the crime of installing macOS 27. #donotwant but that doesn't have any pull at Apple. Resistance is futile.
AFTER you have the forced march to install their AI in macOS 27, you then have to download gigs and gigs of additional unwanted shit.
Jeebus I wish I could go to sleep and wake up about a decade ago.