Isolate provider deliverables in evaluator LLM context

[notforhumansfun-rgb]

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.}