←back to thread

224 points azhenley | 2 comments | | HN request time: 0.001s | source
Show context
ayende ◴[] No.45075710[source]
That is the wrong abstraction to think at. The problem is not _which_ tools you give the LLM, the problem is what action it can do.

For example, in the book-a-ticket scenario - I want it to be able to check a few websites to compare prices, and I want it to be able to pay for me.

I don't want it to decide to send me to a 37 hour trip with three stops because it is 3$ cheaper.

Alternatively, I want to be able to lookup my benefits status, but the LLM should physically not be able to provide me any details about the benefits status of my coworkers.

That is the _same_ tool cool, but in a different scope.

For that matter, if I'm in HR - I _should_ be able to look at the benefits status of employees that I am responsible for, of course, but that creates an audit log, etc.

In other words, it isn't the action that matters, but what is the intent.

LLM should be placed in the same box as the user it is acting on-behalf-of.

replies(9): >>45075916 #>>45076036 #>>45076097 #>>45076338 #>>45076688 #>>45077415 #>>45079715 #>>45080384 #>>45081371 #
nostrademons ◴[] No.45076338[source]
What you're speaking of is basically the capability security model [1], where you must explicitly pass into your software agent the capabilities that they are allowed to access, and there is physically no mechanism for them to do anything not on that list.

Unfortunately, no mainstream OS actually implements the capability model, despite some prominent research attempts [2], some half-hearted attempts at commercializing the concept that have largely failed in the marketplace [3], and some attempts to bolt capability-based security on top of other OSes that have also largely failed in the marketplace [4]. So the closest thing to capability-based security that is actually widely available in the computing world is a virtual machine, where you place only the tools that provide the specific capabilities you want to offer in the VM. This is quite imperfect - many of these tools are a lot more general than true capabilities should be - but again, modern software is not built on the principle of least privilege because software that is tends to fail in the marketplace.

[1] https://en.wikipedia.org/wiki/Capability-based_security

[2] https://en.wikipedia.org/wiki/EROS_(microkernel)

[3] https://fuchsia.dev/

[4] https://sandstorm.io/

replies(4): >>45076969 #>>45077002 #>>45077449 #>>45080600 #
1. pdntspa ◴[] No.45077002[source]
How would that even work when the web is basically one big black box to the OS? Most of the stuff that matters to most consumers is on the web now anyway. I don't see how 'capabilities' would even work within the context of a user-agent LLM
replies(1): >>45077105 #
2. nostrademons ◴[] No.45077105[source]
You'd have to rewrite most of the software used in modern life. Most of it is conceptually not built with a capability security model in mind. Instead of providing the LLM with access to your banking app, you need a new banking app that is built to provide access to your account and only your account, and additionally also offers a bunch of new controls like being able to set a budget for an operation and restrict the set of allowable payees to an allowlist. Instead of the app being "Log into Wells Fargo and send a payment with Zelle", the app becomes "Pay my babysitter no more than $200", and then the LLM is allowed to access that as part of its overall task scheduling.

This is a major reason why capability security has failed in the marketplace.