§6.4: add page-enforced write boundaries as a mitigation for agent over-reach

[minjikim89]

§6.4's mitigations all address one direction: a site misleading an agent (input-length limits, shared attack evals, untrustedContentHint). §6.3.2 Current Gaps ends with "no verification mechanism … no behavioral contracts … agents must assume good faith from site developers."

The reverse direction has no listed mitigation: an agent, misled or simply over-eager, exceeding the scope a person delegated on a site that exposed write tools. That is the direction prompt injection actually exploits: the injected instruction lives in the site's content, and the damage lands on the site's own data.

Proposal

Name, in §6.4, a mitigation that does not depend on the model resisting injection. The page enforces, in the tool implementations:

• (a) a person-owned write scope. Writes outside it are refused with a structured error naming the allowed targets.
• (b) optimistic concurrency against the person's own edits. Writes over changes the agent has not read are refused with a diff.
• (c) page-owned cancellation for long-running writes, so a stop reports what landed.

The point is that none of these ask the model to behave. They are ordinary preconditions in the tool body, and they hold whatever the agent believes.

Measured

scripts/guardrail-eval.mts hands a model the same tool contracts the page registers and dispatches to the same implementations, with the guards on and off. Scale, stated plainly: one task, one site, two models, ten runs per arm.

arm	wrote over an unread hand edit	task completed
gpt-4.1 · guards ON	0/10	10/10
gpt-4.1 · guards OFF	10/10	10/10
gpt-5.4 · guards ON	0/9	9/9
gpt-5.4 · guards OFF	8/8	8/8

gpt-5.4 lost 3 of 20 runs to network errors, which were excluded; hence 9 and 8.

Two honest notes on the injection scenario. First, on gpt-4.1 the model followed the injected instruction in 0/10 runs with the guards on and 0/10 with them off, so it did not distinguish the arms, so that run says nothing about the guards. That is why a second, model-free arm exists: a scripted agent that follows the injection by construction rewrote 8 of 9 unmarked slides with the guards off and 0 of 9 with them on. The claim is about the page refusing the write, not about a model resisting a prompt.

Raw results (including a handEditSurvived field that is false in both arms, because the task is to rewrite that very field): https://github.com/minjikim89/redline/tree/main/evals/results

Where this sits, and what it does not cover

• Proposal: [Section 3] Address agent-to-tool trust — identity, scoped permissions, and delegation context #96 asks the platform for agent identity and granted scope so a tool can know who is calling. Complementary: this proposal needs neither, because the scope is authored by the person on the page and enforced locally. If Proposal: [Section 3] Address agent-to-tool trust — identity, scoped permissions, and delegation context #96 lands, these guards get better inputs; they work without it.
• A user agent that both invokes tools and automates the page can complete the page's own human-approval step #288 reports an agent that both calls tools and automates the page completing the page's own approval step. That is a real limit on what is proposed here: guards in the tool implementation bind the tool path only. An agent that can synthesize clicks can edit through the UI and never touch a tool. So this mitigation raises the floor for tool-mediated writes; it does not survive a user agent that also drives the page. Worth saying in §6.4 rather than leaving implementers to discover it.
• No structured way to signal a tool's refusal, distinct from success or a schema-validation error #282 (structured refusals) is the shape these refusals want to be returned in.
• WebMCP loses important context when tools appear or disappear #262 (context lost when tools appear or disappear) is the read-side counterpart.

Implementation and error shapes: https://github.com/minjikim89/redline/blob/main/docs/pattern.md
Full notes from building against the spec: https://github.com/minjikim89/redline/blob/main/docs/findings.md
Live: https://minjikim89.github.io/redline/

[minjikim89]

A correction to the top of this issue: §6.4 now lists four mitigations, not three. consequentialHint (Consequential Annotation for Tool Executions) landed in #217 on 2026-09-03, before I filed. I missed it.

It does not change the proposal, and it makes the line a bit clearer. consequentialHint runs in the same direction as the rest of §6.4. The page declares something about itself, and a client or agent decides what to do with that declaration. Its effect depends on that decision. An agent that ignores the hint still books the flight.

What is proposed here is not a declaration. (a), (b) and (c) are preconditions inside the tool body, and they refuse the write whether or not an annotation was honored. An agent that ignores an OUT_OF_SCOPE refusal does not get the write, because the write never happens.

So the two compose rather than overlap. Annotations tell a cooperative agent what to be careful with. Page-enforced boundaries hold when the agent is not cooperative, or is cooperating with someone else's injected instruction.