Knowledge & actions · Explore this field ↗ · Implementation · 2 min read
Tools need permissions, not personality
Treat every external action as a typed, authorized transaction.
The model is not the permission system
A language model may select a tool and draft arguments, but authorization belongs in application code. Tools should accept narrow schemas, validate values, and enforce account and role boundaries independently. Read operations and write operations need different scopes. Administrative or irreversible actions deserve stronger authentication and often human review.
Confirm the consequence
Before a consequential call, show the exact action in user language: amount, recipient, date, account, cancellation effect, or data to be shared. Confirmation should bind to those arguments, not to a vague ‘yes.’ After execution, return a receipt from the system of record. If a timeout leaves status uncertain, say so and check idempotently rather than retrying blindly.
Assume instructions can be hostile
User messages, retrieved pages, tool outputs, and attachments can all contain instructions that try to redirect the agent. Separate data from instructions; constrain tool access; treat external content as untrusted; and inspect outputs before they flow into another privileged call. The OWASP LLM guidance treats prompt injection and excessive agency as application risks, not prompt-writing mistakes.
Operator note
Maintain a tool register with owner, schema, scopes, side effects, confirmation rule, idempotency key, timeout behavior, and rollback path. Test malformed arguments, duplicate calls, stale confirmation, cross-account access, and malicious retrieved text.
Design a narrow tool
Instead of exposing a general customer-record API, create a task-specific operation such as propose_shipping_address_change. Require account scope, order identifier, candidate address, eligibility result, and a request ID. Return a typed status rather than prose. A separate confirmed operation can apply the exact proposal after authentication. This two-step shape gives the interface something concrete to review, limits what injected instructions can reach, and leaves an audit trail. It also makes safe simulation possible in evaluation without touching production records.
Primary reading
Sources and limits
These links support the architecture, policy, or product behavior discussed above. Vendor documentation describes vendor features; it is not independent proof of performance. Current details should be rechecked before a production decision.