Enterprise genai spending is rising faster than governance

At a glance

What this is: Kong’s survey highlights rapid enterprise GenAI spending growth alongside a widening governance gap, with security and compliance emerging as the main blockers to broader LLM adoption.

Why it matters: IAM, API, and AI governance teams need to treat GenAI as a control-plane problem now, because adoption is scaling faster than decision rights, policy enforcement, and oversight models.

By the numbers:

• 72% of respondents say they anticipate an increase in their organisation’s LLM spending in the year ahead.
• 37% say they are currently spending more than $250,000 USD a year on LLMs.
• 73% are already spending over $50,000 annually on LLMs.
• Kong surveyed 550 users, engineers, and IT decision-makers on enterprise LLM adoption.

Context

Enterprise GenAI adoption is no longer experimental. The article says LLM use is moving into mainstream business workflows, with spending expected to rise even as organisations struggle to keep pace with the governance implications of broader deployment.

The identity and access problem here is not just who can use an LLM. It is who can approve, constrain, observe, and audit the APIs, tokens, and data paths that make enterprise GenAI usable at scale.

Kong’s survey points to a familiar pattern: usage expands first, then security and compliance teams are asked to retroactively define controls. That sequence is typical for fast-moving platform shifts, but it creates avoidable governance debt.

Key questions

Q: How should enterprises govern unauthorized GenAI use across business teams and data platforms?

A: Enterprises should treat unauthorized GenAI use as a governance and data control problem, not just a policy issue. Start by discovering where AI tools are being used, then classify the data they touch, apply access and masking controls, and require approval paths for higher-risk use cases. The goal is to reduce leakage, preserve compliance, and make AI usage visible enough to manage.

Q: Why do GenAI applications create new security and legal risk for organisations?

A: GenAI systems can process sensitive inputs, generate unsafe outputs, and make decisions with too much autonomy. That expands the attack surface across privacy, governance, and operational risk. If prompts, plugins, training data, or output handling are weak, attackers can expose information, trigger misuse, or create liability through policy breaches and unauthorized actions.

Q: What breaks when AI agent data access is not tied to identity governance?

A: What breaks is accountability. If access is not tied to identity governance, security teams cannot tell whether the agent was over-entitled, whether a policy failed, or whether the data movement was expected. That makes incident response, compliance evidence, and entitlement review much harder to perform with confidence.

Q: How do teams decide whether to prioritise GenAI adoption or governance first?

A: Teams should prioritise governance first when GenAI will touch sensitive data, customer workflows, or developer tooling. Adoption without policy, logging, and scoped access creates rework later and raises the cost of remediation. If the use case is narrow and experimental, governance can be lighter, but it still needs to exist before production rollout.

Technical breakdown

Enterprise GenAI spending turns API governance into a control-plane issue

Enterprise GenAI is usually delivered through APIs, gateways, and integrated application workflows rather than isolated chat interfaces. That means the security boundary sits around access to models, tokens, downstream data sources, and policy enforcement points. When spending grows, the attack surface grows with it, because each integration creates another path where data can leave governed systems or where policy can be bypassed through unmanaged endpoints. For identity teams, this is less about model quality and more about controlling who can invoke GenAI, under what conditions, and with what data entitlements.

Practical implication: Treat GenAI consumption as an API governance and identity problem, not a standalone AI procurement decision.

Why security and compliance become the adoption blockers

The article says security and compliance are the biggest potential blockers, which is predictable when organisations move from pilot use to enterprise-scale deployment. At that point, the questions shift from model preference to data handling, auditability, retention, authorisation, and acceptable use. If access to GenAI tools is not tied to identity, data classification, and policy, teams lose visibility into who is using what, for which workflow, and with which information. That creates shadow AI conditions even when the tooling is officially approved.

Practical implication: Bind GenAI access to identity, data policy, and logging requirements before broadening internal availability.

Spending growth exposes the gap between adoption and governance maturity

The survey data suggests enterprises are funding GenAI faster than they are building the operating model around it. That matters because governance maturity is not just an approval workflow. It includes lifecycle control over access, review of high-risk integrations, and evidence that the organisation can answer basic questions about usage and exposure. In practice, many programmes are still at the stage of experimenting with models while assuming the surrounding controls can be added later. That assumption becomes expensive once GenAI is embedded in production workflows.

Practical implication: Inventory where GenAI is already embedded and assess whether governance controls exist at the point of access, not only at the point of purchase.

Threat narrative

Attacker objective: The objective is to exploit weak governance around GenAI access so sensitive data, business logic, or credentials flow through uncontrolled AI usage paths.

1. Entry begins when enterprise users, developers, or applications gain access to GenAI services through approved or ad hoc APIs and integrations.
2. Credential and policy exposure follow when tokens, keys, or delegated access are reused across workflows without tight governance or clear scope boundaries.
3. Impact emerges when ungoverned GenAI usage expands data exposure, compliance risk, and visibility gaps across business workflows.

Breaches seen in the wild

• McKinsey AI platform breach: McKinsey AI platform hack exposed 46M chats and sensitive data.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Enterprise GenAI growth is forcing API governance to become the primary control surface. The article’s spending data matters because most enterprise GenAI use is mediated through APIs, tokens, and application integrations rather than standalone prompts. That shifts the governance problem from user experience to access control, logging, and data-path enforcement. Practitioners should treat GenAI as a governed service plane, not as a separate innovation sandbox.

The real blocker is governance debt, not model choice. Kong’s survey points to security and compliance as the main friction points, which is what happens when adoption outpaces control design. The vendor-neutral lesson is that enterprise AI programmes fail when identity, policy, and observability are added after deployment instead of being part of the operating model from the start. The implication is that approval, audit, and entitlement processes must be designed before usage becomes normalised.

GenAI access needs lifecycle management as much as application security. If teams cannot answer who is allowed to invoke GenAI, which tokens are in scope, and when access is reviewed or revoked, the programme is already behind. This is an NHI governance problem because machine-mediated AI usage behaves like any other privileged digital identity, except at higher speed and with broader data exposure. Practitioners should govern the identity behind the AI path, not just the model endpoint.

Shadow AI is what happens when spending grows faster than enforcement. As budgets rise, teams tend to add more sanctioned tools while employees continue to route work through unapproved GenAI services, plugins, and APIs. That produces fragmented logging, inconsistent data policy, and a false sense of coverage. The practitioner takeaway is to measure actual usage paths, not just approved vendors, because governance gaps hide in the workflows people adopt first.

GenAI governance will increasingly converge with IAM, PAM, and API security. The spending trend suggests that AI programmes are no longer isolated experiments but production dependencies. That means the same controls used to govern privileged access, service identities, and sensitive APIs will become the default language for AI risk management. Practitioners should expect AI oversight to be absorbed into core identity governance rather than handled as a separate exception process.

From our research library:

• According to Gartner, worldwide spending on generative AI is set to reach $644 billion in 2025, a nearly 77% year-over-year increase.

What this signals

GenAI governance will increasingly be won or lost at the API layer. Once AI use is embedded in application flows, the practical control point is no longer the model itself but the access path that delivers it. That means identity teams should expect GenAI oversight to merge with API security, service identity management, and entitlements governance.

Shadow AI will remain a recurring governance issue until organisations inventory real usage paths. Approved tooling tells you only part of the story, because employees and developers will route work through whatever is easiest to use. The programme question is whether you can observe those paths, classify them, and apply policy before they become entrenched.

Budget growth without lifecycle control creates governance debt. As more teams get access to GenAI services, the absence of clear review and revocation points will make entitlement sprawl harder to unwind. The practical response is to make every sanctioned AI path traceable to an owner, a policy, and a review cycle.

For practitioners

• Map GenAI entry points Identify every approved and unofficial path into GenAI, including APIs, plugins, embedded assistants, and developer workflows, then assign ownership for each path.
• Bind access to identity and data policy Require authenticated access, scoped entitlements, and data-classification rules for each GenAI integration so usage can be tied back to a governed identity.
• Review token and API credential scope Check whether GenAI services are consuming shared tokens or broad API keys that outlive the workflow they support, then narrow the access scope to the minimum needed.
• Instrument logging for AI usage paths Make sure logs capture which user, service, or workflow invoked the model, what data class was involved, and which downstream system was reached.
• Create a GenAI governance inventory Track sanctioned models, sanctioned applications, and unsanctioned usage separately so security and compliance teams can close visibility gaps before scale increases.

Key takeaways

• Enterprise GenAI spending is accelerating faster than the governance structures needed to control it.
• The main risk is not simply model choice but unmanaged access, data exposure, and weak auditability across AI-enabled workflows.
• Teams should treat GenAI adoption as an identity and API governance problem so policy, logging, and lifecycle controls exist before broad deployment.

Key terms

• GenAI Governance: The set of policies, controls, and accountability rules that determine how generative AI is approved, used, monitored, and retired. Effective governance connects purpose, data classification, access boundaries, logging, and ownership so AI programs do not scale faster than control maturity.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Automation control plane: The central system that coordinates actions across other tools, services, and data stores. In practice, it becomes a high-trust orchestration layer that can hold credentials and issue privileged requests, which means compromise of the plane can cascade into many downstream systems.
• LLM spending governance: LLM spending governance is the discipline of aligning AI budgets with security, compliance, and operational accountability. It matters because cost growth often signals wider adoption, which increases the need for approvals, entitlement checks, and audit-ready controls.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.