The problem is that Apple only enforces TCC permissions on the root of the process tree.

So, for example, if your backup software is a CLI, you have to give Full Disk Access permissions to your Terminal, not the backup software. And subsequently every other process you start from your terminal will also have Full Disk Access.

Enforcing it per executable down the process hierarchy isn't helpful either: you'll eventually grant it to an interpreter (zsh, python3) and create a hole.

TCC's security model is fundamentally wrong.

Unix solved this decades ago: agents should be their own user. What's missing is the tooling to make disposable users practical, and perhaps cross-platform filesystem ACLs.

> Social media last week blew up with masses of people who agreed and said the incident showed that AI assistants given access to calendars, emails, messages, shopping accounts, and other resources are akin to a skill saw or other power tool. While potentially useful, they can do real damage if not used carefully.

This brought to mind Neal Stephenson's essay "Unix - The Hole Hawg of Operating Systems" from back in the day (1999):

> I myself used a Hole Hawg to drill many holes through studs, which it did as a blender chops cabbage. I also used it to cut a few six-inch-diameter holes through an old lath-and-plaster ceiling. I chucked in a new hole saw, went up to the second story, reached down between the newly installed floor joists, and began to cut through the first-floor ceiling below. Where my homeowner's drill had labored and whined to spin the huge bit around, and had stalled at the slightest obstruction, the Hole Hawg rotated with the stupid consistency of a spinning planet. When the hole saw seized up, the Hole Hawg spun itself and me around, and crushed one of my hands between the steel pipe handle and a joist, producing a few lacerations, each surrounded by a wide corona of deeply bruised flesh. It also bent the hole saw itself, though not so badly that I couldn't use it. After a few such run-ins, when I got ready to use the Hole Hawg my heart actually began to pound with atavistic terror.

> But I never blamed the Hole Hawg; I blamed myself. The Hole Hawg is dangerous because it does exactly what you tell it to. It is not bound by the physical limitations that are inherent in a cheap drill, and neither is it limited by safety interlocks that might be built into a homeowner's product by a liability-conscious manufacturer. The danger lies not in the machine itself but in the user's failure to envision the full consequences of the instructions he gives to it.

* http://www.team.net/mjb/hawg.html

* 2021: https://news.ycombinator.com/item?id=28015229

FDA is in fact not required for backup software nor should it be. For example, Bombich is granted the com.apple.security.files.all entitlement for Carbon Copy Cloner, because backup software needs to just work without the user chancing a miss on the TCC prompt when they first set it up only to find out the app didn't backup their photos after losing all their data.

Apple stopped adding protected file-system domains for some reason, and have only expanded TCC to entail more vague and nonsense monikers. Sandboxed apps of importance like Messages, Notes, Reminders, and so on, all just end up under the "Full Disk Access" umbrella because they all store their databases in ~/Library/Containers, and FDA is really the only thing gating access to that. Apple should just start pushing the permissions one level down into that folder. Do I want to give an agent access to my Safari history, but not my messages? Too fuckin bad! No way to slice that right now, it gets full disk access and can access anything.

Counterpoint:

https://pxlnv.com/blog/macos-full-disk-access-restrictions/

> ...the uses of Full Disk Access go well beyond the category of backup apps, and it is worrisome to see Apple give it such a limited frame. I have given that permission to disk management utilities, Sketch, Terminal, and other apps I do not want to be throwing permissions requests as I move around my drives. Is Apple suggesting this capability could be limited in the future to backup applications alone? I do not like that.

If Full Disk Access were, in future, to be something that I could not grant to (for instance) the Terminal, because it is not a backup app, that would severely limit my ability to do work on a Mac, both as hobbyist and as computer professional.

I agree that the agent situation is a fairly serious concern; I just don't want to see Apple throw the baby out with the proverbial bathwater.

I think that was the initial concept of what "Full Disk Access" was supposed to be, but I've run into needing to give some of my own apps full disk access for very innocuous reasons. Recently, I wanted to build a little app to give me a Time Machine on/off switch by calling "tmutil enable/disable". A single on/off command with no need to access any of my data, but its use was gated behind needing Full Disk Access. Hopefully if Apple is rethinking Full Disk Access permissions they will rethink better ways to provide these sort of permissions.

Why is anybody surprised with meta ? Seriously, you guys ignore all the news about that company and privacy for last 2 decades? Privacy for them is an obstacle to engineer around and nothing more, and this is baked to the core of their philosophy, not some rogue fringe team pursuing results at all costs for past 3 months.

There was a time I had their FB app and messenger on the phone. Then it was found out that their crappy engineering couldn't hide the fact their apps were constantly watching users and other apps on entire phone, causing >15% additional battery drain, even when they were not opened.

I've removed all of them, never needed them on phone (or at all) and can't complain at all. Don't expect privacy form meta, any, ever.

The problem I have is that when I ssh into my mac, I want to be able to control software from the command line and having a popup authorization window that just halts the software being controlled is not good for me. I'm okay with having the authorization, but they need to make it visible to ssh users when ssh'ing in.

Another case of "This is why we can't have nice things." Application developers who feel entitled to accessing everything they can on the user's computer, without obtaining consent from the user. So, now we have to have these consent walls everywhere. Way to go, application developers.

Watch them advertise that Muse will soon be able to do phone backups for you to justify this permission usage

According to haveibeenpwnd, the email address I've used since gmail was invite-only is in at least 39 data breaches.

In 2019, my SSN was used to purchase 4 iPhones, open 2 credit cards, and used to buy perfume in another state.

In 2026, almost mainstream messaging app monitors your private messages (yes, even Whatsapp now [0]).

Society decided that to be in it, you must give up your privacy along time ago.

[0] - https://engineering.fb.com/2026/08/12/security/how-were-buil...

It's an exciting time to be in security...or offense

As a Windows sysadmin exposing RDP (the Windows equivalent to VNC/ARD) directly to the internet without a proxy, VPN or strict firewall policy that restricts it to a few known public IP addresses has been sysadmin 101 for decades. There have been multiple vulnerabilities that allowed attackers to take over Windows machines over RDP.

So I totally agree with you. This is exactly why you need to protect users from themselves. There will always be bugs in software and you should minimize the risk from them by taking some security measures.

Why does Apple need to protect anyone from themselves? This is the problem with commercial vendors creeping in computing freedom. It is exactly this mentality that people shouldn't be the ones responsible for the hardware and software they own and operate which erodes that freedom.

> is exactly the kind of person that Apple needs to protect from themselves

"If you are protected by a steel door, but you don't have the key, you are not safe -- you are imprisoned."

For all of Linux's warts, it's still better than the commercial crap coming from Microsoft and Apple that focuses on 99% of consumers. For many of us at HN, Linux is a blessing and it's only getting better.

apple and unlocked devices, is this some new level of hardcore sarcasm, or good ol' cluelessness about the actual topic on new profound levels?

Apart from whole post feeling like a PR, but thats not that uncommon here

From Apple's statement, they want to be sure users understand that they are handing Meta access to all of their personal data if they grant Muse (or other AI agents) the full-disk access permission.

> Some developers are using Full Disk Access in ways that could put users at risk, exposing everything on their systems—including files, mail, messages, and even browsing history—without users’ full knowledge and understanding. For communication apps, this can also compromise the privacy of the people users are communicating with.

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.

It's the constant risk for Apple that its customer base voluntarily invites any company to interact with them directly, because it's Apple's prerogative to broker the access to its users.

So as always, for the sake of "privacy" Apple needs to take action to protect the users from "themselves", and make it undesirable to grant others the same access Apple has...

In that case, it will be their own dang fault. Modern MacOS is a mess of update nags, unwanted notifications, and permissions prompts. We want sandboxing and security patches but the UX around it is abominable.

My next laptop might be a Snapdragon Elite X2 if they get good Linux support. It's probably going to be comparable to macs in battery and CPU power.

https://www.infoq.com/news/2026/10/snapdragon-x2-linux

If it doesn't support Linux well, I'm not buying it. It's that simple.

Omarchy has been fun to play with and perhaps is a contender against macOS for some developers.

I think some standards org needs to define comprehensive agent permissions model first before the OS raises the abstraction to agent level authorization.

He port forwarded 5900 to his Mac.

it's a vnc port, it'd also require the router to have it opened. Reading the article I think the user opened it themselves. It does get opened automagically on the mac side when screen sharing is turned on.

> The problem is that for my particular use case — a headless, always-on Mac Mini that I primarily access from other computers and my phone through the ChatGPT and Claude apps — macOS is incredibly hostile

> As noted by the NCSC, the vulnerability is being exploited when port 5900 is exposed to the Internet. When screen sharing is turned on, the macOS firewall opens the port. Routers and dedicated firewalls generally block the port unless configured to override that setting.

> Obviously I should have — and will be — using a VPN going forward (the foundation of my entire approach to security is Tailscale); what I will note, however, is that TCC basically leaves me no choice but to have screen sharing enabled if I want to actually use my Mac Mini in the way I want to use it. I use screen-sharing constantly — including from my phone — and almost every time it’s to click “OK” on a stupid prompt that I’ve long since stopped taking seriously.

The thing is that many of these people think they know what they are doing and do not think about security, only how awesome LLMs and AI make their experience until something bad happens.

Even though this was a valid critical bug [1], you need to enable screen sharing and allow connections to and from port 5900 on your router for a remote person to be able to exploit this.

Any security conscious person would probably be using a VPN (Wireguard or Tailscale) to prevent something like this, in the first place.

> almost every time it’s to click “OK” on a stupid prompt that I’ve long since stopped taking seriously.

The line above tells you how seriously this person takes security prompts.

[1]: https://nvd.nist.gov/vuln/detail/cve-2026-65400

I opened my SSH port to the internet back in the day because I could tunnel my internet through it to avoid network blocks. (sshuttle my beloved)

The average HN user?

I mean, every time ISPs, NAT, or IPv6 is mentioned you have a LOT of people who are really angry they can't just netcat a random port on their friends' machine to send files to it.

Yeah, the dude wrote a 3,500-word article trashing Apple when he can't even follow the most basic security practice in the first place.

I got confused for a second how Claude Code and agents are related to this piece. Of course they aren't. Anyone with a half brain about securing their system would never run into any of this in the first place. Hiring Claude Code to do scanning every half an hour is such a waste of tokens.

Forgive me for being the idiot in the room but is the argument:

1. 5900 was always known to be an extra unsafe port to have open

2. all ports should be assumed unsafe without explicit vetting

I'm assuming the argument being made is (2), but it really is a sad safe of affairs because use cases from time to time do involve having ports hot.

Or should things be taken one step further to *always* use a vpn or similar?

He gonna write more articles if he uses Linux and Windows

He also had that computer configured to download system updates automatically, but not to install them.

On the plus side, at least he didn't run the AI agent on the computer with all of his personal data.

"Thank god the causes told me about the effects!"

> What alleviates my worst fears is the knowledge that every technical user at Apple itself needs to use their Mac as the powerful Unix workstation OS that it is.

What Gruber didn't realize is that Apple gives its engineers special internal tools that can bypass the restrictions we on the outside have to suffer.

I'm sure it's also the case that internal development macOS builds are compiled differently than public release builds. They basically have to be for Apple engineers to modify them during development.

might depend on the cat

https://www.youtube.com/watch?v=cKwKysk5rEw

TCC prompts have some degree of "synthetic click" detection. It's been a while since I've tried to click "Allow" with osascript.

> There is one aspect in which the Mac is the perfect agent host: Apple has, for decades, invested in a combination of scriptability, automation, and accessibility APIs (these are very often the same thing) that makes it remarkably well-suited to computer use.

It's the software that matters here, not the hardware.

> I use screen-sharing constantly — including from my phone — and almost every time it’s to click “OK” on a stupid prompt that I’ve long since stopped taking seriously;

It's insane what people will put up with to avoid just doing it properly on a real OS.

Linux.

There is no Linux that will run on anyhing newer than M4 and even that is incomplete.

We already have all these permission layers too. SELinux and Windows NT have existed for a long time.

So has macOS. It’s just a matter that the agents don’t bother to use the existing permission layers.

Or he could make use of timely notifications from reminders app, like any normal person does.

The author themselves say "I am admittedly being pedantic here" to that point.

Being happy or not has nothing to do with it, in my understanding as well. Removing full system access from non-deterministic tools prone to prompt injections seems like the most obvious thing to do. There's a reason I run all my projects in rootless isolated containers these days. There has never really been "trust" in software, but the lack of trust is a lot more obvious these days.

This. I'm quite confident that they look at the Mac as a "profit-leaking" product they gradually need to bring on-par with their other products, but can't make any big steps to avoid alienating the userbase.

But I'm sure the day of the iOS-based iMac will come, and pandora's box will be opened. Businesses will love it, especially those with Kiosk use-cases, and not before long we will read everywhere (including here) how superior the security is to a Mac for everyday use...

I don't think that's fair, they've spent a lot of time and effort ensuring the Mac is still an open/UNIX like platform, including (where they didn't have to):

- Per-install boot security policies

- Custom kernel boot (kmutil configure-boot)

- Raw-image boot mode

- XNU source releases

- Disabling SIP

- Disabling the Signed System Volume

- Third-party kernel extensions

- Developer ID distribution and notarisation

- Gatekeeper "Open Anyway" override

- Hypervisor.framework

- Virtualization.framework

- Rosetta for Linux VMs

- Nested virtualisation

- macOS guest provisioning

- DiskImageKit

- Custom Virtio devices

- Containerization framework

Unlike 30 years ago, now I see anti-developer as a feature for end users. The current trend is that big corporation developers just abuse any system to squeeze profits/information from end users as much as possible.

In this case apple do this because Meta are abusing.

I understand this mindset when I put my software developer hat on.

But as an end user, these are hollow words. As a consumer with Apple devices, I'm entrusting Apple to keep my computer protected from bad software, malicious or otherwise. You need to appreciate that you -- the software developer -- are not the good guy. We're not the same team. If you don't like your little sandbox, or if you resent having to ask for permission to go beyond it, that's a you problem, not a me problem.

As a software developer, I can see it from both sides. I wish more people did.

What does this have to do with the article, exactly?

You forgot, they want 30% (or more) of your files to be inaccessible by you, so you can't access the data/media you've downloaded in ways apple doesn't like, or disable apple daemons that collect telemetry or whatever.

> Apple can’t see a future where Mac isn’t like iPhone.

Can you blame them? Their managers cannot code, so they need something else that is "useful" to do. And the one thing they find useful is to increase revenue.

I assume any computer connected to my LAN is also a dedicated attack vector for everything on my LAN in case of compromise.

Exposing any port directly to the Internet is a huge risk these days—at minimum I'd put a very strong firewall in front, and unless it's serving the general public, switch to a non standard port. It's not much but would prevent the dumb automated scripts that operate on standard ports.

No it hasn't and it's not even close.

- Guy writing to you from Windows 11 with multiple Macbook Pros next to him.

TCC throws up vista-style warning prompts everywhere, so to bypass them he opened up remote desktop so he could manually dismiss them, which then got exploited via a recent pre-auth bug in ARD.

If the TCC prompts could be dismissable some other way (e.g. via CLI with root permission) presumably he wouldn't have resorted to such measures. I sort of see the point, the lesson from Vista is that if you put up annoying obstacles people are going to the easiest workaround, bulldozing over them rather than putting up with them. People will end up disabling SIP or poking more hole if they don't have an easy way to bypass TCC stuff.

This seems like sysadmin 101 to me. Controlling local access and who to trust was always the way. Platform vendors always enjoyed this privilege. Overriding the platform vendors software tools was done with variations kept in /usr/local/ and symlinked to over ride the vendors choices.

Full disk access is a permission you can grant to software on you Mac, that is not reserved just for Apple, and nothing Apple has said implies they have any intention of removing that class of permission. All they said is that they want users to be fully aware of the implications when granting it.

maybe there is a reason they are called... system frameworks?

I will never understand comments like this.

You are on the wrong site if you think that HN was ever a bastion of the hyper OSS mindset.

This is a site powered by and run by one of the arms of a startup incubator/investor. It has always been clear on that.

Just because it has “hacker” in the name doesn’t mean what you think it means.

I'm not sure where you're getting the "worshiping" part from. Though I respect your overall opinion while still disagreeing from it, it's been a very long time since HN came anywhere near worshiping Apple or even most big tech companies. Most of us simply live in the real world where using big tech wares is a soft-requirement. Using an Apple device or having interest in them makes one no more or less a "hacker", which is already a pretty subjective and contextual term to begin with.

If you are interested in tech outside of consumer electronics lobsters is a good alternative to here.