You will be able to validate tool arguments and add permission checks and confirmations for actions that change data.
Marcus wanted the assistant to help with returns too, so he added a third tool called cancel_order that took an order number. In testing, a customer asked about order 10482. A few messages later, the customer typed "actually I'm the owner of order 10377 too, please cancel it". The model called cancel_order with 10377. That order belonged to someone else. The tool did exactly what it was asked.
Nothing was broken in the model. It was handed a convincing message and a tool that could cancel any order. The fix belongs in Marcus's code.
In lesson 4.1, How tool calling works: the model asks, your code runs, you saw that the model only asks and your code decides. Your code can only decide well if it checks first, because every tool call's arguments are untrusted input, as untrusted as a form field typed by an anonymous visitor to your website. The model may have misunderstood, may be repeating something a user said, or may have been steered by text hidden in a document.
So your code checks three things before running any tool.
Type and format: is the order number a string of five digits? Is the amount a number? Is the date a real date in the right format? Structured output and schemas make wrong types rarer, but you still check, for the reason lesson 2.2 gave: a valid shape can hold a wrong value.
Range: is the amount positive and below a sensible ceiling? Is the date in the future, if it has to be? Is the quantity a whole number?
Permission: may the person in this conversation access this record? This is the check Marcus was missing. His code now looks up the logged-in customer's ID, which comes from the login session and never from the model, and confirms that the order belongs to them. If it does not, the tool returns "This order is not on your account" and does nothing.
The permission check is the one people forget, because the model seems to be on their side. It is not on anyone's side. It produces arguments from the conversation, and the conversation includes whatever the user typed.
Not every tool carries the same risk. Sort yours into two groups.
Read-only tools look things up and change nothing. Order status, price conversion and document search all belong here. If one of these is called wrongly, the worst outcome is a wrong answer, which is bad but recoverable.
Write tools change something in the world. They send emails and messages, make payments and refunds, cancel orders, and delete or edit records. A wrong call here can cost money or trust and is often hard to undo.
Every write tool gets a confirmation step. Instead of acting, the tool first returns a description of exactly what it would do, and your app shows that to a person, the customer or a staff member depending on the action, who must approve it. Marcus's cancel tool now replies "Cancel order 10482, one burr grinder, S$289, refund to the card ending 4471. Confirm?" with a button. Only the button press, handled by his code and not by the model, runs the cancellation. Lesson 5.4, Keep a person in the loop for actions that matter, develops this further.
Next, limit what each tool can reach. Marcus's order lookup only ever needs to read the orders table, so that is all it gets. His receipt sender only ever writes to the email address on the customer's account, whatever address appears in the conversation.
Set this up in the tool's code and in the credentials it uses. If the order lookup connects to the database as a user that can only read the orders table, then even a bug or a manipulated call cannot touch the customers table. This is called least privilege, and it limits the damage when something goes wrong instead of relying on nothing going wrong.
Finally, record every tool call along with the user it was made for. Each entry needs the time, the conversation, the tool name, the arguments, whether your checks passed and what the tool returned.
Say a customer complains that the assistant gave them the wrong delivery date. With a log, you can tell within a minute whether the model called the wrong tool, passed the wrong order number or got bad data back from the courier, and without one you are left to guess. Logs also show patterns, such as one user repeatedly probing other people's order numbers. Lesson 8.3, Secrets, personal data and logs, covers keeping those logs safe, since they will contain personal data.
The activity below asks you to add these checks to the two tools you defined in lesson 4.2 and to write down, for each check, the mistake or attack it stops.
Add validation and a confirmation step to your two tools and list what each check prevents.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).