Your manifest is text that you send, and the assistant that uses it is a language model — something that can be manipulated if no guardrails were put in place. This is exactly what each layer prevents, explained without jargon:
- It’s data, never an instruction. Your manifest isn’t pasted verbatim into what the AI model reads — it goes through the same anti-injection filter any other tool in the system uses first. A label that said “ignore your previous instructions” would arrive stripped of that attempt.
- Closed vocabulary. Only the field, action and anchor types in this manual exist — anything else is rejected with the exact reason, never a generic error.
- Hard limits on size, count and length, checked before anything else.
- Human review of every version, and activation action by action, off by default (section 7).
- Per-session fingerprint. If your site changes the manifest, the copilot turns off until someone approves it again (section 6).
- The plan is validated on the server against your approved manifest: the assistant can only reference ids that really exist there, with values of the right type — and any action that saves always comes out marked for confirmation, whatever the plan says.
- The SDK itself requires confirmation, in case the server were to fail — it’s its own dialog, never a function your site hands it that could always return “yes”.
- Origin and session are bound together. The manifest is only accepted from your channel’s allowed origins, and a result is only accepted for the plan and session that requested it — never from another tab, another visitor or another tenant.