<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: feigewalnuss</title><link>https://news.ycombinator.com/user?id=feigewalnuss</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Fri, 24 Apr 2026 08:51:39 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=feigewalnuss" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by feigewalnuss in "OpenClaw isn't fooling me. I remember MS-DOS"]]></title><description><![CDATA[
<p>Right, we have to see credentials and personal data as different problems. Wirken addresses the first directly and only partially the second. Session scoping keeps injection damage inside one channel's scope so a poisoned email cannot reach into your Telegram credentials. The model still reads the email content during that session, and any prompt injection in that content can still act within what just that session can reach.<p>The layer that addresses content-level flow is information-flow enforcement above identity. TriOnyx (<a href="https://github.com/tri-onyx/tri-onyx" rel="nofollow">https://github.com/tri-onyx/tri-onyx</a>) looks at that exact problem: taint and sensitivity tracking, gateway kills on threshold breach.<p>It complements Wirken. You need identity before you can meaningfully ask what agent A has been exposed to.<p>On the agent-gets-its-own-machine approach, that is fine as a blast-radius strategy and I have no quarrel with it. It trades isolation between channels for isolation between the agent and the host. If you only have one channel and disposable keys, it works. It stops working as soon as the agent holds something you cannot cheaply rotate, which for most people ends up being their messaging identities.</p>
]]></description><pubDate>Tue, 21 Apr 2026 04:28:30 +0000</pubDate><link>https://news.ycombinator.com/item?id=47844523</link><dc:creator>feigewalnuss</dc:creator><comments>https://news.ycombinator.com/item?id=47844523</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47844523</guid></item><item><title><![CDATA[New comment by feigewalnuss in "OpenClaw isn't fooling me. I remember MS-DOS"]]></title><description><![CDATA[
<p>Disclosure: I wrote the linked post.<p>The "gave it my Gmail password" problem has a better answer than "don't do that." Security kicks itself out of the room when it only says no. Reserve the no for the worst days. The rest of the time, ship a better way.<p>That's why I built the platform to make credential leaks hard. It takes more than a single prompt. The credential vault is encrypted. Typed secret wrappers prevent accidental logging and serialization. Per-channel process isolation means a compromise in one adapter does not hand an attacker live sessions in the others.<p>"Don't do that" fails even for users trying their hardest. Good engineering makes mistakes hard and the right answer easy. Architecture carries the weight so the user does not have to.<p>On the trifecta being "sorta-kinda solved" by newer models, no. Model mitigations are a layer, not a substitute. Prompt injection has the shape of a confused-deputy problem and the answer to confused deputies has always been capabilities and isolation, not asking the already confused deputy to try harder.<p>You want the injection to fail EVEN when the model does not catch it.</p>
]]></description><pubDate>Mon, 20 Apr 2026 14:38:36 +0000</pubDate><link>https://news.ycombinator.com/item?id=47835054</link><dc:creator>feigewalnuss</dc:creator><comments>https://news.ycombinator.com/item?id=47835054</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47835054</guid></item><item><title><![CDATA[New comment by feigewalnuss in "OpenClaw isn't fooling me. I remember MS-DOS"]]></title><description><![CDATA[
<p>Disclosure: I wrote the linked post.<p>Heartbeat cron and naive memory are the right thread to pull. Agree.<p>The problem is the data/trust boundary. One agent process, one credential store, all channels sharing both. Whenever we scale the memory up, which we all want to do, we scale the disaster radius of every prompt injection with it.<p>Wirken accounted for this in the first design step. Per-channel process isolation. Handshakes between adapters and the core. Compile-time type constraints so a Discord adapter cannot construct a Telegram session handle. Encrypted credential vault. Hash-chained audit log of every action. All, remaining model-agnostic, so local models and confidential-compute providers are drop-in.<p>Your memory point is still unsolved at this layer. When memory does get solved, you want the solver running where it cannot leak the wrong credentials to the wrong channel. Otherwise the smarter it gets, the worse the breach.</p>
]]></description><pubDate>Mon, 20 Apr 2026 14:29:52 +0000</pubDate><link>https://news.ycombinator.com/item?id=47834910</link><dc:creator>feigewalnuss</dc:creator><comments>https://news.ycombinator.com/item?id=47834910</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47834910</guid></item><item><title><![CDATA[OpenClaw isn't fooling me. I remember MS-DOS]]></title><description><![CDATA[
<p>Article URL: <a href="https://www.flyingpenguin.com/build-an-openclaw-free-secure-always-on-local-ai-agent/">https://www.flyingpenguin.com/build-an-openclaw-free-secure-always-on-local-ai-agent/</a></p>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=47831437">https://news.ycombinator.com/item?id=47831437</a></p>
<p>Points: 307</p>
<p># Comments: 331</p>
]]></description><pubDate>Mon, 20 Apr 2026 07:49:48 +0000</pubDate><link>https://www.flyingpenguin.com/build-an-openclaw-free-secure-always-on-local-ai-agent/</link><dc:creator>feigewalnuss</dc:creator><comments>https://news.ycombinator.com/item?id=47831437</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47831437</guid></item></channel></rss>