Took a look at Paxel. It's worth noting that we have the client target code to analyze only, I could not find server side code, nor source prompts for the client code, if any of those could be provided it would make auditing easier.

Also, I appreciate that it's probably all fine, and that my attack scenarios are mostly theoretical, and that YC took care in developing security measures for Paxel, and that maybe I'm paranoid.

But I believe in a security model that doesn't rely just on trust, but on system level guarantees, where we install things not by running 'curl $URL | bash', but by robust technologies like OAuth. Yes, maybe it's a bit harder to build, and the 'UX' of installing these things will not be as clean. I'm just not on board with the piping curl into bash fad. I'm sure there's a sweetspot of trustingness and scrutiny.

To take some heat off YC, they are not the only ones, consider socket.dev, a security product, they tell you that they will not read your code, only the requirements.txt and package.json type of files, but when you install it, GitHub gives them full access to repos, we have had file level permissions for years, but suddenly it's not possible to request that level of granulairty for permissions.

I'm sure that there's a sweetspot between trustworthiness and rigour, but 'curl|bash' and 'deputyless permissions' is clearly on the too-trustworthy end of the spectrum, fantastically so, it makes me feel the overton window is shifting towards extremist levels of disregard for security.

But maybe I'm wrong, I'd love to read a defense of 'curl|bash', 'give the agent access to all the company data' and 'you can just ask the LLM to not read some data'.