[dead]
Don't trust AI agents
151–160 of 211 posts
Re: Don't trust AI agents
#152My take is that agents should only take actions that you can recover from by default. You can gradually give it more permission and build guardrails such as extra LLM auditing, time boxed whitelisted domains etc. That's what I'm experimenting with https://github.com/lobu-ai/lobu 1. Don't let it send emails from your personal account, only let it draft email and share the link with you. 2. Use incremental snapshots an…
I'd like to try a pattern where agents only have access to read-only tools. They can read you emails, read your notes, read your texts, maybe even browse the internet with only GET requests... But any action with side-effects ends up in a Tasks list, completely isolated. The agent can't send an email, they don't have such a tool. But they can prepare a reply and put it in the tasks list. Then I proof-read and approve…
GET and POST are merely suggestions to the server. A GET request still has query parameters; even if the server is playing by the book, an agent can still end up requesting GET http://angelic-service.example.com/api/v1/innocuous-thing?pa... and now your `dangerous-secret` is in the server logs.
You can try proxying and whitelisting its requests but the properly paranoid option is sneaker-netting necessary information (say, the documentation for libraries; a local package index) to a separate machine.
Re: Don't trust AI agents
#153Has anyone used: OpenClaw NanoClaw IronClaw PicoClaw ZeroClaw NullClaw Any insights on how they differ and which one is leading the race?
I haven't used them all but based on my partial research so far: - OpenClaw: the big one, but extremely messy codebase and deployment - NanoClaw: simple, main selling point is that agents spawn their own containers. Personally I don't see why that's preferable to just running the whole thing in a container for single-user purposes - IronClaw: focused on security (tools run in a WASM sandbox, some defenses against pro…
IronClaw’s security architecture sounds plausible, but I have not audited it. Plugins can only access remote endpoints you’ve specifically allowed it for. Secrets aren’t available to the LLM - they are injected where the LLM requires it but only secrets authorized for that plugin are available to it. Together those two things provide an answer to a huge range of the most common prompt injection vulnerabilities, such as credential extraction. So you can give it access to your bank account and email and it can’t email your bank password to an attacker. But it could still transfer money to them.
The only secure way to use any of these tools is to give them very limited access - if they need a credit card give them a virtual card with a low limit, or even its own bank account. They can send email but only from their own account; like a human personal assistant. But of course this requires careful thought and adds friction to every new task, so people won’t be doing it.
Re: Don't trust AI agents
#154My take is that agents should only take actions that you can recover from by default. You can gradually give it more permission and build guardrails such as extra LLM auditing, time boxed whitelisted domains etc. That's what I'm experimenting with https://github.com/lobu-ai/lobu 1. Don't let it send emails from your personal account, only let it draft email and share the link with you. 2. Use incremental snapshots an…
> 1. Don't let it send emails from your personal account, only let it draft email and share the link with you. Right now there's no way to have fine-grained draft/read only perms on most email providers or email clients. If it can read your email it can send email. > 3. Don't let your agents see any secret. Swap the placeholder secrets at your gateway and put human in the loop for secrets you care about. harder than…
> harder than you might think. openclaw found my browser cookies. (I ran it on a vm so no serious cookies found, but still)
It's easy, and you did it the right way. Read "don't let your agents see any secret" as "don't put secrets in a filesystem the agents have access to".
Re: Don't trust AI agents
#155Earlier quoted context omitted.
> 1. Don't let it send emails from your personal account, only let it draft email and share the link with you. Right now there's no way to have fine-grained draft/read only perms on most email providers or email clients. If it can read your email it can send email. > 3. Don't let your agents see any secret. Swap the placeholder secrets at your gateway and put human in the loop for secrets you care about. harder than…
> Right now there's no way to have fine-grained draft/read only perms on most email providers or email clients. If it can read your email it can send email. > harder than you might think. openclaw found my browser cookies. (I ran it on a vm so no serious cookies found, but still) You should never give any secrets to your agents, like your Gmail access tokens. Whenever agents needs to take an action, it should perform…
> That means agents should not have access to internet without a proxy, which has proper guardrails. Openclaw doesn't have this model unfortunately so I had to build a multi-tenant version of Openclaw with a gateway system to implement these security boundaries.
I wonder how long until we see a startup offering such a proxy as a service.
Re: Don't trust AI agents
#156A question I've been asking myself and which I honestly want to put out there - and I apologize in advance, because you will see me repeat it in other threads, out of genuine curiosity:
Does your life have so much friction that you need a digital agent to act on your behalf?
Some of the use cases I saw on the OpenClaw website, like "checking me into a flight", are non-issues for me.
I work in business automation, but paradoxically I don't think too much about annoyances in my private life. Everything feels rather frictionless.
In business, I see opportunities to solve friction and that's how I make money, but even then, often there are barriers that are very hard to surmount:
(a) problems are complex to solve and require complex solutions such as deterministic or ML systems that LLMs are not even close to being able to create ad-hoc
(b) entrenched processes and incumbent organizations create moats that are hard to cross (ex: LinkedIn makes automation very hard)
(c) some degree of friction, in some cases, may actually be useful!
I imagine there are similar dynamics in the consumer space, but more than anything, I may not be seeing issues with such a critical eye (I like to relax after work, after all)
So, do you have problems in your private life that you'd want to take on the risks - and friction - of maintaining these agents?
Re: Don't trust AI agents
#157> OpenClaw has nearly half a million lines of code, 53 config files, and over 70 dependencies. This breaks the basic premise of open source security. Chromium has 35+ million lines, but you trust Google’s review processes. Most open source projects work the other way: they stay small enough that many eyes can actually review them. Nobody has reviewed OpenClaw’s 400,000 lines. This reminds me of a very common thing po…
I've been waiting for someone to say this. An agent will generally produce far more code than technically necessary for the task. It's a kind of over engineering which makes it increasingly harder to wrap your head around the codebase.
Over engineered implies the codebase was inflated with some kind of rationale by the AI, but there is none. It's just code vomit with duct tape
Re: Don't trust AI agents
#158Re: Don't trust AI agents
#159Earlier quoted context omitted.
This whole reply, and every other "anecdote" reply is more worthless than the pixels its printed on, without a link to your "actually did a good job" password manager. (wow funny how these vibe code apps always are copies of something theres many open source versions of already)
Ugh, you made me spend the 20 minutes it takes to spin up a new github account to share this (my existing one uses my real name and I don't really want to doxx myself that much. Not that it's a huge deal, my real identity and the "ninkendo" handle have been intertwined a lot in the past.) https://github.com/ninkendo84/kenpass I'm not saying it's perfect, there's some things I would've done differently in the code. It…
Thank you for the time commitment based on an internet forum comment. I appreciate greatly the succinct human written README.
Did you investigate prior art before setting out on this endeavor? https://www.google.com/search?q=site%3Agithub.com+password+m...
I ask because engineers need to be clever and wise.
Clever means being capable of turning an idea into code, either by writing it or recently by having the vocabulary and eloquence to prompt an LLM.
Wisdom means knowing when and where to apply cleverness, and where not to. like being able to recognize existing sub-components.
Re: Don't trust AI agents
#160Earlier quoted context omitted.
I don't understand how some people decide here, who the good programmers are. A lot of people reminded me a guy from West Palm Beach, who votes on elections solely on the principle of who has more "fame". Paul Graham is famous for sure (at least in HN circles), but I never considered him an exceptional or good programmer at all. So I always interpreted his words with a hefty amount of grain of salt. And sometimes som…
> Paul Graham is famous for sure (at least in HN circles), but I never considered him an exceptional or good programmer at all. pg wrote a Lisp dialect, Arc, with Morris. The Morris from "the Morris worm". These people are at the very least hackers and they definitely know how to code. I don't think a "not good programmer" can write a Lisp dialect. At least of all the "not good" programmers I met in my life, 0% of th…
Presumably he got better in the intervening decades, but part of how we stopped the Morris Worm was that it was badly written (see the various version of With Microscope and Tweezers for detail, particularly about the "am I already running" check that ended up being why it got noticed, "because exponential growth".) Even for "bored 1st year grad student skipping lectures" it should have been better code :-)
(Also, writing a Scheme dialect was a first-semester CS problem set - if you're in a 1980s academic CS environment it was more effort to not accidentally write a lisp interpreter into something, something in the water supply...)