Thread

1. jkingsman · 1790693007 · focus · HN ↗

   I'm no evangelist for LLM assistants, but this seems incredibly improbable and represents a failure of MacOS security if so. If full disk access isn't granted, Mac blocks it from the Downloads folder, to say nothing of actually sensitive paths. I would expect a far more likely case of an accidentally granted permission on another device or a permission that was on and then turned off.

   Permissionless action is about to skyrocket as an issue, but this particular scenario strikes me as incredibly unlikely. Would be interested to know if Muse can provide more meaningful data provenance/logs.

   Scanning iMessage dbs as a passive part of full disk access (and not a messages grant), if true, is a little sketchy, regardless.

   1. skohan · 1790696607 · focus · HN ↗

      Agent sandboxing/access control is one of the biggest problems to be solved before this technology really should go mainstream.

      Even as a technical person, it's not trivial to sandbox agents correctly. The fact that an mis-clicked permission popup could give an agent unrestricted access to a user's disk is a massive risk vector in the hands of lay people who barely understand how any of this works.

      So much of current security depends on the model of tying access control to a user account. A lot has to be re-thought in terms of how to grant access to an agent working on the user's behalf, in a way that doesn't make it completely useless, and also doesn't require every user to become a sysadmin managing fine-grained agent permissions manually.

      1. robby_w_g · 1790697148 · focus · HN ↗

         I think sandboxing could be solved if effort was put into it. Webassembly seems like a great way to enforce data and execution boundaries for an LLM, for example.

         I think the problem is that LLM providers are dis-incentivized from pursuing it because their ethos is gobbling up any and all data they can get.

         > Oops, we accidentally yoinked your personal documents, photos, and videos and they’re now swimming in our model’s data ocean! We’re sorrrry, oh well let’s move on.

         It’s up to the users to use tools that enforce security/privacy. Open source harnesses like pi.dev seem like a good path forward to me

         1. skohan · 1790697963 · focus · HN ↗

            Sandboxing the agent application is easy. The tough part is sandboxing in such a way that it's still useful.

            I.e. if I have an agent running in a WASM sandbox with no access to the host system, I can't ask it to clean up my files. Same thing with things like giving an agent access to your email inbox: doing so allows the agent to provide utility, but it comes with risks, as the agent can delete important emails, or leak sensitive data.

            I think a big part of the problem is, a lot of the systems we use and would like agents to help us with don't have a concept of separated roles with different levels of access which can be applied. A lot of times it's all or nothing.

            And even when we do have fine-grained access control available, it's a pain in the ass to manage it. Like you can create a GitHub token with fine-grained access control to your repositories and make sure the agent only uses that one to connect, but it's a whole lot easier to use a broad-access token, or just let the agent use your own token, so lots of people will just end up doing that.

            And I also like pi, but it's probably one of the worst in terms of sandboxing as it's yolo by default.

            1. SwabbyNat74 · 1790698519 · focus · HN ↗

               Fundamentally i think its how we're trying to skip critically important steps here. Its like the first automobiles that were built with completely uncovered, unfiltered engines. Dropped onto a chassis, and then opened up, dirt, debris, oils, etc intermingled and things blew up. Gas lines, oil reservoirs, compartments and chambers that are all specialized to create a highly efficient and consistent experience came out of designing it properly. The same can be said for Muse and other agents. Without the right scaffolding and harness, of course things go wrong.

               I'm a HUGE proponent of putting them behind task gating trees, and sheathing them with QA/QC checks on their processes, especially at this stage. Unfortunately its so easy to create, and all of that takes time and design that many just throw away for getting to results.

               Even fine grained ACLs, which are great, dont have the structured approach such autonomous agents need to shore them in (imo).

            2. robby_w_g · 1790700808 · focus · HN ↗

               There is definitely a balance between utility and security/privacy gates. I think people are enjoying the freedom of YOLO for now until the consequences of gate-free agent use become too severe.

               > And I also like pi, but it's probably one of the worst in terms of sandboxing as it's yolo by default.

               Agreed, but the nice thing about pi is the plugin system and how configurable it is. I can easily hack on the pi harness, whereas a more opinionated one like opencode is more difficult

               1. skohan · 1790706557 · focus · HN ↗

                  Yeah I think people are probably widely underestimating the risks. Like if you gave another programmer unlimited access to your system and ssh keys, and they never slept and could code and run terminal commands at dozens or hundreds of words per minute, you would have to trust them a lot to give them that.

                  And I love pi - it's my daily driver - but the extension system itself is an attack vector. If any process manages to write an extension to your .pi directory, it could rewrite your prompt to have the agent exfiltrate your secrets, or take whatever action on the host system if you don't sandbox it.

            3. shieldagent · 1791103364 · focus · HN ↗

               [dead]

Unofficial Hacker News client; not affiliated with Y Combinator.