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: 1. **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. 2. **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. 3. **Hard limits** on size, count and length, checked before anything else. 4. **Human review** of every version, and activation action by action, off by default (section 7). 5. **Per-session fingerprint.** If your site changes the manifest, the copilot turns off until someone approves it again (section 6). 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. 7. **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". 8. **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.