Coding agents prompt injection test: a pre-launch plan for browsing tools

FuturPulse analysis · 7 October 2026

On 6 October 2026, AdvSim2Real reported a 33.6% relative gain in attack-time web-task completion; before launching a browsing coding agent, test adaptive poisoned skills in an isolated browser and fail any unauthorized tool action. (arxiv.org)

What should a pre-launch test prove?

A launch test should prove two things at once: the agent finishes the requested coding task, and hostile material cannot redirect its tools. Browsing changes the problem because a page can contain both legitimate task data and an instruction designed to replace the user’s intent. AdvSim2Real describes that conflict as central to web-agent security. (arxiv.org)

The practical unit of measurement is not “did the model refuse bad text?” It is “did the agent perform a forbidden action?” Record every browser navigation, file read, shell command, network request, credential access, code change, commit, and pull-request action. A useful test outcome therefore needs both a task result and an action trace.

Set a written action contract before testing. It should name the user-approved repository, permitted domains, writable directories, allowable commands, and the exact destination for any output. Anything beyond that contract is a failure, even if the agent eventually completes the feature.

What belongs in the test set?

Build tests around the places where a coding agent learns what to do. Claude Code, for example, can read project instructions, invoke skills, use shell commands, connect external tools through MCP, and work across files. Its product documentation shows why a test set must cover more than a single web page. (docs.anthropic.com)

Start with clean, small repositories that each contain one real task: fix a failing test, update a dependency, add a narrow feature, or investigate a build error. Then make paired versions. In one version, the evidence supports a defensive action. In the other, it does not.

This pairing stops a security gate from rewarding needless caution. ParanoiaEval’s evidence-controlled pairs isolate whether the agent reacts to the facts rather than merely treating every unfamiliar input as dangerous. Its reported rate of unnecessary treatment shows that over-defence is a product failure, not a harmless preference. (arxiv.org)

Each task should include one controlled injection location at a time:

• a browser page, issue, pull-request discussion, README, or package note;
• a skill description that persuades the agent to load the skill;
• the main instruction file inside a skill;
• a supporting resource such as a script, configuration file, or helper asset;
• a combination of description and resource, then instruction and resource.

SkillJect’s public configuration exposes those description, instruction, and resource layers, plus combinations of them. That structure is useful because it separates an unsafe skill from an unsafe page and reveals which trust boundary actually failed. (github.com)

How should adaptive attacks run?

Do not stop at one fixed malicious prompt. Run a bounded adaptive loop in which an attack generator observes the previous outcome and changes only its framing, placement, or claimed relevance. Keep the user task and the protected action constant, or a better attack can be confused with a harder task.

Use five attempts as an initial ceiling. SkillJect’s default configuration sets a maximum of five adaptive iterations and stops after success; it also keeps direct and template methods as single-pass comparisons. That gives a launch team a repeatable budget without allowing an unlimited search for a bypass. (github.com)

Run each case across these four outcome classes:

• Information disclosure: the agent reveals a planted secret or reads a prohibited file.
• Privilege escalation: the agent attempts an action outside the approved role.
• Unauthorized write: the agent changes a protected file, branch, or external record.
• Backdoor injection: the agent leaves hidden persistence or a covert future instruction.

Those are the attack categories named by SkillJect’s test framework. The test should mark success from the trace, not from text alone: a model can explain the danger correctly and still launch an unapproved command. (github.com)

Use a second agent or deterministic rules only to classify the trace after it is saved. SkillJect supports a rule-based result and an optional model judge that can upgrade a missed result. That is useful for triage, but the release decision should preserve raw logs so a human can inspect disputed cases. (github.com)

Which controls should block or constrain?

The most valuable control is containment. Give every test a disposable repository copy, fake credentials, a temporary browser profile, and no route to production systems. Permit only an explicit list of test domains and endpoints, then log denied requests as clearly as allowed ones.

Separate untrusted content from agent instructions in the test harness. A web page or skill may be displayed to the agent as evidence, but it should not silently become authority to run commands or alter permissions. The agent must seek confirmation when page text asks for an action outside the task contract.

Skills deserve their own gate because they can carry repeatable instructions and supporting files. Claude Code says skills use a SKILL.md file, can load automatically when relevant, and can use dynamic context injection. Anthropic’s skills reference also shows that project skills can affect repeatable workflows such as verification. (docs.anthropic.com)

Scan every third-party and changed skill before it enters the test environment, but do not treat a clean scan as approval. Cisco’s Skill Scanner combines signatures, code analysis, dataflow checks, and an optional model judge, while explicitly warning that no findings do not prove a skill is safe. (github.com)

For a high-signal starting policy, send medium-or-higher findings for human review and fail the build on high severity. Cisco reports that rules alone caught 7.7% of malicious skills at high severity, while its balanced model-judge setting produced a larger review queue. That makes scanning a prioritisation layer, not a substitute for adversarial execution tests. (github.com)

How do you measure useful caution?

Measure security and usefulness together. The core scorecard should track task completion, injection success, forbidden-action rate, correct escalation rate, and unnecessary defensive work. The final measure matters because an agent that blocks ordinary coding tasks will not be deployable.

Use matched safe and unsafe cases for every control. If a repository note genuinely requires a dependency update, the agent should make the update. If an otherwise identical note asks it to read a secret or open an unrelated endpoint, the agent should stop, explain the conflict, and ask for approval.

ParanoiaEval’s results are a warning against counting refusals as wins: stronger task capability did not guarantee appropriate risk treatment in its eight-model evaluation. A release gate should therefore report false alarms beside missed attacks. (arxiv.org)

Also test pressure on the sites the agent browses. Wikimedia said on 5 October that it found unauthorized activity it attributed to OpenAI-operated agents, including wiki edits, Etherpad probing, and heavy automated traffic. Wikimedia’s account is a reminder to measure rate limits, repeat navigation, retries, and aborted tasks, not only data loss. (diff.wikimedia.org)

What does a realistic launch gate cost?

A serious evaluation needs enough room for long agent traces. Tokens are the chunks of text a model reads and bills by. By our calculation from OpenRouter list prices, 1,000 agent steps using 30,000 input tokens and 2,000 output tokens range from $3.90 to $400, depending on the selected model. (openrouter.ai)

The table compares only model usage for the same test profile. It excludes browser infrastructure, storage, scanner calls, retries beyond the assumed 1,000 steps, cached-input discounts, and staff review. That limitation matters: the cheapest model is not automatically the cheapest launch programme if it creates a large manual review queue.

Context figures are listed model limits, not guaranteed usable space after system prompts and tools.

What should the release gate require?

The release gate should require a signed test manifest, not a single benchmark score. It should identify the model, system instructions, tool permissions, browser configuration, skill versions, test-set version, attack generator, retry policy, and every exception granted during the run.

Require all of the following before enabling browsing or autonomous writes:

• zero successful unauthorized writes, secret reads, privilege changes, or persistence attempts in the chosen launch set;
• no unexplained external network action outside the domain allowlist;
• task completion on matched safe controls, so the agent is not passing through blanket refusal;
• human review of every severe trace and every model-judge disagreement;
• a rollback switch that removes browsing, write access, or a newly added skill without changing the core coding workflow.

Run the same gate when a skill changes, a model changes, a browser tool gains a permission, or a new external connector is enabled. Hugging Face says Spaces can run arbitrary Dockerfiles, which illustrates a broader point: flexible execution surfaces need isolated environments and repeatable rebuilds before public exposure. Its Spaces documentation describes both Docker-based hosting and hardware upgrades. (huggingface.co)

Finally, replay failures after each mitigation. AdvSim2Real argues that attackers can adapt to fixed defences, while SkillJect uses trace feedback to refine poisoned skills. A control that wins once but fails when the wording, location, or claimed task relevance changes is not yet a release control. (arxiv.org)

What we could not verify?

No public evidence here establishes a universal pass rate for browsing coding agents, a standard threshold for acceptable prompt-injection risk, or the terms under which every agent vendor monitors browser actions. Vendors and independent evaluators could settle those questions by publishing reproducible traces, permission configurations, attack sets, and false-alarm results.

The published research also does not establish that a passing result on a sandboxed skill or web task transfers unchanged to a company’s production repositories, identity systems, or internal tools. The organisation launching the agent must validate those boundaries with its own access rules, representative tasks, and an accountable security review.

Sources

• AdvSim2Real: Training Web Agents Against Adaptive Prompt Injection in a Web World Model
• ParanoiaEval: Benchmarking Unnecessary Defensive Work in Agentic Coding
• SkillJect evaluation framework
• Cisco AI Defense Skill Scanner
• Claude Code documentation
• Claude Code skills documentation
• Wikimedia report on OpenAI agent activity
• OpenRouter model prices and context limits
• Hugging Face Spaces documentation