logoalt Hacker News

nicoburnstoday at 3:57 PM5 repliesview on HN

It seems to me like it's a fundamentally unsolvable architectural issue with LLMs. Ultimately the only protection is to limit the powers we grant to any given LLM to reduce the fallout when (not if) things go wrong (much like we do with people).

Of all the "AI doomsday" scenarios, people failing to understand this (and treating AIs like deterministic computers) seem like to most likely to cause issues.


Replies

madamelictoday at 6:57 PM

> Ultimately the only protection is to limit the powers we grant to any given LLM to reduce the fallout when (not if) things go wrong (much like we do with people).

I have been working on something like that: https://clawband.io

It's not quite ready for 'showtime' but feel free to take a look and give your impressions if you'd like. I feel the exact same way: I want to allow my agent to perform actions on all services but also limit what they can do.

Basically my idea is wrapping individual service's APIs and then the middleware (Clawband in this case) enforces granular permissioning such as "can make credit cards but only up to $50" or "can send emails but only to specific domains". The agent never gets a raw API key to a service, it uses an intermediate API key that gets exchanged in the backend for calling the service after permissioning has been enforced.

jmounttoday at 5:34 PM

I really think one needs a "Harvard architecture" for AIs (data independent of instructions). Though yes, that may not be possible.

show 3 replies
Angosturatoday at 4:02 PM

Jokes on them. My bank will just truncate it to 10 characters.

show 1 reply
KaiShipstoday at 7:01 PM

[flagged]

embedding-shapetoday at 5:58 PM

> It seems to me like it's a fundamentally unsolvable architectural issue with LLMs.

Seems solved already? Exactly what the system/user division is about, and if that's not enough for you, use a model that has a developer/system/user divide.

Today's SOTA LLMs have pretty excellent following of these divisions, and the user "instructions", regardless if they're smuggled in, won't override the system ones.

The difficulty comes when you accept completely unreviewed/unchanged user-input as user messages, as your system/developer prompts needs to take this into account. You're better off to kind of whitelist what's possible rather than trying to prevent specific things, but seems that hasn't fully caught on yet.

It feels like people and organizations are still trying to discover what works or not, and there are huge gaps being being left open because there simply isn't enough understanding of the limitations and impact of what they make available to users. We're already seeing it in lots of places, feels like it won't get better before it gets worse.

show 3 replies