AI agents need transaction-level authority to act

An AI agent can have enough information to determine that a customer record needs changing and still lack the authority to make the change. That distinction is becoming operational as enterprise agents cross application boundaries. Salesforce and Google Cloud’s expanded partnership, announced September 15, is one example: the companies are connecting their AI platforms so agents can use shared business context and act through enterprise applications, extending Salesforce data, workflows and business logic into third-party AI interfaces. Both companies sell the AI and cloud platforms involved, so they benefit commercially as enterprises adopt this kind of integration.

The resulting architecture separates capability from authority. ERP, CRM and other applications can remain systems of record, the applications designated to hold authoritative business records, while agents gather information and coordinate work across them. For enterprise technology leaders, autonomy becomes a transaction-level question: which authoritative data supports an action, who authorizes it, what risks and policies govern execution, and how the organization can recover when something goes wrong.

An agent’s ability to act is separate from its authority

That transaction-level question matters because identifying an appropriate action does not grant permission to execute it. An agent may reason across CRM data, ERP records and other business context and correctly determine what should happen next. Execution still has to pass the enterprise controls that govern the transaction, including data authority, permissions, risk, policy and recovery requirements.

Those controls change what CIOs and architects need to decide when discussing agent autonomy. Asking whether an agent “has write access” compresses several governance decisions into one technical permission. A more useful enterprise model asks whether authoritative information supports each proposed action, whether the agent and task are permitted to perform it, whether the risk is acceptable, whether the result is auditable and recoverable, and whether unresolved cases must escalate.

Data authority comes before execution

The first control question comes before execution: which information is allowed to govern the decision? Suppose an agent retrieves customer information from CRM, billing information from ERP and additional context from a data platform. When those records disagree, access to all of them provides more evidence, but it does not establish which conflicting fact should control a change.

Lian Jye Su, chief analyst at Omdia, an Informa TechTarget company, says businesses should establish a system-of-record matrix that explicitly maps different data types to authoritative sources. The agent can then follow predetermined authority rules when records conflict instead of deciding for itself which record appears correct. The matrix turns data authority into enterprise policy rather than an inference made during an individual agent run.

That matrix may require finer distinctions because authority can vary within a single business object. Kash Mehdi, vice president and field CTO at Reltio, says authority may sit at the individual attribute level. ERP might govern billing status, CRM might govern sales preferences, while another platform contains the most reliable customer identity, so one customer record can draw its authoritative attributes from several places. Reltio sells enterprise data-management technology, giving the company a commercial interest in organizations treating governed data and identity as central to agent operations.

Attribute-level authority then requires enterprises to establish how records are matched, how discrepancies are handled and which information agents may use. As Mehdi puts it, “An agent should not decide authority simply based on which system it queried last or which record appears most complete.” A result that looks comprehensive to the model is insufficient grounds for an enterprise change when organizational rules assign authority elsewhere.

Once those rules exist, they can also define where the agent has room to act. Mehdi says agents can resolve conflicts autonomously when an organization has explicitly authorized them to apply established policies, while ambiguous or high-risk discrepancies should go to human data stewards. Su similarly cautions against allowing agents to select the authoritative system independently when bad information could lead to a consequential business decision.

These authority rules remain relevant even as the role of enterprise applications changes. Su expects AI to become an orchestration and decision layer above conventional enterprise applications while ERP, CRM and other applications continue as the official systems of record. An agent can therefore coordinate a decision across several applications while those applications remain authoritative repositories.

That division creates two forms of authority that enterprise architecture has often treated together. A system of record establishes which information governs a decision, while transaction controls determine whether an agent may act on that information. Because data authority can be finer-grained than application boundaries, neither the application holding a record nor the agent capable of reading it can by itself settle who may change it.

Transaction authority requires explicit permissions and enforcement

Once authoritative information is established, execution poses a separate control question. Mehdi captures the distinction directly: “Decision authority shouldn’t be confused with the system that executes or stores the transaction.” An agent can recommend or initiate a change using information from several applications while enterprise policies, delegated permissions, workflow controls and the target application independently determine whether the transaction can proceed.

Those permissions become more precise when they describe the proposed transaction instead of giving an agent permanent broad access. Mehdi says authorization should be scoped according to the agent’s identity, its task, the data involved and the action it is attempting. One agent could read the information required for a job, recommend changes in some applications and write low-risk updates in others, with each level of access tied to its task.

That task-level scope still has to account for consequences. Su says decisions about write authority should account for business risk, including possible effects on business continuity and regulatory compliance. The same technical operation can require different treatment when its consequences differ, especially when an incorrect change is difficult to undo.

Those consequences can also emerge between reasoning and execution. An agent might rely on stale information, submit the same transaction more than once, or make a change that triggers further updates in several connected applications. Access to the target system consequently says little about whether a proposed write remains safe when execution begins.

To evaluate the write at that moment, Mehdi proposes a policy-enforcement checkpoint between agent reasoning and execution. Before allowing a transaction, the checkpoint validates the agent’s permissions, checks that the underlying information is fresh and examines its provenance, meaning where that information came from. It also tests the action against business rules and allows the transaction only when those conditions hold.

Because the checkpoint evaluates an individual action, autonomy can vary within the same application. The enterprise can ask which agent is acting, which task authorized the request, what data supports it, which operation will occur and what level of risk accompanies it. An agent can consequently have authority for one write while being prevented from performing another operation against the same application.

Once a transaction executes, the next control is the evidence it leaves behind. Mehdi says consequential actions should create an auditable record containing the agent’s identity, the information it used, the rules and permissions applied and the changes that resulted. Those records let the enterprise reconstruct both the basis for a decision and the authority under which the change was allowed.

That record also supports recovery, which must be designed with the same transaction-level specificity. Enterprises need transaction histories and mechanisms for rolling changes back where possible, according to Mehdi, as well as compensating transactions, which offset an earlier change when straightforward reversal is unavailable. Reversibility affects the acceptable risk of granting write authority because an error that can be cleanly reversed has different operational consequences from one whose downstream effects require repair.

With those controls in place, write access becomes an execution decision rather than a standing measure of autonomy. Retrieval establishes what an agent can know, while execution adds requirements around current information, provenance, duplicate protection, downstream effects, auditability and recovery. A particular transaction becomes autonomous only when it satisfies those requirements.

Bounded autonomy can preserve human control over consequential decisions

Transaction-level controls create an alternative to requiring a person to approve every agent action. Current deployments often remain close to universal approval: Su says most enterprise agents do not yet have independent write authority, with organizations relying on human verification and authorization before expanding what agents can do. The same controls create a path for delegating selected actions as organizations become comfortable with their consequences.

Su expects write access to broaden as enterprises deploy more agents, beginning with less business-critical applications where mistakes have more manageable consequences. That sequence makes autonomy depend on consequences rather than treating all writes alike. Transactions with predefined authority and tolerable failure modes can move toward autonomous execution earlier, while consequential transactions can retain stronger checks.

Conflict resolution shows how that boundary can work at the data level. Mehdi allows autonomous resolution when organizations have explicitly authorized agents to apply predefined policies, while ambiguous or high-risk discrepancies escalate to human data stewards. Su says an agent finding discrepancies in authoritative records should alert the user and the responsible business department rather than making consequential corrections independently.

Those escalation rules make human involvement depend on certainty and consequences. A clear discrepancy covered by an explicit rule can be resolved within delegated authority. An ambiguous discrepancy, compliance-sensitive action or high-impact change crosses a different threshold and goes to a person responsible for the decision.

The same boundary appears as enterprises introduce agentic AI, meaning AI systems designed to pursue tasks and take actions with some degree of autonomy. Su says enterprise process automation still involves substantial manual employee intervention, making today’s model more human-in-the-loop, where people participate directly in the process, than human-on-the-loop, where they primarily supervise autonomous operation. Increased agent capability can thus precede any transfer of final authorization.

A large custodian bank provides a concrete example of substantial automation with human authorization. Mehdi learned during an executive roundtable discussion that agents at the bank perform payment repair, work previously handled by operations employees. Humans still validate the AI-generated corrections before settlement, so the agent performs meaningful operational work while a consequential financial step retains a human control.

The bank case shows how delegated work and retained authorization can occupy different stages of one process. Su’s expected expansion into less business-critical applications and Mehdi’s predefined policies provide further conditions for delegating authority. Ambiguous, high-risk and consequential cases continue to involve people, creating graduated authority across an agent’s work.

CIO governance has to span agents, applications, workflows and people

That graduated authority changes the CIO’s architecture problem as agents coordinate activity across applications. Enterprise leaders have to define where authority belongs among authoritative data sources, agent identities, business policies, applications, workflows and employees. A general write permission cannot express those boundaries because each transaction can involve different data, consequences and responsible parties.

The operational risks make this architecture consequential. A bad action can disrupt business continuity or create regulatory problems; it can also rely on stale information, duplicate an existing transaction or trigger changes in downstream applications. Those risks explain why enterprises often withhold independent write authority, require human verification and authorization, escalate ambiguous or high-risk conflicts to data stewards, and flag discrepancies for users and responsible departments.

The custodian-bank payment process applies the same architecture to a financial workflow: automation reaches payment repair while human validation remains attached to settlement. Business-critical, compliance-sensitive and otherwise consequential workflows can retain verification, authorization or escalation where broader autonomy would create unacceptable exposure. The transaction and its consequences set the boundary.

For CIOs, each class of transaction is consequently the practical governance unit. The architecture needs to say which information has authority, which agent and task may use it, what operation is permitted, what policy must be satisfied, what evidence is recorded, how failure is reversed or compensated for, and when a person must take over. That design lets the same agent operate with different levels of autonomy as its work moves between applications, transactions and risk levels.

Key executive takeaways

• Establish data authority before execution: CIOs and data owners can map authoritative sources down to the attribute level so agents know which data governs each decision. Ambiguous or high-risk conflicts can then route to accountable human stewards.
• Enforce authority at the transaction level: Architecture and security teams can scope agent permissions by identity, task, data, action and risk. Policy checkpoints should verify data freshness and provenance while preserving audit trails and recovery mechanisms.
• Match autonomy to consequences: Process owners can delegate low-risk actions covered by explicit policies while retaining human approval for consequential, ambiguous or compliance-sensitive transactions. This creates graduated autonomy within the same agent workflow.
• Govern the full agent workflow: CIOs can define authority across agents, applications, workflows and people for each transaction class. Governance should specify authoritative data, permitted actions, policy checks, audit evidence, recovery procedures and escalation paths.