Why CIOs must redesign how SAP, Salesforce and ServiceNow grant authority

It posted the recurring accruals. It worked the intercompany exception queue, the reconciliation that normally falls to a staff accountant. And when items would not match, it cleared them to a suspense account within the configured tolerance rather than escalating them to a human.

Clearing the queue was the objective. Nobody had defined escalation as success. Every journal entry carried the controller’s user ID.

No one set out to obscure anything. The job step had been mapped to her credentials at implementation, which is how it had been done since the system went live. Segregation of duties had become a fiction.

The control requires a named preparer and a named approver. The agent did both, under one identity: it prepared the entries and it disposed of the exceptions. The record named the controller for each.

She had done neither. When internal audit walked those entries the following quarter, they asked her to explain postings she had never seen. None of this was a model failure.

The agent was accurate. It was authorized. Every entry looked clean, which is exactly why nobody caught it.

Figure 1. The assumptions never changed. The actor did.

Vipin Jain Here is the number that should frame this year. Gartner expects 40 percent of enterprise applications to carry task-specific AI agents by the end of 2026, up from under 5 percent in 2025. Okta finds only 10 percent of organizations have a strategy for managing the agents they are already running.

And Deloitte , surveying more than 3,000 leaders across 24 countries, puts mature agentic governance at 21 percent against 74 percent who expect to be using agents within two years. Adoption is racing. The control model is not.

Every one of those agents inherits a permission model built for a person clicking a button, which means the question that matters is no longer whether an agent can do the work. It is whether, when it does, anyone can say who authorized it. McKinsey frames the same shift from the governance side: organizations can no longer concern themselves only with systems that say the wrong thing.

They now have to contend with systems that do the wrong thing. What actually broke? ERP, CRM and core administration platforms rest on four assumptions so foundational that nobody writes them down: identity, permission, action, receipt.

Each one places a named human at the center. An agent breaks all four at once, and none of them repairs itself. Figure 2.

The four control planes, and what each one now requires. Vipin Jain Intent. A person submits a bounded request, and the request is the transaction boundary.

An agent receives a goal and decomposes it into steps at runtime. On a state eligibility modernization program, we gave an agent one goal: clear the verification backlog. It re-ran electronic verification, and where a federal source returned no match, it advanced the case toward closure and generated the notice.

Nobody listed that step. Nobody had to. It is a defensible reading of clear the backlog, and it is precisely what the agent was rewarded for.

But a no-match is not a finding of ineligibility. It triggers a reasonable opportunity period, and closure carries notice and appeal rights that attach to a determination, not to a data lookup. The rule that breaks here is least privilege.

You cannot scope permissions to an action set nobody enumerated in advance. Authority. Applications grant entitlement to a person.

It is standing and role-based, and that person’s judgment is the unwritten limiter on it. At a specialty retailer, I watched a quoting agent go into Salesforce to compress turnaround at quarter close. The approval matrix was intact: manager above fifteen percent, director above twenty-five.

None of it fired. A submission action in the user interface triggers a Salesforce approval process, and the agent wrote to the record through the API. It never submitted.

An integration user provisioned with more rights than anyone intended bypassed the validation rules and record locks that would ordinarily catch it. Salesforce’s own architects are blunt about the mechanism. The client credentials flow, they warn , creates a service-account pattern in which every call runs as a single identity, and both per-user permissions and the audit trail are lost along the way.

Their guidance on identity propagation goes further: when an agent calls a downstream service using client credentials, the request carries the agent’s service identity rather than the end user’s, which makes per-user authorization and audit trails impossible. That approval process was never a security control. It was a workflow convention that humans had no reason to route around.

Logic. Business rules used to be a configuration artifact: versioned, testable, under change control. At a health insurer, I traced one authorization threshold for advanced imaging to three separate homes.

Configured in the core administration platform. Routed in the orchestration layer. And written in plain English inside the agent’s instruction, as a sentence somebody added during a sprint.

Medical policy tightened the first. Nobody touched the third, because the third is not a configuration item. No change control that clinical policy or compliance has ever seen covers it.

In every payer program I have worked, that drift runs one direction only. An agent cannot lawfully deny since adverse determinations require review by a licensed clinician. So the exposure is silent over-authorization against a threshold the organization believes it already tightened, surfacing months later through a delegated vendor audit or a utilization variance that finance notices before medical management does.

Then someone asks the question with no good answer: how long, and how many. Evidence. The log names whichever credential was presented.

That is the insurer’s close, and it is the most measurable of the four failures. The Cloud Security Alliance found that 68 percent of organizations cannot clearly distinguish between human and AI agent activity, even as 73 percent expect agents to become vital to operations within a year. An agent without a delegation chain is not automation.

It is an unsigned transaction. Table 1. The same failure, four industries Industry System What the agent did What broke Financial services SAP, month-end close Cleared exceptions to a suspense account under the controller’s user ID Evidence.

Segregation of duties asserts a preparer and an approver; the record showed one person as both Retail Salesforce, quoting Wrote discounts to the record through the API, never submitting for approval Authority. A standing entitlement on an over-provisioned integration user, with no per-action scope Healthcare payer Core administration, utilization management Auto-approved against a threshold medical policy believed it had tightened Logic. One rule in three places, with change control covering one of them Federal State eligibility Advanced cases toward closure on a data-hub no-match Intent.

An unbounded goal, executed through steps nobody enumerated Why didn’t the controls catch it? Because in every one of these cases, the controls worked as designed. That is the uncomfortable part, and in the programs I advise it is the finding that changes the conversation.

This is not a problem the CIO can hand to the security team and consider closed. Consider the insurer’s segregation-of-duties conflict. It never appeared in the access risk analysis, and the tooling did not fail.

Most implementations exclude technical and service accounts from risk-analysis scope entirely, on the reasonable historical assumption that a service account does not exercise judgment. Nobody ever analyzed the account. The conflict was not missed.

It was never in view. Most writing on agent risk assumes an adversary. The OWASP Top 10 for Agentic Applications , built with input from more than 100 practitioners, catalogs goal hijack and memory poisoning and places Identity and Privilege Abuse third on the list.

What I see most often is duller. Nobody attacked the payer. A threshold governed in one of three places simply drifted, and it took a vendor audit to notice.

The pattern holds across all four, and each one breaks a control an auditor already asks about. Intent breaks least privilege. Authority breaks separation of duties.

Logic breaks configuration management. Evidence breaks non-repudiation. Those four are the spine of any controls walkthrough, which is precisely why this arrives on the CIO’s desk rather than staying in the security function.

None of these produced a headline. They produced audit findings and rework: a control deficiency to disclose, authorizations to re-adjudicate, cases to reprocess, notices to reissue. That cost lands on the CIO’s budget and the CFO’s certification, not on the security team’s incident log.

The repair is the same in all four cases. Stop letting an agent borrow a person’s credential, and start recording who stands behind it. Figure 3.

What replaces the borrowed credential. Vipin Jain What has the market already conceded? What I find most striking this year is not that a vendor shipped something.

It is that vendors, standards bodies, regulators and advisers all converged on the same requirement within roughly six months of each other, without coordinating. Figure 4. Standards, vendor releases and regulatory deadlines through 2026.

Vipin Jain Microsoft made the human sponsor mandatory . Every agent identity carries a named business owner accountable for it, and if that person leaves, sponsorship transfers to their manager so accountability never quietly disappears. SAP now governs an agent lifecycle that runs from proposed to evaluated to approved to active to retired, with a verification badge controlling which agents are cleared for use.

And Okta has moved access decisions out of individual applications and into the identity layer, with AWS, Google Cloud and Salesforce behind the effort. Google reached general availability this month with the bluntest statement any vendor has made. Its agent identity documentation argues against the service account directly: agent identities are not shared, cannot be impersonated, and permit no long-lived keys.

Every action resolves to a cryptographic ID rather than to whoever the credential once belonged to. That is the insurer’s close, described by a hyperscaler as a design flaw to engineer out. The pattern held into this month.

At Black Hat on 4 August, Rubrik unveiled a service that grants an agent access one tool call at a time, minting a short-lived token for each call and eliminating standing permissions outright. Its general manager for AI put the diagnosis in one line: the access models we built for humans were never designed for autonomous actors. The standards work is further behind, and honest about it.

NIST’s National Cybersecurity Center of Excellence opened a concept paper on software and AI agent identity and authorization in February and closed comment in April, explicitly seeking input on agent auditing, non-repudiation and prompt-injection controls. The gap is officially acknowledged. The standard is not written.

Regulators moved in a way most leaders misread. Brussels deferred the EU AI Act’s high-risk obligations in June, pushing them to 2027 and 2028, and the headline everyone absorbed was that the AI Act had been delayed. Half true, and imprecise in a way that matters: the Article 50 transparency duties, including telling people when they are interacting with an AI system, were untouched.

They took effect on 2 August and are live now. The advisory community has landed in the same place. BCG , writing on scaling agents in regulated industries, tells CIOs to define clear approaches to agent identity, authority and accountability: what agents can access, what actions they can take, and how those actions remain traceable.

Booz Allen , surveying 105 federal IT and cybersecurity decision makers this spring, found 22 percent who have not determined who bears responsibility when an agent causes an incident. Read those together and the picture is unambiguous. The identity layer has been rebuilt around delegated, sponsored, per-action authority.

The business applications those agents act inside have not moved at all. The plumbing now encodes accountability. The applications still do not ask for it.

Where should CIOs start? None of this requires a reorganization. The leaders I see getting ahead are not doing more; they are doing six things in order, on the bounded use cases where they can afford to learn.

Inventory the agents. Enumerate every agent acting inside a system of record, the identity it runs under, and its standing entitlements. Only 23 percent of leaders report full visibility into the agents already running in their environment, and most organizations I work with cannot produce that list today, and producing it is usually the moment this becomes real to the executive team.

Bind identity to a named human. Retire shared service accounts and borrowed logins. Every agent gets its own identity with a named sponsor who answers for it.

This is the change that fixes the insurer’s close because the document header stops naming a bystander. Scope authority per action. Short-lived, time-bound, just-in-time.

And move approval enforcement out of the workflow layer into the authorization layer, where an API call cannot walk around it. This is the step I almost never see taken, and it is the one that fixes the retailer. Consolidate the logic.

The instruction becomes a configuration item: versioned, evaluated, approved and reviewed alongside the rules engine. If a threshold changes in medical policy, it changes in all three places or it changes in none. Instrument the evidence.

The transaction record carries the delegation chain, meaning agent, sponsor, instruction version and model version. Without those four, every incident investigation starts from zero. Graduate autonomy deliberately.

Sanctioned, then supervised, then autonomous, with sunset as a real state rather than a euphemism for neglect. Figure 5. The agent authority ladder.

Vipin Jain The gates between rungs are what make the ladder operational rather than decorative. Sanctioned to supervised requires a named sponsor and a declared scope. Supervised to autonomous requires an evidence record showing the agent stayed inside it.

And sunset is not a failure state. It is what happens when an agent stops earning the authority it holds, which most organizations have no process to detect. Do these in order and autonomy compounds.

Skip them and you join the more than 40 percent of agentic projects Gartner expects to be canceled by the end of 2027, undone not by weak models but by escalating cost, unclear value and inadequate risk controls. The takeaway The most common strategic mistake I see this year does not look like a mistake. Leaders are granting agents authority inside systems whose architects assumed a human held it, and then treating the resulting mess as a technology problem.

It is not. It is the same failure I have watched for thirty years, from trading floors to Medicaid programs: business strategy, IT and organizational culture are not architected to move together, and the technology simply industrializes the gap. I recommend a reframe most leaders resist at first.

Guardrails here are not friction. You can give an agent that proves who authorized it more autonomy, sooner, and with far less anxiety than one that cannot. The delegation chain is what makes acceleration survivable.

So put three questions to your team this week. None of them requires a program to answer, and all three will tell you more than a maturity assessment. Table 2.

Three questions, and what a good answer sounds like Ask your team A good answer sounds like When an agent acts in our ERP, whose name does the log carry, and is that person accountable? A named sponsor who can explain the action, rather than a service account nobody owns Which of our approval controls are genuine security boundaries, and which are workflow conventions? A tested list, proven by attempting the action through the API rather than the user interface Which of our agents have earned the authority they hold, and which should we sunset?

An evidence record for each agent, and a retirement date for the ones that cannot produce one The agent is the new user. Your applications have not been told. This article was made possible by our partnership with the IASA Chief Architect Forum .

The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA , the leading non-profit professional association for business technology architects.