From f65f1c56aa98fcdf244acc6a7aec803a9ffaedf3 Mon Sep 17 00:00:00 2001 From: sepehr-safari Date: Sat, 19 Sep 2026 22:24:56 +0300 Subject: [PATCH] feat: say how this compares to the things people weigh it against Someone deciding whether to use this is choosing between it and a sandbox, or their client's permission prompts, or an allow list, or reading the calls themselves. The page answered none of those. "What it is not" came closest and is a list of limits, which is a different thing: a limit tells you where this stops, a comparison tells you what to reach for instead and when. Five questions, each phrased the way someone would type it, each answered in its first sentence. That ordering is deliberate. A reader skimming gets the answer without the reasoning, and an assistant summarising the page can lift the first sentence without it collapsing into a claim the rest of the paragraph then qualifies. Every one of them concedes where the alternative is better, because each one is better at something. A sandbox catches what this cannot see and this catches what a sandbox waves through. An allow list runs first and needs no model, and this ships with one. Reading the calls yourself is the right answer until the results get long enough that nobody does. None of them claims this replaces anything, which is both true and the reason the section is worth having: a comparison that concludes "so use ours" is one a reader discounts entirely. No FAQPage markup. The questions are visible text and that is what gets read. Google restricted FAQ rich results to a narrow set of sites, so there is no rich result to win here, and nothing supports a separate retrieval benefit for the markup on its own. Structured data that buys nothing is still something to maintain. --- src/pages/index.astro | 48 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) diff --git a/src/pages/index.astro b/src/pages/index.astro index f2da0f2..914885c 100644 --- a/src/pages/index.astro +++ b/src/pages/index.astro @@ -94,6 +94,54 @@ const description = +
+

+ How this compares{' '} + + # + +

+ +

Why not just sandbox the agent?

+

+ Do both. A sandbox and this answer different questions: a sandbox limits what a process can + reach, and this reads what a call is actually asking for. A container will happily let an + agent curl your environment out to a webhook, because that is a normal thing for + a process to do. What it catches, this one misses; what this catches, it misses. +

+ +

Why not rely on the client's permission prompts?

+

+ A permission prompt shows you the call and asks. It does not read the result that comes back, + which is where injected instructions arrive, and it cannot tell a routine rm from + a destructive one because it is not looking at the content. This never approves anything on + your behalf, so the prompts still happen. It is a second opinion that has read the text. +

+ +

Why not just allow-list the tools you trust?

+

+ You should, and this has allow and deny lists built in. They run first, deterministically, + with no model involved. The limit is that a list names tools rather than what a call does with + them: write_file is on your list either way, whether the path is{' '} + src/auth.ts or ~/.ssh/authorized_keys. +

+ +

Why not read the tool calls yourself?

+

+ For a handful of calls, do. It stops scaling at about the point agents get useful: a single + web fetch can return forty kilobytes, and the instruction hidden in it is one sentence in the + middle. This starts in shadow mode precisely so you read your own log first and decide what + you would have wanted stopped. +

+ +

Is this just a prompt-injection classifier?

+

+ That is half of it. A classifier reads results. This also screens calls before they run, which + is the half that catches a destructive command or a secret heading somewhere it should not, + neither of which is prompt injection. The numbers below cover both directions separately. +

+
+

Two ways in{' '}