Separate AI Read and Write Tools
Split AI read and write tools by effect, with separate authorization, approval, and synthetic denial tests.
A single tool called manageCustomer hides too many decisions. An agent that only needs to look up an account should not receive the same route that can change its owner or close it. Split the interface by effect before you add prompts or approval text.
Start with a real workflow. List the data the agent must read and the state it may change. A "read" is still sensitive if it returns keys, private messages, or another tenant's records. Classify based on the handler's behavior and the data it exposes, not the HTTP verb or tool name. OWASP's secure MCP guidance calls for strong authorization and validation around tool execution.
Tool split worksheet
| Tool | Minimum input | Default decision | Required proof |
|---|---|---|---|
getInvoiceStatus | Invoice ID | Allow for its owner | Own invoice appears; other tenant denied |
listCustomerInvoices | Customer ID | Hold until tenant filter is checked | Results contain only owned markers |
sendInvoiceReminder | Invoice ID and recipient | Approval required | No message before exact approval |
refundInvoice | Invoice ID and amount | Deny by default | Tool absent from initial catalog |
This table is a design example, not a recommended production grant. Replace each row with the team's own authorization rule. Give read and write tools different upstream credentials when the provider supports separate scopes. If it does not, enforce separation in the server and record the residual risk. Never rely on a model's promise not to call a tool.
Bind write approval
For writes, bind approval to the exact action, object, and arguments. The server should reject a changed amount, recipient, or tenant after approval. A confirmation sentence in the model context is weaker than a server-side check. Add idempotency or duplicate protection where retries could repeat an effect.
Test the split with synthetic accounts. Try a read-only caller against every write tool, a writer against an unrelated tenant's object, and a call with missing identity. Check the database or external service for side effects, not only the tool response. Reconcile the published tool list with the actual registered handlers before each release. That catches an accidental write operation added under a harmless name.
Know what your agents can reach
Map data access, tool actions and approval boundaries before testing. Use the scope guide, or discuss a review of your AI application.
Sources
- OWASP Top 10 for LLM ApplicationsAccessed
- MCP Authorization SpecificationAccessed