During a recent architecture review with a client, I asked their leadership to trace a single automated transaction backward through their production systems. Three days earlier, an embedded customer support agent had issued an unapproved account credit to a corporate client. Every system monitoring dashboard was glowing green. Internal network logs showed a clean, successful transaction. Cloud performance monitors showed standard processing times.
When we queried the core financial system, the control environment could not answer the question we were trying to resolve. There was no log explaining what customer context triggered the refund, what calculations took place, or which corporate business policy authorized the spend. The software had executed cleanly from a technical standpoint, but from a business governance standpoint, it was an unauthorized transaction.
It is easy to assume that an agent inherits some of the trust of the application it lives inside. It doesn’t. A secure Salesforce, SAP, or Workday environment still does not answer whether an agent was authorized to make a particular business decision. If it makes the wrong move, the vendor does not own the resulting business problem. The enterprise does.
According to research from Gartner, forty percent of enterprise applications will be integrated with task-specific AI agents by the end of 2026, up from less than five percent in 2025.
That forecast will likely be read as proof that enterprise AI adoption is accelerating. But it measures something narrower: how quickly vendors are putting agents into products companies already use. Software can be deployed long before the organization has decided what that software is actually allowed to decide. That forecast tells us how quickly agents are arriving. It does not tell us whether the organizations deploying them have decided where their authority begins and ends.
The subscription price on the vendor’s order form is only the first line item.
Enterprise procurement teams are still buying autonomous software agents as if they were traditional application features, evaluating additions using familiar checklists: seat pricing, uptime guarantees, data encryption and user access roles.
The moment software can initiate payments, adjust contract pricing, alter supplier terms, or reroute customer orders without a person reviewing the choice first, an organization has delegated part of its business authority to software. At that point, seat price is only part of the evaluation. The real issue is what authority the company has handed over.
If an agent can execute consequential decisions, the enterprise also pays for the operational guardrails around it: ongoing monitoring, policy enforcement, historical audit logging, incident response and the manual finance or legal cleanup required when something goes wrong. An agent that looks inexpensive during contract negotiations can become remarkably expensive to support in daily operations. In architecture reviews, I keep seeing the same four questions get mixed together:
A software vendor’s cloud security certification proves that its underlying infrastructure is protected against outside intruders. It does not prove that an action taken by an automated tool complied with your internal company rules. If an embedded sales agent commits your organization to an unapproved contract discount, the vendor’s security report remains valid, but your revenue margin takes the hit.
Technical performance monitors verify system mechanics, not business permissions. An operations dashboard can confirm that a request finished in 240 milliseconds, but it cannot tell an internal auditor whether the system should have approved the credit in the first place. Traditional enterprise software follows rigid rules where decision paths are mapped out in advance. Autonomous agents interpret unstructured information and choose among possible actions on the fly.
NIST’s 2026 research identifies fragmented logging across distributed infrastructure as a monitoring problem and points out that the relationship between monitoring and auditing is still unresolved. That matters because an enterprise can have healthy systems and extensive logs while still being unable to prove that a business decision was authorized.
Mandating that human employees approve every automated action does not solve this problem at enterprise scale. Human-in-the-loop workflows look safe in leadership meetings, but they break down under transaction volume. Give an employee five flagged exceptions a week, and they investigate each one carefully. Give that same employee two hundred automated approval requests a day, and clearing the backlog becomes the primary job. The review turns into a routine rubber stamp. Human approval only works as a control when the person approving the action has the time and context to evaluate it.
Conversely, forcing senior managers to manually double-check every piece of background information behind every automated suggestion destroys projected productivity gains. You end up paying the full subscription cost for the automated system while retaining the full payroll cost of manual review.
The AI failures that make headlines are usually the obvious ones. Enterprise systems have another class of failure: the transaction that succeeds.
Traditional IT monitoring is designed to catch systems that break. A server stops responding, a database times out, or an application crashes, triggering an immediate alert. Policy failures do not trigger technical alarms. The purchase order processes, the supplier gets paid, the customer receives a confirmation email and the transaction closes. From a technical standpoint, nothing failed. From an internal governance standpoint, it was a complete failure of controls.
Consider how this plays out in daily operations. In procurement, an automated purchasing agent routinely routes material orders to a preferred supplier that delivers quickly, quietly bypassing a corporate policy that requires gathering three competitive bids for purchases over $50,000. The same thing can happen elsewhere across the business. A sales agent can offer custom payment terms that violate internal accounting rules for revenue recognition. A customer-support agent can resolve an urgent ticket by pulling private client records across department lines without proper authorization.
In every case, the software ran as intended, the task finished and the operations dashboard displayed green checkmarks. Yet an automated process changed company records or decisions outside authorized policy.
The second Gartner forecast changes the conversation. Gartner predicts that by 2027, forty percent of enterprises will demote or decommission autonomous AI agents due to governance gaps discovered only after production incidents occur. The research specifically points to the failure to distinguish an agent’s ability to act from the scope of access it is granted.
An agent may possess the technical capability to update a database record without the enterprise ever making an explicit decision that it should be allowed to do so. That problem compounds when workflows cross multiple vendor applications. If one software platform defines permissions one way, and your core enterprise database defines them another, who owns the business rules when an automated workflow spans both?
The vendor can provide the software, but the enterprise still owns the business rules.
In my work evaluating production architectures, I repeatedly see governance fall into an ownership vacuum. The business application team assumes cybersecurity is managing agent permissions. Cybersecurity assumes the business process owner defined the operational rules. Finance assumes the software vendor engineered the platform to prevent policy violations.
By the time leadership asks who authorized the behavior, the system may have been running for months and making decisions nobody explicitly approved. Once money has moved or an unvetted contract term has been delivered to a client, an audit log can only document what happened. It cannot make the decision authorized.
Enterprises have delegated authority to software for decades through scheduled batch jobs, service accounts and automated scripts. What changes with autonomous agents is that the software has far more latitude to decide how it accomplishes an objective. Asking “Who has access to the application?” is no longer enough. You must also ask: “What decisions is the software allowed to make with that access?”
The answer is not to put an approval committee in front of every automated action. That would simply replace one problem with another. Applying uniform, manual controls to every automated feature is just as flawed as deploying agents with no guardrails at all. The more consequential the action, the stronger the control should be.
A meeting-summary agent and an agent that can issue a refund should not operate under the same control boundary. A software provider can update an agent’s underlying behavior during a routine update without changing your enterprise policy. For that reason, business authority rules cannot live solely inside the vendor’s application.
For high-consequence actions, the enterprise needs a separate check against its own policies and financial limits before the record changes. The evidence detailing why that action was permitted must be captured independently, ensuring that when internal auditors or regulators examine the transaction a year later, the enterprise can verify both the context and the business authorization behind it. Before approving the rollout of embedded autonomous agents, every leader should put six practical questions to their procurement and architecture teams:
Software vendors will continue embedding autonomous agents into the enterprise applications companies already use. C-suite cannot let that release cycle become the company’s authority model. The organization still has to decide what those systems are allowed to do and be able to prove that decision later.