The trust boundary

This page explains what Pilotage makes checkable and what remains a matter of trust.

Pilotage makes a cooperative server's claims structured and checkable; it does not prove that the server is honest.

Guides, catalog entries, diagnostics, plans, risk labels, traces, and narration all come from the server. A conformant Client can check their shapes, branch on closed codes, enforce a risk gate, and compare a plan with a trace. It cannot independently prove that an untrusted server reported every effect or labeled risk correctly.

Harborview illustrates the distinction. Its execute tool advertises:

{
  "readOnlyHint": false,
  "destructiveHint": true,
  "openWorldHint": true
}

A specific catalog entry provides more precise Pilotage risk:

{
  "id": "notify.facilities",
  "risk": "external_side_effect",
  "risk_hints": {
    "readOnly": false,
    "destructive": false,
    "openWorld": true
  }
}

The Host gate uses risk_hints, not tool annotations or prose. Even then, the value is a Harborview claim. Authentication, authorization, sandboxing, independent monitoring, and infrastructure policy remain outside Pilotage.

Teaching text is also data, not Host authority. A guide sentence cannot modify policy, bypass approval, or force another tool call. Hosts should apply the same injection defenses used for other untrusted model input.

After execution, mission verification rests on the structured trace envelope, not narration or a model's self-report. Against an honest engine, that is the evidence needed to catch wrong branches and incomplete work. Against a dishonest engine, it remains only the engine's account.

Formal rules: Part II §9, Trust model, Part II §10, Security requirements, and Part II §7.3, Host risk gate.

Next: The plan and risk · Execution and traces