# MCP tool permissions: check user, record and field

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.

## Copyable prompt

```text
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.
```

## Checklist

- Resolve identity from trusted authentication.
- Check the exact target record.
- Allow only explicitly permitted fields.
- Reject empty, unknown or mixed forbidden updates.

## Further reading

[MCP: security best practices](https://modelcontextprotocol.io/specification/latest/basic/security_best_practices)