At a Fortune 500 insurer, I watched an AI agent inside the month-end close do exactly what we asked. 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.

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.

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

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.

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.

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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. Graduate autonomy deliberately. Sanctioned, then supervised, then autonomous, with sunset as a real state rather than a euphemism for neglect.

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

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. 

The once stable era of IT service management (ITSM) has entered a period of disruption and uncertainty. At least if you’re an investor or enterprise customer with an interest in ITSM giant ServiceNow, the signals over recent months have been hard to ignore.

Last year, the category leader delivered market-pleasing AI announcements, a record share price, and good quarterly revenue growth, as well as an interesting pivot toward cybersecurity with the December acquisition of partner Armis for $7.75 billion in cash.

But as the calendar turned to 2026, the phrase “Saas apocalypse” started to gain traction, and market sentiment about SaaS incumbents suddenly melted away, causing ServiceNow’s share price to drop 30% by mid-2026, albeit from historic highs.

What’s driving anxiety is the perception that AI agents and vibe-coding tools will soon took over many of the previously complex workflow, automation, and software tasks carried out traditionally by subscription platforms, including ServiceNow’s. Customers will stop buying SaaS subscriptions because they won’t need employees or “seats” to do this work. Instead, cheaper internal AI tools, or larger cloud platforms doing the same job, will simply automate the market away.

While some enterprise IT leaders are in fact empowering business users to vibe code their own solutions, the model for replacing vendors with vibe-coded apps remains edgy business. As a result, SaaS isn’t likely dying any more than on-premises software, though CIOs are still reimagining software’s future as AI agents advance.

So too is ServiceNow, including how it expects IT leaders to finance that future. The company’s June Financial Analyst Day 2026 presentation confirmed a shift away from subscriptions based on seats is already under way, with only 50% of the company’s Net New Annual Contract Value (SaaS jargon for new revenue) in 2025 coming from this source. Instead, growth is increasingly generated by “consumed” services such as infrastructure, integrations and connectors, AI token consumption, and cybersecurity.

AI convergence

AI is causing previously distinct sectors such as ITSM and cybersecurity to converge, with AI itself turning into a unifying AIOps front end to diverse, specialized technologies sitting below it. In this, ServiceNow looks well-placed, having added the Virtual Agent chatbot system to its Now platform as long ago as 2018, later reinforced by acquisitions, including search outfit Element AI, chatbot company Passage AI, and AIOps pioneer Loom Systems. In 2025, this evolution crystalized as the ServiceNow AI Platform, a rebranded Now platform augmented by unifying features such as the AI Control Tower.

In traditional ITSM, the platform helps teams build workflows without the need for coding in a way that simplifies complex processes. AI takes this a step further; now it becomes possible not only to generate a workflow but reason and act on it. In this, AI and ITSM look like a natural combination as each enhances the usefulness of the other.

But building a better AI front end or adding automation to workflows gets you only so far, which makes the company’s Armis acquisition, its largest ever, intriguing. Unlike previous ServiceNow acquisitions with a cybersecurity theme — Veza in 2025, Mission Secure in 2024 — Armis’s agentless platform is more than an information gathering system. It can also orchestrate actions such as isolation and blocking across a wide range of devices, including workstations, routers, switches, firewalls, and the long tail of often forgotten medical scanners and IoT devices.

Nevertheless, it is the ability to build an accurate inventory that explains why the acquisition happened at an eye-watering 23 times annual revenue, says Brad LaPorte, a former Gartner analyst who now works with Lionfish Tech Advisors. ServiceNow didn’t buy Armis to sell it as a cybersecurity sideline because its $340 million annual revenue and annual growth rate are too small to justify that.

“Nobody pays 23 times revenue for a product. They pay for a position. That single financial fact explains most of what customers are about to experience, good and bad,” says LaPorte. The limitation of today’s ITSM and configuration management database (CMDB) systems is that workflows assume the CMDB is accurate when it’s often a work of fiction.

“Everyone reconciles to it. Nobody believes it. Every attack surface tool on the market can tell you what it found. Not one of them can tell you who is going to fix it by Friday,” LaPorte says.

So, buying Armis is less about adding cybersecurity than supercharging the company’s traditional ITSM workflows, which have recently been given an AI makeover. At the same time, by making its platform appealing to hospitals, utilities, and manufacturing, ServiceNow can attract customers in completely new sectors.

According to LaPorte, ServiceNow customers should be alert to the ways this changes their relationship. Customers are likely to experience Armis being heavily marketed to them at contract renewal. In theory, this is good, assuming they can refuse. But they might find that the financial engineering and incentives behind this could be complex to untangle and don’t always work in their favor over the contract period.

Armis will also bring ServiceNow into competition with a new set of rivals, LaPorte notes, and bring into the fold a new buyer, the CISO, it has never previously had to win over. CISOs are skeptical by nature as well as sensitive to the occasional security weaknesses that have affected ServiceNow itself.

“Armis was Switzerland. It integrated with everybody, including every ITSM platform that competes with ServiceNow. That neutrality was part of the product,” LaPorte says. “That is gone now. This just moved everybody’s negotiating position.”

Consumption pricing

Several experts spoken to for this article agreed that the SaaS apocalypse idea is overblown in relation to ServiceNow. Its incumbency protects it from AI because reproducing ServiceNow’s capabilities using vibe-coded AI could prove more challenging than people assume. However, there is consensus that the convergence of AIOps and cybersecurity will be highly disruptive in the ITSM sector.

“ServiceNow is competing with Microsoft, which can bundle, and with the model vendors, who are climbing up into the application layer,” argues Lionfish Tech Advisors CEO Rob Smith, another ex-Gartner analyst. “ServiceNow’s defense is not that it has a better model, which it doesn’t. Its defense is that it knows the steps in your process, and that is expensive to re-create.”

Chris Selland, founder of research company Differential Factor, who lectures at Northeastern University on entrepreneurship and disruption (and has written on SaaS for CIO.com), agrees that ServiceNow’s Armis acquisition looks like an important piece of a puzzle.

“The Armis deal extends that map into everything that was never in the CMDB, such as IoT and medical devices. It’s a defense of their asset graph,” he says. And the company probably sees itself as having something to defend. “ServiceNow is in around 90% of the Fortune 500, so yes this is fundamentally a ‘sell more to the base’ strategy,” argues Selland.

“The threat was never that AI writes competing enterprise software; it’s seat compression and the collapse of per-seat pricing. That threatens the SaaS industry’s core revenue model,” Selland contends.

ServiceNow understands this, which is why it is moving toward a consumption-based model. The question is how this will change the balance of power with customers at a time when open-source and open-weight models are driving down AI pricing and competition is fierce, including from large cloud platforms.

With more players competing for business against specialists such as ServiceNow, this could give buyers a lot more leverage if they understand how to manage hidden cost traps.

“Consumption-based pricing is much better for both buyers and sellers than seat-based pricing, although it can lead to nasty surprises for buyers if they’re not careful about monitoring what their employees are doing,” Selland says.

Records held in Salesforce and ServiceNow systems are under attack leaving user data exposed, according to researchers at Reco.

The attack appears similar to those perpetrated by the extortion group ShinyHunters, Reco said. ShinyHunters has been particularly active this year, attacking dating sites in January and Oracle in June, and there are fears that they could have found a new target.

Reco has named the latest campaign of attacks “City-Forum,” after a domain name associated with the attackers’ IP address. While it bears similarities to Shiny Hunters’ past exploits, there are also differences. This time around the attacker penetrated the systems through the UI-API layer, an attack point that Reco had not seen used before, and had also created its own toolset to carry out the attack. It is also targeting a native ServiceNow Service Portal search endpoint that has almost no online documentation or well-known open-source tools.

The threat is particularly noteworthy, Reco said, as the attackers have studied the services to map different common data-leak vectors, a sign of an advanced approach.

A Salesforce spokesperson said that it was aware of the campaign in which malicious actors are exploiting customers’ overly permissive Experience Cloud guest user configurations in the campaign to potentially access more data than targeted organizations intended.

“This issue highlights risks stemming from misconfigurations, such as overly permissive guest user profiles, and not from a Salesforce vulnerability,” the spokesperson said.

Regardless of who the attackers were and how the attack was carried out, one thing should be clear: Organizations should be increasingly careful about who they give login credentials to.

This article first appeared on CSO.