sdecoret - stock.adobe.com
AI agents know what to do -- but should they have authority to do it?
AI agents are gaining access to enterprise systems, but moving from reading data to making changes requires new rules about authority, permissions and human oversight.
Enterprise software vendors are making it easier for AI agents to work across applications. But as agents gain access to information in multiple systems, a more complicated question is emerging: What happens when an agent moves from retrieving information to writing back into a system of record or triggering a transaction?
Salesforce and Google Cloud's expanded partnership, announced September 15, illustrates the shift. The companies are connecting their AI platforms so agents can access shared business context and take action through existing enterprise applications. The integration builds on Salesforce's efforts to extend its data, workflows and business logic to third-party AI interfaces.
But connecting agents to enterprise applications doesn't resolve which system is authoritative when records conflict, where an agent is permitted to make changes or who ultimately approves a transaction. Those decisions become more consequential as enterprises move beyond agents that retrieve information and recommend actions.
Most enterprise agents aren't yet being granted independent write authority, said Lian Jye Su, chief analyst at Omdia, an Informa TechTarget company. Instead, organizations are proceeding cautiously, relying on human verification and authorization before expanding agents' ability to act.
Su said he expects write access to expand as enterprises deploy more agents, initially in less business-critical applications where the consequences of an incorrect action are more manageable.
When enterprise records disagree
One of the first complications arises when agents retrieve information from multiple systems that contain conflicting records.
An agent might access customer information from a CRM platform, billing information from an ERP system and additional context from a data platform. But access to all three doesn't tell the agent which information to trust before initiating a change.
Businesses should establish a system-of-record matrix that explicitly maps different data types to their authoritative sources, Su said. Agents would then follow predefined rules rather than independently determining which conflicting record is correct.
Another complication is that determining the authoritative source isn't always as simple as choosing between ERP and CRM.
Kash Mehdi, vice president and field CTO at Reltio, said authority might reside at the individual data-attribute level. An ERP system might govern billing status, CRM might own sales preferences and another platform might maintain the most reliable customer identity. Enterprises need established rules for matching records, resolving discrepancies and determining which information an agent can use, Mehdi said.
"An agent should not decide authority simply based on which system it queried last or which record appears most complete," he said.
Those rules also have limits. Agents can resolve conflicts autonomously when organizations have explicitly authorized them to apply predefined policies, Mehdi said, but ambiguous or high-risk discrepancies should be escalated to human data stewards.
Su similarly cautioned against letting agents independently determine which system is authoritative, particularly when incorrect information could lead to consequential business decisions.
Decision-making and execution are different responsibilities
The question gets more complicated when agents begin initiating changes across applications.
Su said he expects AI to become an orchestration and decision layer above traditional enterprise systems, even as ERP, CRM and other applications remain the official systems of record. But the ability to identify an action doesn't necessarily confer the authority to execute it.
Mehdi had similar thoughts on that situation: "Decision authority shouldn't be confused with the system that executes or stores the transaction," he said.
An agent might recommend or initiate a change based on information gathered across applications. Still, enterprise policies, delegated permissions, workflow controls and the target application determine whether the action is permitted, he said.
Those permissions should be tied to an agent's identity, the task it's performing, the data involved and the action it's attempting, rather than giving agents broad standing access, Mehdi added. An agent could be permitted to read necessary data, recommend changes in some systems and write low-risk updates in others, depending on the risk involved.
That distinction is already emerging in financial services. At one large custodian bank, agents perform payment repair, work traditionally handled by operations employees. However, humans validate AI corrections before settlement, according to Mehdi. He learned about the deployment during an executive roundtable discussion.
Mehdi couldn't confirm whether the agents modify pending payment records directly or prepare corrections for execution through a separate workflow. The example nevertheless illustrates how companies can separate agent-performed tasks from final transaction approval.
Other enterprises are generally maintaining similar boundaries as they introduce agentic AI, Su said. There's still a lot of manual intervention from employees in enterprise process automation, he said, making it more human-in-the-loop than human-on-the-loop.
The approach also reflects the varying consequences of allowing agents to change different enterprise systems.
Su said decisions about write authority should be based on business risk, including potential effects on business continuity and regulatory compliance. An agent detecting discrepancies in authoritative records should flag them for the user and the responsible business department rather than independently making potentially consequential corrections.
Write authority raises operational questions
Even when enterprises define which systems agents can modify, executing transactions raises another set of issues: An agent could initiate an action using outdated information, attempt to repeat a transaction or make a change that triggers subsequent updates across multiple applications.
Companies need a policy-enforcement checkpoint between an agent's reasoning and execution, Mehdi said. That checkpoint should validate permissions, the freshness and provenance of the underlying information and compliance with business rules before permitting a transaction.
The consequences of an incorrect action also depend on whether the change can be reversed.
Consequential agent actions should produce an auditable record identifying the agent, the information it used, the rules and permissions applied and the resulting changes, according to Mehdi. Enterprises also need transaction histories and mechanisms to reverse changes or execute compensating transactions when a straightforward rollback isn't possible.
For CIOs, the challenge extends beyond determining how much autonomy to grant individual agents. As agents begin coordinating work across multiple applications, businesses must define where an agent's authority ends and where the authority of existing systems, workflows and employees begins.
ERP, CRM and other enterprise applications might remain the systems of record, but agents increasingly operate across the boundaries between them. That raises a new question CIOs must consider: An agent might have enough information to determine what should happen next, but should it have the authority to make it happen?
Liz Hughes is an award-winning editor and writer covering AI and emerging technology and the former editor of AI Business and IoT World Today.
