An AI assistant does not need a wallet to cause a financial control failure. It can change a client's contact details, export a restricted report, close a case or widen another user's access. The permission question begins at the first connected business system, well before a payment is proposed.
A tool is an interface through which the assistant requests an operation. The tool's name and description tell the model what it can ask for. They do not determine what it is authorised to do. That decision belongs to the application and the receiving service, using identities and policies that the model cannot rewrite.
Separate the user, the application and the service account
A request can involve several actors: the employee asking the question, the AI application, a connector and a downstream business system. If every operation arrives under one powerful service account, the downstream system may see the application but lose the employee's scope. The assistant can then become a route around controls that still apply to the employee's ordinary interface.
Ask whose authority is being used at each step. A client-service employee may read records for assigned accounts but cannot export the entire client population. A connector that uses a broad technical credential needs to reapply that restriction before returning data. Authentication of the connector establishes its identity. It does not establish the business entitlement of every request it sends.
The Model Context Protocol authorisation specification requires token audience validation and describes separate tokens for downstream APIs rather than passing the client's token through unchanged. Audience means the service for which a credential was issued. Checking it limits the reuse of a legitimate token against a service that was never meant to accept it.
Least privilege needs a business object
A permission such as read or write is incomplete without the object and context. Read which portfolio? Write which fields? For which legal entity and for how long? A scope label that covers an entire database may be technically narrow compared with administrator access while remaining much broader than the assistant's assignment.
Prefer operations that match the business task. An assistant preparing an onboarding review might read assigned documents, create a draft finding and attach supporting evidence. It need not have a general update-client-record operation. A smaller interface reduces the number of parameter combinations that policy checks must understand.
Read access deserves its own limits. Searching across unrelated mandates, combining sensitive fields or exporting a large result can create disclosure risk without changing a record. Row limits, field restrictions, permitted destinations and purpose-bound queries can be as important as blocking a destructive command.
A hypothetical client-record change
Hypothetical example: a relationship manager asks an assistant to update the telephone number for a client contact. The employee can edit contacts for that client but cannot modify settlement instructions. A generic update tool accepts an object identifier and arbitrary fields. A document in the conversation supplies a different identifier and an instruction to replace bank details as well.
If the connector checks only that the employee has write access somewhere in the customer system, both changes may pass. The correct boundary checks the actual object, allowed fields and requested action. The contact update can proceed while settlement fields are rejected or routed into their separate approval process.
The approval screen should show the exact proposed change and the record it affects. A human clicking continue on a description generated by the same model does not independently validate the operation. The reviewer needs an authoritative view of the target record and the parameters that will be submitted.
Credentials should not carry the whole organisation
Use scoped credentials and distinct identities where the downstream system supports them. Short lifetimes limit how long a stolen token remains useful, but they do not make an overbroad permission acceptable during its valid life. Long-running tasks also need a rule for what happens when a user's access changes after the task starts.
MCP's security best practices identifies token passthrough, confused-deputy risks and scope minimisation as concrete integration concerns. A confused deputy is a service induced to use its own authority for an operation the requester should not obtain. The financial version may be an assistant using a central reporting credential to retrieve data outside a user's mandate.
Revocation tests should cross every layer. Disable the employee's entitlement, revoke a connector grant or remove the service's permission, then demonstrate what stops working. A cached session must not silently become an alternative authorisation system. Session continuity and permission continuity are different requirements.
Constrain the action after the model chooses it
Validate the tool request after generation and before execution. Check that the target belongs to the authorised population, the fields are permitted, quantities are within policy and required approvals exist. The receiving service should also enforce its own controls. A rejected tool call is preferable to depending on the model to remember a restriction every time.
Some operations need two distinct steps: prepare a proposed change, then submit an approved change. Bind the approval to a stable representation of the operation so that later edits invalidate it. Otherwise the user may approve one recipient or record while the application executes another.
There is a practical cost to fine-grained controls. Too many scopes confuse users, frequent approval requests become routine and legacy systems may offer only coarse service credentials. Those limitations should affect the automation boundary. Where precise enforcement is unavailable, a narrower task or a controlled human submission may be the more workable design.
Tool discovery should follow the same ownership discipline. Adding a connector or changing its advertised operations can expand the application's reachable authority. Require review of the new capabilities and their enforcement rules before exposing them to existing workflows, even when the underlying employee permissions remain unchanged.
Make permission failures measurable
Evaluation should include attempts to access another client's record, unexpected field updates, revoked users, expired credentials and requests that span multiple systems. Include concurrency: two legitimate operations can create an impermissible combined result if both check an outdated state. Test the permission system directly, rather than relying exclusively on model conversations.
Logs should connect the initiating user, task, connector identity, requested action, policy decision, approval and downstream result. Avoid placing raw secrets in those logs. A record saying that the assistant called a tool is less useful than a record showing which authority permitted the action and which policy version evaluated it.
AI agent spending delegation addresses a related financial mandate, but tool authority has a wider scope: records, disclosures and operational state. The control of institutional access onchain poses a similar ownership question. An institution should be able to name the party that can grant, narrow and revoke each capability before it gives that capability to software.