docs(skill): say that page content is data, never instructions - #289
Conversation
Both skills tell the agent to read arbitrary pages — observe, get-html, snapshot, screenshot, console, network — inside the user's real, logged-in profile, and neither says that what comes back is untrusted. A repo-wide search found no prompt-injection guidance in any markdown; the only place page data is labelled untrusted is a protocol comment in bsk-protocol that the agent never sees. The absence stands out because the skills already constrain behaviour elsewhere: never extract credentials, never evaluate secrets, never record banking or SSO pages. Untrusted page content is the same class of rule and was simply missing. States it where the reading happens, in both skills, with a pointer from the standing rules at the top of each. Names the read commands and the element names and labels that get passed back to click/fill/select, since those carry page text too, and says what to do instead: stop, tell the user what the page tried, do not comply. AGENT_INSTALL.md asks the installing agent to repeat it to the user, because the person granting access to their logged-in browser should know a page cannot redirect the agent, and that an agent appearing to follow one has been injected rather than instructed. Documentation only; no behavioural or technical mitigation. The reporter's further suggestions — delimiting tool output, a domain allowlist, a consent-to-consequence step — are deliberately left out of scope. Fixes Tencent#286
|
Firstly, thanks for your good PR ! The current text treats requests to send data, approve something, install something, or visit another site as injection attempts unconditionally. Those can also be legitimate parts of the user’s request—for example, submitting an authorized form or following a link to external documentation. The boundary should be whether page content attempts to override instructions or expand the user’s authorization, rather than the type of action it mentions. Suggested wording for both skills:
Please also align AGENT_INSTALL.md with this distinction. In particular, describe what the agent must not do, rather than implying that a page cannot redirect it: this change adds behavioral guidance, not a technical guarantee against prompt injection. |
Raised in review by @iuyo5678, and the objection is right. The first wording listed actions - send data somewhere, approve something, install something, visit another site - and called any page mentioning them an injection attempt. Those are ordinary parts of authorized work. An agent following that rule would refuse to submit a form the user asked it to submit, or to follow a documentation link the user asked it to read, and would report the page as hostile for containing a button. The test is whether the page is trying to change what the agent may do, not what kind of action it names. The text now says that, and says explicitly that navigation guidance, controls and quoted examples are not by themselves evidence of injection. AGENT_INSTALL.md also claimed "a page cannot redirect the agent". That reads as a technical guarantee and none exists: nothing stops a page carrying text aimed at an agent. It now describes what the agent is required not to do - let page content override its instructions, grant it permission, or widen its task - and names the guidance as behavioural. Both skill files carry the same wording, as before.
|
@iuyo5678 thank you, and you are right on both points. Pushed in The action list was the wrong test. I had written that a page telling the agent to send data somewhere, approve something, install something or visit another site is an injection attempt. Those are ordinary parts of authorized work. An agent following that rule would refuse to submit a form the user asked it to submit, or to follow a documentation link the user asked it to read, and would report the page as hostile for containing a button. That is a worse failure than the one I was trying to prevent, because it breaks the normal case rather than an attack. It now turns on authorization, close to your wording:
I kept your "pause the affected step if safe continuation is unclear" — it is better than a flat stop, which would strand the user mid-task on an ambiguous page.
Both skill files carry the same wording, as before. |
Keep the DSH guidance within the existing prompt budget and use CLI action names in the CLI skill.
Condense the DSH guidance while preserving its authorization boundary and recovery behavior. Keep the existing 7000-character limit after combining the PR with main's recovery instructions.
3 participants
Fixes #286.
Verified the report before writing anything
@TianjinAI's evidence holds at
fa953dc. Re-running their searches on a fresh clone:One hit, about
BSK_HOMEpermissions, unrelated to page content. And the one place page data is labelled untrusted iscrates/bsk-protocol/src/tools/record_v2.rs:13— a Rust doc comment the agent never reads.The gap stands out precisely because the skills are careful elsewhere: "Never extract credentials, cookies, tokens, or other secrets", "Never evaluate secrets", "never record banking, SSO or password-manager pages". Untrusted page content is the same class of rule and was simply absent.
What this adds
The rule goes where the reading happens — the top of Read and interact in both skills — with a one-line pointer from the standing rules at the top of each file, so an agent that only reads the header still meets it.
It names the commands that return page text (
observe,get-html,snapshot,screenshot,console,network) and, separately, the element names and labels handed back toclick/fill/select—TargetDescriptorV2already documents those as untrusted page text internally, so an agent passing them around is moving page-controlled strings whether or not it realises.It also says why this tool is different from an ordinary fetch: the read happens inside the user's real, logged-in profile, so a page that redirects the agent acts with their sessions.
AGENT_INSTALL.mdasks the installing agent to repeat it to the user. Someone granting access to their logged-in browser should know a page cannot redirect the agent, and that an agent which appears to follow one has been injected rather than instructed — otherwise that behaviour reads as a malfunction rather than a defence working.Scope
Documentation only. No sanitisation, no provenance marking, no allowlist. @TianjinAI's further suggestions — delimiting
observe/get-htmloutput, an optional domain allowlist, consent-to-consequence before consequential actions in a borrowed tab — are deliberately out of scope here; they are design decisions for the maintainers, and a missing rule is worth closing on its own.Wording follows the issue's suggested text, tightened to the skills' existing imperative voice.
Checks
Re-running the report's own greps after the change:
untrusted|injection|maliciousskill/SKILL.mdpackages/dsh-plugin-browserskill/skill/SKILL.mdAGENT_INSTALL.mdMarkdown only; CI here builds and tests Rust, so nothing in this diff is exercised by it. I have not run the skills against a live browser — there is nothing executable to run.