今日已更新 90 条资讯 | 累计 26894 条内容
关于我们

Where the guardrail lives

Tobias 2026年08月02日 02:42 2 次阅读 来源:Dev.to

Three threads I read this week were about the same question: when should an AI agent stop and ask a human? All three answered at the level of the action. Which tool call is risky, which amount needs a signature, which decision the model isn't allowed to make. The cheapest guardrail I have doesn't live there. It's picking what the thing runs inside. The renderer that never gets trusted Part of what I build renders arbitrary HTML in a headless browser. Anyone can hand it a URL or a page of script, and there's no version of that where I trust the renderer to behave. So it doesn't get asked to. It runs sandboxed, with egress rules, resource limits and a hard wall-clock deadline, and a bad render gets killed rather than reasoned with. None of the safety comes from the thing being careful. The same rule, pointed at my own tooling Reach gets reduced before the run, not judged during it. Two I actually hold myself to: Two browser-automation paths. One drives my real logged-in profile, for the handful of tasks that genuinely need it. One launches an empty throwaway profile, and that's the default for everything else. Secrets get written to a file and passed by path, never echoed into the conversation. A value that never enters the context can't leak through a summary, a log, or a screenshot of the session. Both cost something real. I script a login instead of already being logged in, and I read a path instead of a value. It has overruled the convenient option more than once. Rules the agent follows are still worth having. They just can't be the only layer, because they share one failure mode: they depend on the agent correctly judging what it's about to do. So, one question, since I only have my own handful of examples: what's something you've made structurally impossible for your agent, rather than something you told it not to do?

本文内容来源于互联网,版权归原作者所有
查看原文