Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't trust AI agents

nanoclaw.dev

Post reply on HN
Print view View original

161–170 of 211 posts

Re: Don't trust AI agents

#161

Post by ninkendo »

FEELmyAGI wrote: post #159
ninkendo wrote: post #134

Earlier quoted context omitted.

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 vocabul…

> Did you investigate prior art before setting out on this endeavor

Lol no, I had no idea there was any other password managers! Thanks for the google search link! I didn't know search engines existed either!

> Wisdom means knowing when and where to apply cleverness, and where not to. like being able to recognize existing sub-components.

It says literally in the README that part of this is an exercise in seeing what an LLM can do. I am in no way suggesting anyone use this (because there's a bazillion other password managers already) nor would I even have made this public if you hadn't baited me into doing it.

The fact that there's a literal sea of password managers out there is why I'm curious enough to think "maybe a one that I get to design myself, written to exactly my tastes and my tastes alone could be feasible", and that's what this exercise is about. It literally took me less time to vibe-code what I have right now, than to pour through the sea of options that already exist to decide which one I should try. And having it be mine at the end means that I can implement my pet features the way I want, without having to worry one bit about fighting with upstream maintainers. It's also just fun. I thoroughly enjoy the process of thinking about the design and iterating on it.

Re: Don't trust AI agents

#162

Post by steveklabnik »

TacticalCoder wrote: post #137
ruszki wrote: post #135

Earlier 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…

> I don't think a "not good programmer" can write a Lisp dialect.

You can write a lisp in 145 lines of Python: https://norvig.com/lispy.html

Re: Don't trust AI agents

#163

Post by steveklabnik »

MadxX79 wrote: post #46
badsectoracula wrote: post #32

> 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…

Brook's law anno 2026: "Adding manpower to a late software project makes it later -- unless that manpower is AI, then you're golden!"

I know you're being sarcastic, but this is what OpenAI has said:

https://openai.com/index/harness-engineering/

> This translates to an average throughput of 3.5 PRs per engineer per day, and surprisingly the throughput has increased as the team has grown to now seven engineers.

We will see if this continues to scale up!

Re: Don't trust AI agents

#164

Post by Zak »

wiseowise wrote: post #127
Zak wrote: post #120

Earlier quoted context omitted.

Who is signaling what virtues to whom in this context? When I see PG write something like that, it signals to me that he has embraced AI hype to the point that he is displaying poor taste and embracing a risky technical practice.

PG is signaling his AI bros, idk.

I imagine PG is rich enough and influential enough in the tech/VC space that he doesn't have to signal anything he doesn't honestly believe.

It's unsurprising he would believe LLM coding tools are a productivity boon, but using code quantity as a measure of software development progress is one of the most famously wrong ideas in the software world. Either he wrote carelessly, or he believes that LLM tools have changed that reality.

I'm inclined to think LLM tools haven't substantially changed that reality. LLMs perform better when more of the problem fits in context, so succinctness remains valuable.

Re: Don't trust AI agents

#165

Post by shich »

buremba wrote: post #14

My 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…

The proxy approach for secret injection is the right mental model, but it only works if the proxy itself is hardened against prompt injection. An agent that can't access secrets directly can still be manipulated into crafting requests that leak data through side channels — URL params, timing, error messages.

The deeper issue: most of these guardrails assume the threat is accidental (agent goes off the rails) rather than adversarial (something in the agent's context is actively trying to manipulate it). Time-boxed domain whitelists help with the latter but the audit loop at session end is still reactive.

The /revert snapshot idea is underrated though. Reversibility should be the first constraint, not an afterthought.

Re: Don't trust AI agents

#166

Post by KerrAvon »

aerhardt wrote: post #150
TacticalCoder wrote: post #137

Earlier quoted context omitted.

> 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…

I take him to be a good programmer on top of a pioneer venture capitalist and entrepreneur but Hackers and Painters contains some pretty bad predictions and takes on programming, and if he didn't have that good foresight then , it has probably become worse with the years.

obligatory Dabblers and Blowhards https://idlewords.com/2005/04/dabblers_and_blowhards.htm

Re: Don't trust AI agents

#167

Post by lukan »

gyomu wrote: post #41
badsectoracula wrote: post #32

> 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…

Yeah, it’s pretty wild. Even pg is tweeting stuff like “An experienced programmer told me he's now using AI to generate a thousand lines of code an hour.“ https://x.com/paulg/status/2026739899936944495 Like if you had told pg to his face in (pre AI) office hours “I’m producing a thousand lines of code an hour”, I’m pretty sure he’d have laughed and pointed out how pointless that metric was?

Hm, I do not read the statement as a hyped "this is how everyone should write code now" rather as a statement of fact. "A experienced programmer he knows uses LLMs to generate thounds LOC/h". That does not say whether those lines will actually be shipped anywhere or just exist for testing purposes/prototyping.

Re: Don't trust AI agents

#168

Post by nickdirienzo »

atonse wrote: post #142
nickdirienzo wrote: post #106

I tried NanoClaw and love the skill (and container by default) model. But having skills generate new code in my personalized fork feels off to me… I think it’s because eventually the “few thousand auditable lines” idea vanishes with enough skills added? Could skill contributions collapse into only markdown and MCP calls? New features would still be just skills; they’d bring in versioned, open-source MCP servers runni…

> I think it’s because eventually the “few thousand auditable lines” idea vanishes with enough skills added? I just watched a youtube interview with the creator. He actually explains it well. OpenClaw has hundreds of thousands of lines you will never use. For example, if I only use iMessage, I have lots of code (all the other messaging integrations) that will never be used. So the skills model means that you only "ge…

I totally get that, and I'm reminded of plugin architectures (e.g. VSCode extensions or browser extensions).

Those extensions don't modify the core codepaths for what they integrate with, but still provide new capabilities for only what I want to use.

I guess I don't see extensibility, agentic capabilities, and more code safety (and fewer tokens burned on codemods) as mutually exclusive. Not saying you're saying that fwiw.

Re: Don't trust AI agents

#169

Post by jrpear »

eyberg wrote: post #79
benatkin wrote: post #34

Earlier quoted context omitted.

No, but Podman is. The recent escapes at the actual container level have been pretty edge case. It's been some years since a general container escape has been found. Docker's CVE-2025-9074 was totally unnecessary and due to Docker being Docker.

No they have not been. There were at least 16 container escapes last year - at least 8 of them were at the runtime layer. I personally spent way too much time looking at this in the past month: https://nanovms.com/blog/last-year-in-container-security runc: https://www.cve.org/CVERecord?id=CVE-2025-31133 nvidia: https://www.cve.org/CVERecord?id=CVE-2025-23266 runc: https://www.cve.org/CVERecord?id=CVE-2025-52565 youki…

It looks to me like what is called a "container escape" in this context isn't necessarily as bad as it seems. For example, in the advisory for CVE-2025-31133 affecting runc[1]:

> Container Escape: ...Thus, the attacker can simply trigger a coredump and gain complete root privileges over the host.

Sounds bad. But...

> this flaw effectively allows any attacker that can spawn containers (with some degree of control over what kinds of containers are being spawned) to achieve the above goals.

The attacker needs already to have the capability to spawn containers! This isn't a case of "RCE within the container" -> "RCE outside the container", which is what I would think prima facie reading "container escape".

I have always thought that running an untrusted image within an unprivileged container was a safe thing to do and I still believe so.

[1] https://github.com/opencontainers/runc/security/advisories/G...

Re: Don't trust AI agents

#170

Post by livestories »

fnord77 wrote: post #66
buremba wrote: post #14

My 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…

I think mailto: links they output (a la

https://mailtolink.me/

) are a great way to get these drafts out even.

Post reply on HN