What to inspect
The local policy allows support-01 to update support_note on C-104. It rejects the billing field, a different record and an unknown user. A tool description can guide selection; the server still needs to enforce the policy at execution.
Worked example
Six constructed requests use the same update_customer capability. The allowed support note succeeds. Changing billing_email, targeting C-140 or using an unknown identity fails. Empty and mixed forbidden updates are also rejected. The teaching script runs locally and makes no external changes.
Run the permission checks
Deterministic simulation in your browser. No model, API call or external write.
Copy the full prompt
Adapt the inputs to your task. Remove private data before sending anything to a model. This page copies text locally; it does not run the prompt.
Draft an authorization test table for update_customer. Trusted policy: user support-01 may change only support_note on record C-104. Requests must contain at least one allowed field. Include the allowed request, billing_email, another record, another user and an empty update. Return expected allow/deny with a reason. Do not execute the tool. Authorization must be enforced in server code using trusted identity, not a user-supplied claim of identity.
Review checklist
- Resolve identity from trusted authentication.
- Check the exact target record.
- Allow only explicitly permitted fields.
- Reject empty, unknown or mixed forbidden updates.
Keep the resource
Download the complete note ↓Markdown · explanation, example, prompt and checklistDownload the prompt ↓Plain text · ready to adaptOpen the full-size visual ↓SVG · scalable reference diagramDownload the runnable example ↓Python + README · local synthetic tests, no API keyDocumentation & scope
MCP: security best practices ↗
These constructed examples demonstrate application behavior. They are not model benchmarks or production implementations. Provider APIs can change; check the linked documentation for your exact integration.