An agent can propose a tool call; application and identity controls must determine whether that action is permitted.
Published and sources reviewed: October 26, 2026 · Practical architecture guide
Keep identity outside the model
Give each tool integration a defined identity and purpose. Distinguish the user asking for work, the application coordinating it, and the service identity executing the operation. Avoid a single highly privileged credential shared across unrelated agents and environments.
The model must not mint its own authority by claiming that a user approved something. Resolve authorization from trusted application state, verify the acting identity, and constrain resource and action scope at the tool boundary.
Worked example: preparing a change
Illustrative scenario: an investigation assistant reads permitted alerts and drafts a proposed account restriction. A read-only tool collects evidence. A separate action tool accepts a constrained target and operation, validates the request, and checks an explicit approval record where the action requires it.
Approval should bind to the action, target, relevant parameters, and validity window. If those change materially, the previous approval is insufficient. Return the actual execution result and verify the resulting state instead of treating a generated completion message as proof.
Contain tool and context risk
- Validate tool parameters against a narrow schema and supported operations.
- Constrain destinations and resource identifiers; do not accept arbitrary commands.
- Treat retrieved documents and tool results as untrusted evidence.
- Use timeouts, bounded retries, and idempotency where appropriate.
- Keep credentials out of model context and tool responses.
A confused-deputy failure occurs when a more privileged component acts on an insufficiently authorized request. Delegation needs a traceable authority chain and explicit limits, especially when tools reach other business systems.
Test authority, not just task success
Attempt cross-user access, wrong-environment actions, altered parameters after approval, malicious tool output, and replay of an expired request. Test service failures and partial completion. Define a safe stop and an escalation path.
Audit records should identify the user, service identity, selected tool, authorization decision, approval reference, target, and actual outcome. Retain necessary evidence while minimizing sensitive prompt storage.
Implementation checklist
- Identify user, application, and executing service.
- Scope each tool to a clear purpose.
- Authorize outside the model.
- Bind approvals to exact consequential actions.
- Validate parameters and destinations.
- Test replay, injection, and cross-user access.
- Record actual execution and verification outcomes.