Agent Tool Authorisation
Enforcing that a tool invoked by a model executes with the requesting user's permissions rather than the application's, and that consequential actions require confirmation.
The security model of an agent is determined entirely by what its tools can do and whose authority they carry. A model that can call a database tool running with an administrative service account has been handed that account's full power, and the model's instructions are the only thing standing between an attacker and it — which is not a boundary, since natural language instructions are not an access control mechanism.
The design that holds. Tools execute with the end user's identity and permissions, so a model asked to read another customer's record fails at the data layer regardless of what convinced it to try. Each tool is scoped to the narrowest capability that satisfies its purpose. Consequential and irreversible actions — payments, deletions, external communications, configuration changes — require explicit human confirmation, with the specific action and parameters shown rather than a generic prompt. And every invocation is logged with the user, the parameters and the result.
The threat that makes this urgent rather than theoretical is indirect prompt injection: content retrieved from a document, a web page, an email or a code comment carrying instructions the model follows. The content is data and the model treats it as instruction, which is the confused deputy problem in a new setting.
The architectural conclusion: assume the model can be induced to attempt any action available to it, and design so that the worst attempt available is acceptable.