Tool access changes the security model
The moment an AI agent can call a tool, security is no longer only about generated text. The model may be able to read files, query databases, send messages, call business APIs or modify external systems.
Use least privilege
Each tool should expose the smallest set of operations required for the agent's role. Separate read actions from write actions, restrict resource scope and avoid giving the agent general-purpose credentials when a narrow token or service account can be used instead.
Validate outside the model
The model should not be the final authority for sensitive tool parameters. Application code can enforce allowed destinations, maximum amounts, permitted record types, safe filesystem locations and other business rules before an action executes.
High-risk tool patterns
- Arbitrary shell or code execution.
- Unrestricted filesystem access.
- Broad database write permissions.
- Tools capable of sending money or making purchases.
- Messaging tools that can contact arbitrary recipients.
- Administrative APIs with account-wide privileges.
Test tool abuse directly
Adversarial testing should attempt to persuade the agent to use tools outside their intended purpose. A strong design should remain safe even when the model produces an incorrect or manipulated tool request.
Frequently asked questions
Why should tool parameters be validated outside the model?
Model output can be incorrect or manipulated. Independent application validation ensures sensitive operations remain inside deterministic security boundaries.
What is least privilege for an AI agent?
It means giving the agent only the specific access and operations required for its task, rather than broad credentials or unrestricted tools.