By the end of 2026, Gartner projects roughly 40% of enterprise applications will carry agentic capabilities , up from just 5% in 2025. Much of the software driving that curve isn’t new. It’s already installed, already budgeted for and already sitting on the “approved” side of the ledger. It’s the accounting platform, the HR system, the collaboration tool nobody thinks twice about anymore, yet creates an agentic AI governance blind spot. Organizations built entire risk programs around software behaving as expected, and increasingly, it doesn’t.

“The fundamental assumption was that software could and would and should behave predictably,” said Nick Warner, CEO and co-founder of Neo, an agentic software control startup. “So you would measure against that and reasonably assume that any anomalistic behavior was caused by an attacker or some type of malware.” That paradigm has become antiquated, he said, due to product updates made inside tools companies already trust.

The Agentic AI Governance Blind Spot

Most vendor risk reviews happen once, at approval, and rarely again until the next contract renewal or annual reassessment. that model assumes that once a product passes review, it stays roughly the same product. Agentic capabilities break that assumption.

“Sanctioned software can become a source of shadow AI without anyone purchasing or installing a new tool,” said Jack Lodge, EVP of customer success at NWN Carousel, which manages technology environments for enterprise clients. “A vendor can add an agent that accesses more data, invokes other systems, or acts on a user’s behalf,” Lodge said, “and the tool may remain classified as ‘approved’ even though it has become materially different” from what was originally reviewed. Furthermore, “new agentic capability can use existing permissions to act at machine speed,” he added.

Warner sees the same gap from the security side. Large platform vendors tend to announce agentic rollouts loudly, he said, because there’s a sales motion attached. It’s the dozens of smaller tools an accounting or HR team relies on, “where there isn’t real notification around fundamental transformation of the software from being deterministic to being powered by AI and taking on agentic capabilities.” He added, “the average organization has thousands of different software tools in their environment,” which makes a manual, reassess-on-schedule approach unworkable at the scale agentic adoption now demands.

Why Point-in-Time Approval Creates an Agentic AI Governance Blind Spot

The fix both experts point to isn’t a faster annual vendor questionnaire. Rather, it’s a different trigger altogether.

Zane Lackey, general partner at venture capital firm Andreessen Horowitz, is a security practitioner, founder and former chief information security officer at Etsy (his fund has invested in Neo). Asked whether a vendor adding agentic capabilities to an already-approved tool triggers a re-review today, he said, “In practice today almost never. Vendor risk review is point-in-time and was built for an era when software was shipping much slower (like quarterly) and the capabilities were fixed at purchase.”

What needs to change, Lackey argued, is what triggers a review in the first place — shifting from a calendar-based schedule to one tied to specific signals, like a new authorization scope or a newly enabled autonomous capability. “Risk acceptance needs to no longer be thought of as a static point-in-time decision, but rather a constantly evolving set of data which may result in new decisions being made as new capabilities emerge inside approved tools,” he said.

Lodge frames the fix in three steps. First, triggers for material changes such as new autonomy, expanded data access, added permissions, external integrations and the ability to make or execute decisions should be established in advance. Second, contract language should require vendors to disclose those changes to named contacts before general release. Finally, “higher-impact agentic features should default to being disabled and require specific administrative approval to enable until a targeted review has occurred,” he said. None of that means restarting a full security assessment for every enhancement, he added; “The review should be proportionate to what the feature can see, decide and do, and it should be informed by telemetry from the environment rather than by vendor claims alone.”

Agentic AI Governance: Whose Decision Was It?

Even organizations that catch the capability shift face a harder question: when software acts, who decided?

“Many security teams are having a very tough time with attribution,” Lackey said. “The log says a valid user did a valid thing but there’s no field for who made the decision.” Most existing security tooling was built before agents existed, he noted, and has no way to distinguish between a human’s action and an agent’s decision executed under that human’s credentials.

Lodge draws the same line from the governance side: “A valid credential proves that an account was authorized to access a system. It does not prove that the employee personally decided to take the specific action.” For attribution to be effective, he recommends separating the human who delegated a task from the agent that executed it and the credentials used. “Ideally, agents should have distinct machine identities, narrowly scoped permissions and service-level visibility rather than operating invisibly through an employee’s account,” he said. He further recommends that “audit logs should capture who initiated the task, which agent and version acted, which objective it received, what systems it accessed, whether human approval occurred and what final action was taken.”

Warner described the same gap from inside customer environments: with the average enterprise running dozens of security products, none currently provides a full audit trail of agentic sessions or chat activity. Visibility into who — or what — initiated an action, he said, is the starting point for building any policy or controls.

Closing the Agentic AI Governance Blind Spot Starts With Ownership

Asked who should own this, Warner didn’t hedge: “We think that it’s 100% on security,” arguing that it is impractical to expect procurement to track ongoing capability changes across a sprawling vendor list and that a “radical rethinking of security posture” is needed.

Lodge advocates for shared responsibility with clear accountability, spread across defined roles: the business or application owner accountable for the use case and how much authority an agent receives; the CISO or governance/risk leader owning the governance framework and review thresholds; security and IT owning identity, monitoring and access controls; and procurement or legal setting the contractual requirements for notification and audit rights. “There should be one executive owner for the overall governance program and one named business owner for each agentic capability,” Lodge said.

Regardless of ownership, there is agreement that the old model, where an approval at purchase covers a product for its useful life, even with annual reviews, no longer maps to software that may evolve rapidly after it’s already inside the walls.

For leaders, that reframes an assumption more than it adds a task. Vendor approval was never meant to be permanent, but it has functioned that way in practice — a decision made once, filed and rarely revisited unless something goes wrong. As enterprise software increasingly gains the ability to reason, act, and decide on its own, that filing-cabinet approach to risk is not only outdated; it is an agentic AI governance blind spot sitting inside every application already marked safe.

Did you enjoy this story on agentic AI governance? Don’t miss my next one: use the blue “follow” button at the top of the article near my byline to follow my work, and check out my other columns here .