AI governance is becoming an API and identity problem

At a glance

What this is: Kong argues that enterprise AI adoption is outpacing governance, with shadow AI, weak API readiness, and cost control gaps emerging as the main blockers.

Why it matters: IAM, NHI, and security teams need to treat AI governance as an identity and access problem because unmanaged agents, APIs, and tokens create the same control drift seen in other non-human identity sprawl.

By the numbers:

• 84% of companies report a hit to gross margins from AI costs.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Kong's analysis of AI governance, shadow AI, and token cost control

Context

AI governance now sits at the intersection of API design, identity control, and cost management. In practice, that means enterprises are not just deciding where to use AI, but who or what is allowed to call models, which systems those calls can reach, and how much freedom an agent has once it is in production.

The governance gap appears because many organisations still treat AI adoption as a series of local experiments. That creates shadow AI, inconsistent API hygiene, and weak visibility into token consumption, which mirrors the same fragmentation problems security teams have spent years trying to eliminate in NHI and access governance.

For IAM and security leaders, the important shift is that AI traffic cannot be governed as ordinary application traffic alone. It needs lifecycle oversight, policy enforcement, and auditability across the identities and interfaces that make agentic workflows possible.

Key questions

Q: How should security teams govern AI agents that can call APIs and models directly?

A: Security teams should govern AI agents through central policy enforcement, scoped access, and complete logging at the gateway or control plane. The key is to treat the agent as a runtime identity with lifecycle, audit, and authorization requirements, not as a normal application integration.

Q: Why do AI agents create new identity and access management risks?

A: AI agents create new identity and access management risks because they can initiate actions, select tools, and consume data at runtime across multiple systems. That behaviour expands the blast radius of any weak scope, missing approval step, or unmanaged credential path.

Q: What breaks when AI governance is left to individual teams?

A: What breaks is accountability. Individual teams tend to create separate agents, gateways, and approval patterns, which produces shadow AI, inconsistent logging, and unclear ownership. Once that happens, security and compliance cannot reliably answer who accessed what or why.

Q: Who should own AI governance in the enterprise?

A: AI governance should be owned jointly, but with a single operating model that spans platform engineering, security, IAM, and finance. If ownership is split without shared controls, the organisation gets inconsistent policy enforcement and no reliable audit trail.

Technical breakdown

Shadow AI and unmanaged MCP gateways

Shadow AI emerges when teams create AI workflows outside central governance, often by standing up their own MCP servers or calling models directly. In that model, identity controls are fragmented across teams, and security loses a reliable view of which agent, service account, or API client is invoking which data source. The operational issue is not just discovery. It is that the organisation cannot consistently bind approval, policy, and logging to the AI interaction path. Practical implication: centralise control points before agent sprawl hardens into a permanent blind spot.

Practical implication: centralise control points before agent sprawl hardens into a permanent blind spot.

API readiness for agentic workflows

Agent-ready APIs need stable specifications, predictable scopes, and observability that machine actors can rely on. When APIs are inconsistent or poorly documented, agents compensate by retrying, probing, or taking unintended paths, which increases both security risk and operational noise. This becomes an identity issue because the API consumer is no longer a person or a single application, but a runtime actor making autonomous calls across services. Practical implication: treat API hygiene as a prerequisite for safe agent access, not a cosmetic integration task.

Practical implication: treat API hygiene as a prerequisite for safe agent access, not a cosmetic integration task.

Token governance as a control plane

Token consumption behaves like a new form of usage-based exposure. Without central limits, routing rules, and auditability, costs rise unpredictably and governance teams lose the ability to distinguish legitimate workload demand from runaway agent behaviour. Kong's article frames this as a financial problem, but the deeper issue is access control over compute and model usage at runtime. Practical implication: apply governance to model access and spend together, because cost spikes often signal control failure as much as usage growth.

Practical implication: apply governance to model access and spend together, because cost spikes often signal control failure as much as usage growth.

NHI Mgmt Group analysis

AI governance is becoming an identity governance problem before it becomes an AI tooling problem. Once agents can call models, APIs, and data sources directly, the real control question shifts from model quality to who or what is authorised to act. That makes policy, logging, and lifecycle oversight the foundation, not the afterthought. Practitioners should stop treating AI traffic as a separate universe from IAM and NHI governance.

Shadow AI is the same governance failure pattern as NHI sprawl, just with faster runtime decisions. Teams spin up agents, MCP servers, and direct model calls faster than platform teams can standardise controls, which fragments accountability and weakens auditability. The field should read this as a warning that decentralised AI adoption reproduces the same blind spots seen in unmanaged service-account growth. Practitioners need one governance model for runtime access, regardless of whether the actor is human, machine, or agent.

Agent-ready APIs expose a new control boundary: the interface, not just the identity, must be governed. If the API is inconsistent, undocumented, or weakly observed, the agent can still reach the system, but the enterprise loses predictability over how it gets there. That makes API hygiene a prerequisite for identity governance in agentic environments. Practitioners should align API design, authZ scopes, and audit logging as a single control surface.

Identity blast radius is the right concept for AI governance because token, API, and agent access now fail together. A mis-scoped agent can generate cost blowouts, data leakage, and unmanaged service calls in the same workflow. That is no longer just a security issue or a finance issue. It is a compounded identity governance issue, and practitioners should measure it as such.

Centralisation is not bureaucracy in AI governance, it is the only way to preserve accountability at scale. The article's examples show that organisations without central policy enforcement end up compensating after the fact, when cleanup is more expensive and visibility is already lost. The field should expect governance platforms to converge around access, policy, and spend controls in one place. Practitioners should plan for that convergence now.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, 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, according to SailPoint.
• That governance gap mirrors the broader AI identity problem described in OWASP NHI Top 10, where runtime access and tool use must be constrained before autonomous behaviour scales further.

What this signals

Identity blast radius: AI programmes should now be assessed for how quickly a single agent can expand from a model call into data access, cost exposure, and downstream API activity. The risk is not only compromise, but uncontrolled runtime growth across identity, infrastructure, and finance teams. That makes a unified governance model more valuable than isolated technical fixes.

Enterprises that already struggle with service-account sprawl will recognise the pattern immediately. The difference is speed, because agentic workflows can create governance debt in days rather than months. Teams should prepare for higher demand on central policy enforcement, lifecycle records, and audit evidence across AI access paths.

A practical signal to watch is whether AI traffic is being measured with the same discipline as human and machine access. If teams cannot tell which agent used which data, when, and under what approval model, the programme is operating with a structural blind spot. That is where identity governance must move next, not after the next deployment wave.

For practitioners

• Map every AI entry point to an owner Inventory direct model calls, MCP servers, agent runtimes, and gateway paths, then assign a single accountable owner for each path. If no owner exists, the path is already outside governance.
• Bind AI access to policy at the gateway Enforce allowlists, scopes, request validation, and logging at the point where agents reach models or downstream APIs. Do not rely on application teams to implement equivalent controls independently.
• Classify AI traffic by identity, not just application Track which service accounts, API clients, or agent identities are invoking workloads, and tie each one to a lifecycle record for review, offboarding, and audit.
• Treat token spikes as governance alerts Set alerts for abnormal token consumption, unusual routing patterns, and model access outside expected operating hours. A cost anomaly often reveals a policy anomaly first.
• Standardise API specs before scaling agents Require predictable schemas, documented scopes, and observable responses for every API that an agent may call. Without that baseline, agent behaviour becomes difficult to constrain or investigate.

Key takeaways

• AI governance fails quickly when agents, APIs, and tokens are deployed faster than identity controls can be centralised.
• The article shows that shadow AI, weak API readiness, and unpredictable token spend are not separate issues, but linked governance symptoms.
• Practitioners should treat AI access, policy enforcement, and auditability as one control plane across human, machine, and agentic identities.

Key terms

• Shadow AI: Shadow AI is AI use that happens outside approved governance, visibility, or control. It usually appears when teams deploy agents, model calls, or integrations independently, leaving security, legal, and IAM teams without a clear record of what is running or what it can access.
• Agent-ready API: An agent-ready API is an interface that gives machine actors predictable schemas, stable authorization boundaries, and observable behaviour. It matters because agents do not tolerate ambiguity the way humans do, and inconsistent APIs often produce probing, retries, or unsafe fallback paths.
• Identity blast radius: Identity blast radius is the range of systems, data, and costs that one identity can affect when controls fail. In AI environments, it is shaped by model access, API scope, tool permissions, and the speed at which an agent can chain actions before review occurs.
• AI gateway: An AI gateway is a control point that mediates traffic between agents, models, and enterprise systems. Used well, it can enforce policy, logging, routing, and cost controls in one place, making AI behaviour easier to govern than scattered point integrations.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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: The AI Governance Wake-Up Call. Read the original.