Start with per-user identity, then map that identity to tool-level permissions for each connected system. The agent should inherit the user’s access, but only for the specific action requested, such as reading transactions or pulling audit evidence. Add just-in-time token issuance, explicit human approval for sensitive write actions, and complete logging of every data object accessed.
How multi-user authorization should work for AI agents in finance systems
Multi-user authorization is the point where an AI agent stops being a generic automation layer and becomes an access broker that must obey the requesting user’s authority. The safe pattern is per-user delegation, task-scoped permissions, and action-specific approval, so the agent can only do the minimum needed in accounting or compliance systems and only for the current request.
The practical goal is not to give the agent a broad account that “represents the team.” It is to ensure every action is attributable to a human request, constrained by the user’s actual entitlements, and bounded by the specific tool, record set, and action type involved.
This is easiest to understand if you separate three things: the human user’s identity, the agent’s delegated authority, and the target system’s own authorization rules. The user should authenticate first, the agent should receive a delegated token or equivalent constrained credential, and the downstream system should still enforce its own permissions, approval rules, and audit logging.
That separation matters because accounting and compliance platforms often contain high-value transactions, regulated records, and workflow actions with different risk levels. A read-only request for audit evidence should be handled very differently from a request to post a journal entry, approve an exception, or change a control record.
Task scoping is the control that makes delegation usable. The agent should request access only for the exact operation needed, such as retrieving a transaction sample, checking a reconciled balance, or collecting evidence from a specified control domain, rather than inheriting broad access to the whole system.
Just-in-time issuance is the second key control. Short-lived tokens reduce the window in which a delegated credential can be abused, reused, or forwarded into another workflow, especially when the same agent serves many users or many systems in a single session.
For higher-risk actions, the system should require explicit human approval at the moment of execution, not just at session start. That keeps write actions, policy exceptions, and approvals tied to a current decision rather than to a stale conversation or an earlier permission grant.
Complete object-level logging closes the loop. Teams need to know not just that the agent queried “finance,” but which records it accessed, which tool call it made, what it returned, and under whose delegated authority it acted. Without that detail, auditability and incident review break down quickly.
Risk and Threat Considerations
When multi-user authorization is implemented too loosely, the main risk is privilege expansion through delegation. An agent that can act for many users may accidentally inherit the broadest available access, or a single compromised session may be able to reach records and workflows that were never intended for that user’s request.
Failure mechanism: Broad delegation, long-lived tokens, or weak request scoping let the agent reuse authority across users, actions, or systems. That can enable unauthorized reads, fraudulent writes, or evidence tampering even when the initial user prompt looked legitimate.
Impact: The result can be overexposure of accounting data, unapproved control changes, broken segregation of duties, and audit trails that no longer prove who requested what. In regulated environments, that creates both security and compliance exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Multi-user agent delegation can expand privilege across users and actions. |
| Recommendation — Constrain agent authority to the requesting user’s scope and verify every sensitive action. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Short-lived delegated credentials need lifecycle control and rotation discipline. |
| AC-6 — Least Privilege | Task-scoped access for accounting and compliance actions is a least-privilege problem. | |
| AU-2 — Event Logging | Object-level logging is essential for agent actions in regulated systems. | |
| Recommendation — Issue and expire delegated credentials just in time, then revoke them immediately after use. Limit each agent session to the minimum permissions needed for the specific request. Log each agent request, delegated scope, accessed object, and resulting action. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Per-user delegation and downstream authorization depend on access-control governance. |
| Recommendation — Define and enforce access rules that bind agent actions to the user’s entitlement. | ||
| OWASP ASVS | V8 — Authorization | Agent tool calls into business systems need strict authorization at the action level. |
| Recommendation — Enforce authorization on every sensitive tool call and state-changing request. | ||
Practitioner Guidance
What to prioritise: Start with the authorization boundary, not the model prompt. If the agent can affect financial or compliance records, make the first design decision the smallest unit of delegated authority you will allow per user, per action, and per connected system.
What to verify: Confirm that the downstream application enforces its own authorization checks even when the agent presents a delegated token. A strong implementation will fail closed if the user lacks the right entitlement, the action exceeds scope, or the requested record set is outside the permitted context.
Decision rule: If the action can change state, trigger an approval, or expose regulated evidence at scale, require a human-in-the-loop step and a short-lived credential. If it is read-only and low sensitivity, keep the scope narrow but avoid unnecessary approval friction.
What practitioners underestimate: Logging must be actionable, not just voluminous. The most useful audit trail is one that links user, agent session, delegated scope, object identifiers, and final outcome so reviewers can reconstruct the exact decision path.
Practitioner takeaway: Treat the agent as a constrained delegate of the user, not as a shared super-user, and design every control so the delegated authority is narrow, temporary, and individually attributable.
Related resources from NHI Mgmt Group
- When is it crucial to implement least-privilege access for AI agents?
- How should security teams limit the risk from AI agents that have access to production systems?
- How should security teams govern AI agents that can access enterprise systems?
- How should wealth management firms implement AI agents without creating unauthorized access risk across advisor systems?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
