Identity Governance Becomes Critical as Enterprise AI Spending Soars

Google News surfaced a warning that enterprise AI spending is rising faster than many companies can govern the identities operating behind it. The conflict is no longer limited to experimental chatbots. AI agents now request data, call business applications, generate credentials, and execute tasks across corporate systems.

That expansion changes the security question. Enterprises once focused on deciding which employees could access a resource. They must now govern human users, service accounts, application identities, automation tools, and AI agents within the same environment.

The pressure falls on chief information officers, security leaders, and identity teams. They are being asked to support faster AI deployment while retaining clear ownership, limited permissions, and reliable audit trails. Those goals often conflict when an agent can plan work, delegate tasks, and cross application boundaries.

The central issue is therefore not whether companies will spend more on AI. It is whether identity governance can keep that spending from creating an expanding layer of untracked authority.

What Changed as Enterprise AI Spending Accelerated

Enterprise AI is moving from software that recommends actions to systems that can take actions.

An employee using a chatbot creates a familiar governance problem. The organization must decide which information that employee and application can access. An AI agent creates a harder problem because it can connect to several systems, retain credentials, invoke tools, and perform work without a person approving every step.

That difference becomes significant when agents enter production workflows. A customer-service agent might read account records, summarize past interactions, issue a refund request, and update a ticket. A coding agent might inspect repositories, open development tools, create infrastructure changes, and submit code for review.

Each action requires an identity. It also requires authorization, which defines what that identity can do after authentication. A login alone does not answer whether the agent should read an entire customer database or only the records needed for one assigned task.

Traditional identity and access management systems were designed mainly around employees, contractors, applications, and relatively predictable service accounts. They generally assume that administrators can define a stable role and attach a stable set of permissions to it.

AI agents strain that model. Their tasks can change during execution, and one agent can ask another agent or service to complete part of a workflow. The resulting delegation chain makes it harder to determine where the original authority came from.

Enterprise spending adds urgency because more funded projects create more connections. Every production deployment can introduce API keys, service accounts, data connectors, model endpoints, plug-ins, and access policies. A project that looks like one AI application can create several identities behind the scenes.

Gartner reported that 84 percent of respondents to its 2026 CIO survey expected their organizations to increase generative AI funding during the year. Its discussion of zero-trust governance focused on verifying data and updating existing governance policies as AI-generated information spreads.

That spending does not automatically produce unsafe systems. However, it increases the number of projects that identity teams must discover, classify, and monitor. It also shortens the time available to design controls before business units expect results.

The Google News headline captures this shift, but the real event is broader than one report. Identity governance is becoming part of AI infrastructure because agents cannot operate safely without defined ownership and revocable authority.

Organizations can no longer treat identity review as a final compliance check. They need identity decisions during design, deployment, execution, and retirement. Otherwise, an abandoned agent can leave active credentials or permissions behind after its original project ends.

Why Google News Is Pointing to an AI Control Gap

The spending surge exposes a control gap between who is accountable for AI and who can actually constrain its behavior.

IBM described that gap in a June 2026 study of chief information and technology officers. Two-thirds of surveyed leaders said they were accountable for AI systems they did not fully control, according to the company’s AI control study.

That finding matters because accountability without control produces organizational ambiguity. A CIO might own the enterprise AI program while individual departments select models, connect data sources, and create automation independently. The security team may see the resulting identity only after a review or incident.

AI procurement can also fragment authority. A department might buy an application containing embedded agents without describing it as an agent project. Another team might build an internal workflow using a model API and several existing automation tools.

Both deployments can create non-human identities. Those identities may sit across cloud platforms, software services, internal databases, and development environments. No single inventory necessarily captures the complete path.

The issue is not simply the number of accounts. Identity governance must connect five pieces of information: what the agent is, who owns it, why it exists, which resources it can reach, and when its authority should expire.

Human employees provide natural anchors for several of those questions. Their manager approves access, a job role limits permissions, and departure triggers an offboarding process. AI agents do not have an equivalent organizational status unless the enterprise creates one.

An agent may also use authority borrowed from a human user. This design can simplify deployment, but it weakens attribution if logs cannot distinguish the person’s actions from the agent’s actions. Shared credentials create an even larger gap because investigators may not know which workflow used them.

Security teams therefore face pressure from both sides. Business leaders want shorter deployment cycles, while regulators and customers expect controlled access to sensitive information. Identity teams must support both without turning every agent request into a prolonged manual review.

The control gap also reaches knowledge systems. An AI assistant connected to a corporate knowledge base can retrieve information that appears harmless in isolation. It might still infer sensitive facts by combining several documents that the requesting workflow was never meant to analyze together.

This is why access control must extend beyond a folder permission. Organizations need to understand the relationships among users, agents, data sources, and generated outputs. A well-structured AI knowledge base can improve retrieval, but its value depends on preserving appropriate boundaries.

The challenge becomes harder when AI changes faster than access reviews. A quarterly certification process might approve an agent for one purpose. Weeks later, developers could add another tool or allow it to process a new category of data.

Static approval then stops reflecting the deployed system. Identity governance must track material changes, including new integrations, broader scopes, altered delegation paths, and modified retention rules.

Google News is highlighting a security problem that budget growth makes visible. Companies are funding the ability to act through AI, but many governance programs still focus on controlling the ability to log in.

AI Agents Turn Permissions Into the Main Tradeoff

The core tradeoff is straightforward: agents become more useful as their authority expands, but broader authority increases the consequences of failure.

An agent that can only draft text presents limited operational risk. An agent that can access customer files, call payment systems, change infrastructure, or send external messages can produce more value. It can also cause more damage through error, manipulation, or stolen credentials.

Least privilege is the practice of granting only the access needed for a defined task. Applying it to employees is already difficult because roles evolve and permissions accumulate. Applying it to agents is harder because the required task can unfold dynamically.

Consider an agent assigned to resolve an invoice dispute. It might need to read the invoice, inspect an order, compare a contract, contact an internal approver, and create a proposed adjustment. It should not gain standing access to every invoice or the ability to approve its own adjustment.

A broad service account makes that workflow easy to build. A narrowly scoped identity makes it easier to govern but requires more precise policy design. This tension often appears only after a pilot becomes a production service.

Delegation adds another layer. An orchestrating agent might ask a specialist agent to retrieve data or run an analysis. The enterprise must decide whether the second agent inherits all permissions, receives a reduced subset, or obtains temporary access for one operation.

If authority passes through several agents, logs must preserve that chain. Investigators need to know which human or service initiated the task, which agent made each decision, which resources were used, and whether the resulting action stayed within the approved purpose.

McKinsey estimated that agent-focused technology could absorb up to 15 percent of enterprise cybersecurity budgets within three years. Its analysis said spending would concentrate in identity and governance, alongside data protection.

That forecast reflects a shift in security architecture. Organizations have spent years building controls around networks, devices, and human accounts. Agentic systems make identity a central enforcement point because an agent may operate across all three.

Continuous authorization offers one possible response. Instead of approving access once at login, a system evaluates whether a specific action remains allowed at the moment it is requested. The decision can consider the agent, task, resource, time, risk level, and originating user.

Temporary credentials also reduce exposure. An agent can receive a credential for one task and lose it automatically when the task ends. This approach limits the value of a stolen token and reduces the chance that obsolete access survives indefinitely.

Neither technique solves the full governance problem. A policy engine still needs reliable information about the agent’s purpose and ownership. A temporary credential can be dangerously broad even if it expires quickly.

Enterprises also need separation of duties. An agent that proposes a payment should not necessarily authorize or execute it. High-impact actions can require a human review, a second agent operating under different authority, or a deterministic business rule.

That control reduces autonomy, which can disappoint teams expecting fully automated workflows. Yet the objective should not be maximum autonomy. It should be the highest level of autonomy that preserves acceptable evidence, accountability, and recovery options.

This is where enterprise AI spending meets identity governance most directly. Money buys models, infrastructure, and integration work. It must also fund the controls that determine which actions those systems can take.

The Identity Security Market Has Its Own Evidence Problem

Vendor surveys point in the same direction, but their numbers require careful interpretation.

Security providers have released several studies describing rapid agent adoption and weak identity controls. These reports offer useful signals because vendors observe customer environments and incident patterns. They also support products sold by the organizations publishing them.

Teleport reported that overprivileged AI systems were associated with 4.5 times higher incident rates in its 2026 enterprise study. The company also said 92 percent of surveyed companies were deploying AI while identity controls lagged behind, according to its enterprise security report.

Those figures should not be treated as universal measurements. Results depend on the sample, question wording, definitions, and how respondents classify an AI deployment or security incident. An organization experimenting with a coding assistant is not equivalent to one allowing agents to modify production systems.

The broad pattern remains credible even when exact percentages vary. Enterprises are adding non-human identities, and many existing identity programs struggle to inventory service accounts and API keys. AI agents add more dynamic behavior to that established problem.

Another limitation is terminology. Vendors use terms such as AI agent, machine identity, workload identity, service account, and non-human identity differently. A survey can appear to measure agent governance while combining several categories of automation.

That ambiguity affects spending claims. A company might classify an upgraded privileged-access system as an AI security investment. Another might fund the same control through its cloud platform or general identity budget.

IDC reported that 16.7 percent of planned global AI investment was allocated to AI-agent security and governance. Its analysis of CISO priorities also identified tool sprawl, technical debt, skills gaps, and vendor lock-in as obstacles to purchasing decisions.

That figure shows meaningful buyer attention, but it does not prove that spending is producing mature governance. Organizations can buy overlapping tools without creating a reliable identity inventory or a consistent approval model.

Integration remains the difficult part. Identity data may reside in an identity provider, cloud platform, secrets manager, human-resources system, application catalog, and security operations platform. Agent metadata may live in a separate development or orchestration environment.

A governance product can display only what connected systems reveal. Shadow AI, which means unapproved or undiscovered AI use, can remain outside that view. An employee might connect a consumer AI tool to business data without registering a formal application.

Okta’s 2026 research described a disconnect between executive confidence and employee behavior. It linked the gap to unclear policies, unapproved AI tools, and insufficient safeguards within the agentic enterprise.

The cautious conclusion is not that every enterprise faces an immediate identity crisis. It is that companies lack a consistent measurement system for agent identities, their effective permissions, and their real behavior.

Effective permissions matter more than assigned permissions. An agent may combine access from several systems or infer information across allowed sources. Each permission can look reasonable alone while the combined capability exceeds the intended boundary.

Testing must therefore move beyond configuration review. Security teams need to observe attempted actions, denied requests, delegation patterns, credential use, and data movement. They also need to test how systems behave when an agent receives malicious instructions or encounters corrupted content.

Incident response introduces another uncertainty. Organizations may be able to disable one agent account but not identify every credential, workflow, or downstream task associated with it. A complete shutdown mechanism requires dependency mapping before an incident occurs.

The evidence supports increased attention, not blind confidence in a particular platform or statistic. Identity governance becomes effective only when an organization can demonstrate who owns an agent, what it can do, and how that authority ends.

Who Is Pressured by the Governance Shift

CIOs own the delivery pressure, CISOs own much of the risk, and identity teams inherit the operational workload.

Chief information officers are expected to turn AI investment into measurable business results. They must move projects beyond prototypes while controlling fragmented spending and incompatible platforms. Governance that arrives too late can delay production or force expensive redesigns.

Chief information security officers face a different incentive. They must prevent excessive access, detect misuse, and explain incidents. An agent that acts through shared credentials can undermine all three responsibilities.

Identity and access management teams sit between those priorities. They understand directories, authentication, privileged access, access reviews, and account lifecycles. They may not own agent orchestration, model behavior, data governance, or application design.

This division creates gaps unless companies assign explicit responsibility. Every production agent needs a business owner who accepts its purpose and consequences. It also needs a technical owner who maintains the integration, credentials, policies, and monitoring.

Developers face pressure because identity controls affect architecture. A prototype might use one long-lived API key stored in an environment variable. A production deployment should use managed secrets, scoped credentials, rotation, expiration, and traceable requests.

These requirements add engineering work that is easy to underestimate. The model may generate an answer within seconds, but the surrounding system must retrieve authorized information, validate tool calls, record decisions, handle failures, and prevent unsafe retries.

Enterprise buyers must examine more than model quality. They need to ask whether an AI product supports separate identities for agents, granular permission scopes, administrator approval, exportable logs, credential rotation, and immediate revocation.

They should also ask how the vendor handles delegation. If an agent invokes another service, the customer needs to know which identity appears in downstream logs and whether the original user context survives.

Data owners have a role because access decisions cannot rely entirely on centralized security teams. The person responsible for financial, medical, customer, or engineering data should define acceptable purposes and higher-risk actions.

Legal and compliance teams will care about evidence. A policy document stating that agents use least privilege is weaker than records showing which permissions were granted, who approved them, what actions occurred, and when access expired.

Employees also experience the governance shift. A tightly controlled agent may ask for approval more often or refuse a task it cannot complete within its permissions. That friction can encourage users to choose unauthorized tools if approved systems feel unusable.

The enterprise response must therefore balance control with usability. Policies should distinguish low-risk drafting from high-impact execution. Requiring the same approval process for both can create delay without improving the most important protections.

Procurement can support that distinction by classifying products according to their authority. A tool that summarizes documents presents a different risk from one that edits records or communicates externally.

Boards should focus on exposure rather than the number of AI projects. Ten agents with read-only access to public information can pose less operational risk than one agent holding a broad production credential.

This reframing makes identity governance a business decision. It connects AI spending to the value and risk of the actions being automated, rather than treating every deployment as an equivalent software purchase.

Google News readers should therefore view the identity governance story as a redistribution of work. More AI spending does not eliminate human responsibility. It shifts that responsibility toward the people designing, approving, and monitoring machine authority.

What Enterprise Buyers Should Watch Next

The next phase will be measured by identity coverage, permission quality, and incident readiness, not the number of agent announcements.

The first signal is whether major AI platforms adopt interoperable identity standards. Enterprises currently risk managing each agent environment through different identity objects, logs, and policy systems.

Common standards would help organizations identify an agent consistently across a model platform, orchestration framework, cloud service, and business application. They would also make delegation chains easier to preserve.

A vendor announcing agent identity support is not enough. Buyers should examine whether the identity is unique, persistent, attributable to an owner, and compatible with existing authentication systems. They should also verify that downstream applications can recognize it.

The second signal is the quality of runtime authorization. Many platforms can limit access at setup, but fewer can evaluate each action against the current task and context.

Runtime controls should answer practical questions. Is this agent permitted to access this customer record for this request? Can it send the resulting information outside the company? Does a financial action require a second approval?

Watch for products that support short-lived credentials, task-level scopes, policy checks, and clear denial records. Those capabilities indicate that identity governance is moving into execution rather than remaining an administrative review.

The third signal is evidence from incidents and audits. Companies will learn whether their controls work when an agent behaves unexpectedly, receives manipulated instructions, or uses authority outside its intended purpose.

Useful public evidence would include detailed incident reports, regulatory findings, insurance requirements, and audit guidance. These sources can show whether organizations can trace an agent’s actions and revoke every related credential quickly.

A decline in excessive permissions would strengthen the argument that identity programs are catching up. A rise in incidents involving shared accounts or unclear ownership would show that spending continues to outrun governance.

Enterprises can begin measuring their own position without waiting for a new standard. They should count production agents, identify owners, map credentials, record effective permissions, and track access expiration.

Coverage is the first useful metric. An organization cannot govern an agent it has not discovered. The inventory should include purchased applications with embedded agents, internally built workflows, and employee-created automation.

Permission quality is the second metric. Teams should measure how many agents hold broad or permanent access, how often requests are denied, and whether sensitive actions require additional approval.

Lifecycle performance is the third metric. Companies should know how long it takes to create, review, modify, suspend, and retire an agent identity. Slow processes encourage workarounds, while missing retirement controls leave unnecessary access behind.

Incident readiness provides the final test. A team should be able to disable an agent, revoke its credentials, stop queued tasks, identify affected resources, and reconstruct the sequence of actions.

These steps do not require enterprises to abandon existing identity systems. Many organizations can extend current governance processes if those systems support machine identities, temporary authority, and detailed event data.

However, simply placing agents into employee-style roles will not resolve dynamic delegation or task-specific access. Companies will need policies designed around actions and purposes, not only job titles.

Google News has surfaced a timely headline, but the lasting story is operational. Enterprise AI spending is creating systems that can exercise authority at machine speed. Identity governance must determine whose authority they use, how far it reaches, and when it stops.

The next question for every AI buyer is concrete: can your organization name every production agent, identify its owner, explain its effective permissions, and revoke them without disrupting unrelated work? If the answer remains unclear, the AI budget has already created a governance obligation that the security budget must address.