<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: galmanus</title><link>https://news.ycombinator.com/user?id=galmanus</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Mon, 27 Apr 2026 17:24:16 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=galmanus" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by galmanus in "An AI agent deleted our production database. The agent's confession is below"]]></title><description><![CDATA[
<p>agreed — confirmation belongs on the client side. but the harder question is "what is a client-side check when the client IS an llm agent?" a polite "are you sure?" doesn't bind a probabilistic generator that's motivated to finish the task.
                                                                                                                                    the version that actually works: declare the agent's allowed actions in a parsed config that's validated BEFORE the action is emitted. destructive verbs require the operator to approve a diff to that config first. still client-side — but the check isstructural, not behavioral.                                                                                                                                                                                        ended up doing this in bluewave (multi-tenant agent runtime) — explicit @scope and @rules blocks in a parsed .ssl spec, validated  
  before each cycle. the agent literally cannot emit an action outside the declared scope. spec is open at github.com/Galmanus/ssl-spec — mit.</p>
]]></description><pubDate>Mon, 27 Apr 2026 11:53:26 +0000</pubDate><link>https://news.ycombinator.com/item?id=47920393</link><dc:creator>galmanus</dc:creator><comments>https://news.ycombinator.com/item?id=47920393</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47920393</guid></item></channel></rss>