Skip to content

Isolate provider deliverables in evaluator LLM context - #44

Open
notforhumansfun-rgb wants to merge 1 commit into
Virtual-Protocol:mainfrom
notforhumansfun-rgb:fix/evaluator-deliverable-boundary
Open

notforhumansfun-rgb wants to merge 1 commit into
Virtual-Protocol:mainfrom
notforhumansfun-rgb:fix/evaluator-deliverable-boundary

Conversation

@notforhumansfun-rgb

@notforhumansfun-rgb notforhumansfun-rgb commented Aug 26, 2026 •

Copy link
Copy Markdown

Addresses #40.

What changed

  • escape provider-controlled deliverables before placing them in the evaluator transcript
  • wrap the escaped text in an explicit <untrusted_provider_deliverable> data boundary
  • tell the evaluator not to follow commands, role changes, or tool requests inside that block
  • replace the buyer demo’s Never reject / Complete any deliverable defaults with requirement-based evaluation
  • document that structural delimiters reduce boundary confusion but do not prove correctness or eliminate model-level prompt injection
  • recommend a distinct evaluator for value-bearing jobs
  • add a regression containing an injected closing tag plus complete() lure

Security reasoning

The provider artifact remains visible to the evaluator, but it can no longer close the SDK’s boundary marker and re-enter the surrounding control text verbatim. This is defense in depth, not a claim that XML escaping makes an LLM safe. Role/status gating still controls which tools exist; correctness and value release should remain independently evaluated.

Verification

  • npm test — regression passes
  • npm run build — TypeScript build passes
  • git diff --check — clean

The repository’s current lockfile is not changed; it was already out of sync for npm ci because utf-8-validate@5.0.10 is missing from the lock.


Note

Medium Risk
Changes evaluator-facing LLM transcript formatting for submitted jobs (behavioral for LLM integrations) but does not alter on-chain completion logic; risk is mainly mis-tuned evaluator prompts or over-reliance on escaping as a security guarantee.

Overview
Hardens evaluator LLM prompts against provider-controlled deliverables by changing how JobSession.toMessages() formats job.submitted events.

Provider text is now HTML-escaped and wrapped in <untrusted_provider_deliverable> with explicit guidance to treat it as data only—not instructions or tool calls. The LLM buyer example drops “never reject / complete any deliverable” in favor of requirement-based complete() / reject().

Docs (main README, migration guide, LLM example README) spell out the evaluator trust boundary: delimiters are defense in depth, not proof against prompt injection; value-bearing jobs should use a separate evaluator and independent verification.

Tooling: npm test runs Node’s test runner over tests/**/*.test.ts, including a regression where a fake closing tag and complete() lure must appear escaped, not verbatim.

Reviewed by Cursor Bugbot for commit cc39151. Bugbot is set up for automated code reviews on this repo. Configure here.

Verification refreshed September 30, 2026

At head cc391518, upstream main (2b45a88f) is already an ancestor of this branch and GitHub reports it mergeable. No rebase or conflict-resolution commit is needed.

  • npm test: 1 regression passed.
  • npm run build: passed with Node 22.23.2 / npm 10.9.8.
  • git diff --check: passed; the checkout remains unchanged.
  • A clean npm ci --ignore-scripts still fails because the pre-existing lockfile lacks utf-8-validate@5.0.10. For this local verification, dependencies were installed with npm install --ignore-scripts --package-lock=false; the lockfile was not modified. This is not a claim that a locked clean install passes.

These tests verify transcript escaping and TypeScript compilation, not resistance to every model-level prompt-injection attack. The existing Cursor Bugbot check is successful; no maintainer review is recorded yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant