TL;DR: Enterprise GenAI adoption is accelerating, with Gartner cited in Kong's survey finding more than 80% of enterprises will have deployed GenAI applications or used GenAI APIs by 2026, while 72% of respondents expect LLM spending to rise in the next year. The governance gap is that budget growth is outrunning security and compliance readiness, not just model choice.
At a glance
What this is: Kong's survey shows enterprise GenAI spending, deployment, and model adoption are all rising quickly, with security and compliance already seen as the main blockers.
Why it matters: For IAM teams, the risk is that AI usage expands faster than identity, access, and governance controls can adapt across machine, agentic, and human workflows.
By the numbers:
- 80% of enterprises will have deployed generative AI, erative AI applications or used GenAI APIs by 2026, up from just 5% in 2023.
- 72% of respondents say they anticipate an increase in their organization's LLM spending in the year ahead.
- 37% say they're currently spending more than $250,000 USD a year on LLMs.
- 73% are already spending over $50,000 annually.
👉 Read Kong's survey findings on enterprise GenAI spending and adoption
Context
Enterprise GenAI spending is no longer experimental. The primary identity question is no longer whether teams will adopt LLMs, but how quickly identity, access, and governance controls can catch up with the pace of deployment across APIs, tools, and business workflows.
Kong's survey frames a familiar pattern for identity programmes: usage expands first, then security and compliance become the bottleneck. That matters because LLM access is often wrapped in service identities, API keys, or embedded platform access, which means the control plane is really an identity plane.
The article is about adoption and budget growth, not a deep technical incident. Its starting position is typical for the market, because many enterprises are still discovering where GenAI fits before they have built durable governance around it.
Key questions
Q: How should security teams govern enterprise GenAI access at scale?
A: Treat GenAI access as an identity programme, not a feature toggle. Inventory every service account, API key, token, and workload identity that can reach a model, then bind each one to an owner, a purpose, and a review cycle. That makes access revocation, auditability, and change control possible as adoption grows.
Q: Why do GenAI programmes create new identity risk even when the models change?
A: Because the operational risk sits in the identities that call the models, not only in the models themselves. When teams switch providers or add tools, they often keep the same broad credentials, which expands exposure across data sources, logs, and downstream applications. The control failure is credential reach, not model brand.
Q: What breaks when LLM access is not tied to lifecycle management?
A: Access persists after pilots end, integrations move, or vendors change, and that leaves old credentials in circulation. Without lifecycle management, organisations lose the ability to prove who can still reach a model, who approved it, and when it should be removed. The result is entitlement sprawl that security teams cannot easily unwind.
Q: Who should own governance when GenAI usage spans IT, compliance, and developers?
A: Ownership should sit with the programme that controls identity and access, not with a single tool team. Compliance needs visibility, developers need usable patterns, and security needs revocation authority. A shared governance model works best when each model-facing identity has one accountable owner and one review path.
Technical breakdown
LLM adoption turns application access into identity governance
When enterprises consume GenAI through APIs or embedded application features, the identity problem shifts from user login to machine-to-machine authorisation. The relevant question is not only who can sign in, but which service accounts, tokens, and API keys can invoke model endpoints, retrieve data, and pass outputs into downstream systems. That expands the control surface across provisioning, secret storage, and auditability. In practice, LLM usage often arrives through existing platforms faster than governance teams can classify the identity behind each call.
Practical implication: inventory every model-facing credential, and map each one to an accountable business owner and an explicit access purpose.
Security and compliance become the first scaling constraint
The article points to security and compliance as the main blockers, which is consistent with identity-heavy AI programmes. Once LLM spend grows, organisations need to know which identities are accessing prompts, what data those identities can touch, and whether logs are sufficient for investigation and recertification. This is less about model quality than about lifecycle discipline, because a forgotten API key or shared integration token can outlive the project that created it.
Practical implication: tie GenAI approvals to lifecycle events so access can be reviewed, revoked, and reissued as systems change.
The model mix problem is an access governance problem
The shift between OpenAI, Google, Anthropic, and DeepSeek usage shows that model choice is fluid. For identity teams, that fluidity matters because every model change can alter authentication patterns, data paths, and third-party exposure. If access controls are hard-coded to a single provider or workspace, teams create brittle governance that breaks when developers switch tools. A portable control model should follow the identity and the data, not the brand of the model.
Practical implication: design model access policies around shared identity and data controls, not around a single vendor integration.
NHI Mgmt Group analysis
Enterprise GenAI spending is becoming an identity governance problem before it is a model strategy problem. The article shows budget expansion, faster adoption, and rising operational use, but those are all only sustainable if identities, credentials, and access paths are governed with the same discipline as human access. Once LLMs are embedded in workflows, the control question shifts from procurement to entitlement management. Practitioners should treat GenAI scale as a governance workload, not a software feature rollout.
Machine identities will be the real scaling unit for enterprise LLM usage. Most organisations will not govern GenAI through end-user credentials alone. They will govern it through API keys, service accounts, workload identities, and integration tokens that can invoke models on behalf of teams and applications. That means the effective blast radius is determined by how well machine identities are scoped, rotated, and retired. Practitioners should stop treating model access as a front-end issue and start treating it as machine identity governance.
Model churn creates access churn, and access churn exposes lifecycle gaps. The survey's mix of model adoption shows that enterprises are not standardising on one provider. That creates an identity lifecycle problem because every switch in provider, environment, or integration adds a new credential path, a new audit trail, and a new offboarding obligation. The implication is that access review processes must be designed for rapidly changing AI estates, not static application portfolios. Practitioners should assume migration will increase entitlement sprawl unless lifecycle governance is already in place.
Security and compliance are now the gating functions for GenAI scale. Kong's respondents already name them as the biggest blockers, which reflects a wider market reality: the enterprise can fund GenAI faster than it can prove control. That makes auditability, policy enforcement, and data access tracing foundational rather than optional. Practitioners should expect governance reviews to become part of GenAI programme design, not a post-deployment check.
Identity blast radius is the right concept for GenAI governance. The useful question is not how many models are deployed, but how far a single credential can reach across prompts, tools, data sources, and downstream systems. When LLM access is mediated by reusable secrets and broad service permissions, one mis-scoped identity can spread across many workflows. Practitioners should evaluate GenAI risk by credential reach, not by model count alone.
From our research:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
- For a broader governance lens, see Ultimate Guide to NHIs , 2025 Outlook and Predictions for how the identity boundary is shifting across agents, services, and workloads.
What this signals
Identity governance teams should expect GenAI adoption to surface as a lifecycle problem first. The immediate work is not model selection but ownership, review cadence, and revocation paths for the identities that call those models. If the credential behind a GenAI workflow cannot be traced, recertified, and removed on demand, the programme is already operating outside governance expectations.
Shadow AI will increasingly look like shadow infrastructure. Once teams can spin up model access through shared tokens and integration credentials, unmanaged usage becomes difficult to distinguish from sanctioned usage. That means discovery, entitlement mapping, and policy enforcement need to cover machine identities as well as people, especially where data access is broad and logs are thin.
AI agents have already performed actions beyond intended scope for 80% of organisations, according to AI Agents: The New Attack Surface report, which shows the governance gap is no longer theoretical. For practitioners, that means the next phase of GenAI readiness is not more experimentation, but stronger control over who or what can act, what it can reach, and how quickly that access can be removed.
For practitioners
- Map every model-facing identity Build an inventory of service accounts, API keys, tokens, and federated identities used to call LLMs, then assign a business owner and a defined purpose to each one.
- Bind GenAI approvals to lifecycle events Require re-approval when a model provider changes, a new integration is added, or an application moves environments so access does not persist beyond the intended deployment state.
- Scope credentials to specific use cases Limit each integration token to the minimum model, data source, and workflow it needs, and separate production access from experimentation and testing.
- Make audit logs investigation-ready Ensure logs capture which identity invoked the model, what data sources were queried, and which downstream actions were triggered so compliance teams can reconstruct activity.
Key takeaways
- Enterprise GenAI growth is outpacing the identity controls needed to govern it safely.
- The main risk sits in machine identities and reusable credentials, not in model selection alone.
- Programmes that cannot trace, review, and revoke model access will struggle to prove control as adoption scales.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers API keys and tokens used to reach LLM services. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Supports continuous verification for model access and data paths. |
| NIST CSF 2.0 | GV.RR-01 | Governance and risk ownership are central to AI adoption at scale. |
Apply least privilege to GenAI integrations and re-evaluate access as workflows change.
Key terms
- Model-facing identity: A model-facing identity is any human or machine identity that can invoke an LLM, send prompts, retrieve responses, or pass model output into another system. In practice, this is often a service account, API key, token, or federated credential with real data access attached.
- Identity blast radius: Identity blast radius is the amount of system, data, and workflow exposure a single credential can reach if it is mis-scoped or compromised. For GenAI programmes, the blast radius often extends beyond the model itself into data sources, tool calls, logs, and downstream automations.
- Shadow AI: Shadow AI is the use of AI systems or agents that has not been discovered, approved, or governed by the organisation. It usually appears when teams can create model access through existing credentials or embedded platform features without a corresponding governance record.
- Lifecycle governance: Lifecycle governance is the discipline of provisioning, reviewing, rotating, and retiring identities as business needs change. In AI programmes, it matters because access often outlives experiments, integrations, and vendor relationships unless offboarding is tied to change control.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
This post draws on content published by Kong: 72% Say Enterprise GenAI Spending Going Up in 2025, Study Finds. Read the original.
Published by the NHIMG editorial team on 2025-06-18.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org