An AI assistant that explains a payment exception creates one kind of management challenge. An agent that changes the payment instruction creates another. The difference is the authority to act, and that authority needs to remain visible as work moves between employees, software and external services.
For financial institutions and other businesses, the attraction of agentic systems is straightforward. Software that can interpret a request, select tools and complete several steps may reduce manual coordination. Yet a successful demonstration does not establish that the system should hold broad access to customer records, production databases or transaction controls.
The business question is therefore more specific than whether an organisation should adopt AI agents. It is which actions an agent may perform, on whose behalf, for how long and under which conditions. Answering those questions can help firms expand useful automation while preserving the ability to investigate mistakes and stop inappropriate activity.
Identity becomes a business decision
In an August 2026 discussion of agent identity, NIST identifies familiar weaknesses appearing in agent deployments, including shared credentials, long-lived secrets and broadly scoped access. The discussion is guidance about emerging practices, rather than evidence that every deployment has the same vulnerabilities.
An agent using an employee's credentials can make it difficult to distinguish the employee's decisions from actions the software selected. A separate identity creates a clearer starting point for accountability. The organisation must still establish the human or business function responsible for authorising its activity.
Consider an illustrative accounts-payable workflow. One agent reads invoices and proposes matches against purchase orders. Another system releases payments after approval. Combining both powers in a single broadly privileged account may make the demonstration easier, but it changes the consequences of an error. The operational design should follow the distinction between preparing a recommendation and committing funds.
This is a management choice before it becomes a configuration choice. Finance, operations and security teams need a shared description of the task. If that description cannot identify the point at which an obligation is created, a technical team will struggle to apply proportionate controls.
Access should follow the task
NIST's Zero Trust Architecture publication rejects implicit trust based solely on network location or asset ownership. Applied to agent workflows, the relevant implication is that running software inside the organisation does not by itself justify access to every internal resource.
For a customer-service agent, access to the status of a complaint may be sufficient. Access to the customer's entire financial history may be unnecessary. Even where broader access would improve a response, the business should compare that benefit with privacy obligations, error consequences and the availability of a narrower workflow.
The same distinction applies to actions. Reading a record, proposing an amendment and applying the amendment are separate capabilities. Permissions can reflect those differences rather than treating an application's access as a single yes-or-no decision.
Organisations should also consider the duration of an assignment. A temporary reconciliation exercise does not necessarily justify permanent access. An exception granted for a particular case should have a reason, an accountable owner and a point at which it is reconsidered. Otherwise temporary arrangements can become an undocumented part of normal operations.
Delegation needs a traceable chain
An employee may authorise an agent to prepare a supplier report, which then calls another service to retrieve records. At each step, the organisation needs to understand whether the original authority is being preserved, narrowed or inadvertently expanded.
The IETF's OAuth 2.0 security best current practice, published as RFC 9700 in 2025, addresses threats and protective measures for delegated access. It provides a technical foundation for relevant implementations; using a recognised protocol does not automatically make an entire agent workflow secure.
For business leaders, the practical issue is whether authority can be explained after a transaction. A useful record connects the original request, the agent involved, the systems accessed and the approval supporting a consequential action. It should be possible to distinguish an approved instruction from an interpretation generated later in the process.
This matters when several suppliers participate. A software provider may operate the agent while a cloud service hosts it and another vendor supplies a connected tool. Contracts alone cannot show what happened inside a particular workflow. Operational records and responsibility for examining them remain necessary.
Existing identity disciplines still matter
The CISA and NSA identity-management guidance provides a broader foundation for managing identities and access. Agent programmes should connect with that existing discipline rather than creating a parallel population of accounts that nobody maintains.
An inventory should serve an operational purpose. Teams need to know which business process relies on an identity, who owns it and what would stop working if access were withdrawn. An incomplete dependency record can make an apparently simple security change disruptive.
That does not justify leaving excessive permissions in place. It supports a planned approach to narrowing them. A firm can observe actual dependencies, test an alternative and arrange a fallback before changing a critical workflow. The cost of this preparation belongs in the implementation budget.
Ownership also needs continuity. When an employee leaves or a project ends, the software identity may remain active. The business should have a way to transfer responsibility or retire the workflow. A quarterly discussion that merely confirms that an account exists adds little if nobody can explain why it still needs its permissions.
Approval should be meaningful
Human approval is valuable only when the reviewer can understand the proposed action. Asking an employee to approve a long sequence after the software has already committed most of its effects provides limited protection.
An approval request should expose the facts that change the decision. For a supplier-bank-detail amendment, those facts may include the previous value, the proposed replacement, the source of the request and the verification completed. A generic statement that the agent has finished its checks is less useful.
The reviewer also needs genuine authority to reject or pause the task. If every rejection creates an urgent service failure, the workflow may pressure staff to approve without adequate examination. Staffing, service targets and escalation arrangements therefore influence the effectiveness of the control.
Not every action needs the same process. Drafting an internal note and making an external commitment involve different consequences. A proportionate design places friction where it helps a person make a consequential decision, while allowing routine, bounded activity to proceed under established rules.
AI risk extends beyond access
Limited permissions can contain some damage, but they do not establish that an agent's conclusion is correct. The NIST AI Risk Management Framework organises risk management around governance, context, measurement and management. Its voluntary approach supports examining the system throughout its use rather than relying on a launch-day assessment.
A narrowly authorised agent could still apply the wrong policy, miss an exception or produce an inaccurate explanation. Testing therefore needs to consider the quality of decisions as well as whether a forbidden system can be reached. Business specialists should help define acceptable outcomes and circumstances requiring escalation.
Change introduces another consideration. A new model, connected tool or instruction can alter behaviour even if permissions remain identical. The organisation should decide which changes require renewed evaluation and who can approve them. Reusing a previous assessment without examining the changed workflow can create false confidence.
Supplier claims should be assessed against the deployed configuration. A feature available in a product is different from a feature enabled, correctly configured and tested in the organisation's environment. Evidence of the latter is more useful when deciding whether to expand access.
Measure control alongside productivity
A productivity case can compare task completion time, correction work and the cost of supervision. It should also examine how often the agent needs an exception, whether reviewers receive usable information and whether an interrupted task can be recovered safely.
These measures can reveal an important trade-off. An agent may save time on a normal case while creating substantial investigation work when an unusual case appears. The business case should include both. A small deployment with clear boundaries may be more valuable than a broader deployment whose apparent speed depends on hidden manual repair.
Firms can also test whether access can actually be suspended when needed. A documented stop process has limited value if the people on duty cannot execute it or if its consequences are unknown. Testing should establish who makes the decision, which work stops and how essential services continue.
The purpose is to make a deployment understandable enough to manage. Accountability should remain attached to the business process even when software performs more of its steps. As agents become more capable, clear authority can become an enabler of adoption: teams can expand a task with a reasoned view of what the system may do and what evidence will show whether it did it properly.
References
NIST — Back to the Future Why Agentic AI Needs a Strong Identity Foundation — August 2026
NIST — SP 800 207 Zero Trust Architecture — 2020
https://csrc.nist.gov/pubs/sp/800/207/final
IETF — RFC 9700 Best Current Practice for OAuth 2.0 Security — 2025
https://www.rfc-editor.org/rfc/rfc9700.html
CISA and NSA — Identity and Access Management Recommended Best Practices — 2023
NIST — AI Risk Management Framework