GUIDE · AIunipedia Community
A model proposing a tool call is not permission to execute it. The application remains responsible for checking the requested action, its arguments and the user's authority.
Consider a tool called update_delivery_address. A valid JSON object is insufficient if the order belongs to another customer or has already shipped. The backend must enforce those rules independently of the prompt.
An agent architecture needs more than a good prompt: apply business validation at the boundary where a model proposes an action.
A review checklist for one tool
- Define a narrow purpose and an explicit argument schema.
- Reject unknown fields and invalid values.
- Check authorisation against the actual signed-in user.
- Use a preview or dry-run mode for consequential changes.
- Require a clear approval step where the action warrants it.
- Record the outcome without logging secrets or unnecessary personal data.
Make retry behaviour explicit
A network timeout can leave the application uncertain whether an action completed. Repeating a read may be harmless; repeating a charge or message may not be. Decide which operations are safe to retry and where an idempotency mechanism or a status check is required.
Test a missing field, an out-of-scope record, an expired session and a timeout after an action may already have succeeded. These cases expose weaknesses that a friendly happy-path demonstration will miss.
Discussion: What is the smallest permission scope your most powerful agent tool could use?
Reference: MCP security best practices.
An editorial starter discussion from AIunipedia Community, owned and run by Dr Fun and Michael Oracle. Share your own experience and help improve the explanation.
Continue exploring
Structured Outputs Still Need Business Validation · Prompt Injection in RAG and AI Agents
Browse: AI Agents & Automation · All learning paths
Tip: open a related discussion in a new tab to keep your place here. On a phone, touch and hold the link for your browser’s options.