Tool calling introduces real side effects, so tools should have narrow permissions, exposing only the actions and data needed for the task. This limits damage from mistakes or prompt injection by reducing what a compromised tool call can do. Closely related is the tool schema, which describes the tool name, inputs, required fields, and allowed values. Clear schemas reduce malformed calls and unsafe ambiguity, and a common mistake is making tool parameters too broad or poorly described.
Beyond permissions, applications must defend against adversarial use through red teaming, which deliberately tests an LLM app with adversarial or unusual inputs. Red teaming reveals vulnerabilities before users or attackers find them, and only testing happy-path prompts is a common mistake that leaves obvious gaps unexamined. Designers should bring the same discipline to red teaming that they bring to functional evaluation, treating unexpected inputs as a first-class test case rather than an edge case.
PII handling is another essential practice, defining how personal data is collected, masked, stored, and sent to models. It protects users and reduces compliance risk, and a common mistake is sending sensitive data to tools or logs unnecessarily. Each of these safety practices benefits from the same general approach: apply the technique to a small realistic example, explain the decision out loud, and check whether the result matches the intended outcome. Before acting, the guiding question is what problem is being solved, what trade-off is being made, and how the team will know it worked.