Tools and their safe contracts
Practice this questionWANT TO UNDERSTAND THE CONCEPT FIRST?Learn Tools and their safe contracts
| Tool | Arguments from model | Trusted server context/checks | Minimal result | Failure behavior |
|---|---|---|---|---|
| Customer lookup | Customer reference if needed | Tenant, caller, permitted customer relationship | Permitted display/profile fields | Deny access without leaking existence |
| Policy lookup | Policy ID or safe selector | Ownership, validity, allowed product/region | Policy/version IDs and permitted summary fields | Clarify selector or return unavailable |
| Claim status | Claim ID | Tenant, policy/customer ownership, read scope | Status code, safe reason, required-doc types | Denied, not found under safe policy, or transient unavailable |
| Create claim | Approved draft reference | Exact approval, current rules, idempotency key | Claim ID and durable receipt | Reject invalid draft; reconcile unknown commit |
| Email draft/send | Draft ID / permitted recipient selection | Role, consent, recipient/attachment/content checks, send approval | Draft or message receipt | No send on invalid approval; reconcile uncertain send |
| Document search | Bounded query | Tenant, document ACLs, policy/version/date filters | Bounded excerpts and source IDs | No evidence versus retrieval failure kept distinct |
- Never accept a model's
customerIdas proof of the current customer. - Never let the model supply an unrestricted email URL, SQL query, database filter, or role field.
Adapted from 13_AI.MD · “Tools and their safe contracts”. Code examples are study fragments. Difficulty and core labels are editorial estimates; version-specific behavior should be checked against your project.