Prompt guardrailだけでは足りない。LocalLLaMAが戻ってきたのは実行前に止める話だった

この LocalLLaMA スレッドが伸びたのは、抽象論ではなく体感に近かったからだ。投稿は、今の LLM safety の会話が jailbreak や output filtering に長くとどまりすぎていて、agent system がすでに別のリスク領域に入っていると指摘する。model が API を呼び、file を変更し、script を実行し、browser を動かし、internal system や MCP tool に触れられるようになった瞬間、重要なのは what the model says ではなく what actually executes になる。この切り分けに、多くの読者が自分の運用感覚を重ねていた。

特に効いていたのは distributed systems との比較だ。普通の software system では、副作用の制御を application の善意に任せない。auth before access、rate limits before overload、transactions before mutation のような hard boundary を app の外に置く。投稿は、agent stack の多くが intent、tool call、execution を同じ loop に押し込んでいるため、retry が誤動作を増幅し、permission が曖昧になり、available な tool があるだけで呼ばれてしまうと書く。ここでの核心は単純だ。final allow or deny はどこで行われ、agent runtime の外で enforce されているのか。

reply が全面同意一色でなかったのも、むしろ議論を良くしていた。普通の engineering 問題に見えるという声もあったし、prompt guardrail には低レベルのノイズを減らす役割があるという反論もあった。ただ、その反論も最終的には同じ設計問題に戻ってくる。guardrail は小さな事故には効いても、速度の出た truck は止められないという比喩や、JIT auth token を外側に置くべきだという話が出た。投稿者も、guardrail は不要だと言っているのではなく、capability と authority が同じ loop に束ねられている構造が問題だと整理し直している。

この thread が重要なのは、local setup と production agent stack の差が急速に縮んでいるからだ。agent が filesystem、shell、API、共有された tool ecosystem に触れるなら、安全性は system prompt の上手さではなく execution architecture の話になる。LocalLLaMA がこの投稿を拾ったのも、その転換点を感じているからだろう。community が探していたのは、より強い禁止文ではない。model が drift しても retry しても、実行前に止められる outside gate だった。

Source: Reddit thread.