API security is becoming identity security for the agentic era

At a glance

What this is: Kong's analysis argues that APIs are evolving into regulated infrastructure and that AI readiness is lagging behind broad API adoption.

Why it matters: For IAM teams, this matters because API governance is increasingly an identity problem spanning machine identity, delegated authorization, and agent access control.

By the numbers:

• Only 24% design APIs for AI agents.
• 83.2% of respondents have adopted some level of an API-first approach.
• 65% of organizations that use APIs are currently generating revenue from them.

👉 Read Kong's analysis of the rapidly changing API ecosystem

Context

APIs are no longer just integration endpoints. In regulated environments they function as operational infrastructure, and the article's core point is that identity, authorization, and machine-readable policy now sit at the centre of API governance, especially as AI agents become API consumers.

That shift forces IAM and security teams to treat API design as a governance issue rather than a pure engineering choice. The problem is not only adoption at scale, but whether current access controls, contracts, and audit models can handle non-human clients that act at runtime across multiple protocols and transports.

Kong's framing is typical of the broader market transition: organizations have widely adopted APIs, but many have not rebuilt the identity controls around them for machine-to-machine and agentic consumption.

Key questions

Q: How should security teams govern API access for AI agents and service accounts?

A: Security teams should treat API access as a governed identity path, not a transport detail. That means assigning ownership to each machine consumer, limiting scopes to specific tasks, enforcing token binding where possible, and maintaining audit logs that tie every call to an identity and policy decision.

Q: When does API-first design create more governance risk than it removes?

A: API-first becomes risky when teams treat it as a delivery pattern instead of an identity model. If scopes, authorization context, and telemetry are added later, the organization usually accumulates exceptions across gateways, protocols, and agent integrations that are hard to review and even harder to retire.

Q: What do organisations get wrong about securing AI-ready APIs?

A: They often assume that better documentation is enough. AI-ready APIs need machine-readable contracts, deterministic authorization, and consistent enforcement across every path the agent can reach. Without those controls, the API may be functional for developers but unreliable for governed machine consumption.

Q: How can teams tell whether API governance is actually working?

A: A working programme can answer four questions quickly: who owns the consumer, what it can access, where the policy is enforced, and how the call is logged. If any of those answers differ across protocols or gateways, the control model is fragmented and needs consolidation.

Technical breakdown

Why API-first design is now an identity control problem

API-first used to describe development sequencing, but in 2026 it increasingly determines how identity is enforced at runtime. If APIs are the primary interface, then authentication, authorization, and policy enforcement must be expressed in machine-readable form from the start. That matters because AI agents and service integrations do not interpret controls the way humans do. They need explicit scopes, predictable error handling, and deterministic policy boundaries. When teams retrofit identity controls after the fact, they usually preserve human-centric assumptions and create brittle exceptions around machine consumers.

Practical implication: treat API design reviews as identity design reviews, with scopes, claims, and enforcement points validated before launch.

OAuth 2.0 security and delegated access in machine-to-machine estates

The move to RFC 9700 reflects a broader tightening of OAuth security expectations. Deprecated flows such as the implicit grant and resource owner password credentials no longer fit modern threat models, especially where public clients, gateways, and AI-facing services exchange tokens across systems. For machine identities, the central issue is not just getting a token, but limiting what that token can do, where it can be replayed, and how much trust is embedded in the exchange. Token binding, sender-constrained access, and explicit authorization context are becoming more important than generic bearer-token convenience.

Practical implication: revalidate OAuth flows for every API and agent integration, especially where bearer tokens still cross service boundaries.

Why multi-protocol and event-driven APIs expand the governance surface

The article shows that REST is no longer the only protocol in play. GraphQL, gRPC, CloudEvents, AsyncAPI, WebSocket, and HTTP/3 each shift how identities are authenticated, scoped, and observed. That creates governance complexity because different transports and protocols often carry different assumptions about session state, persistence, and auditability. A central gateway model can help, but only if policies, telemetry, and enforcement stay consistent across all entry points. Otherwise teams end up with partial visibility, inconsistent authorization, and fragmented review processes.

Practical implication: map identity policy coverage across every protocol and gateway, not just the primary REST path.

NHI Mgmt Group analysis

API governance is becoming machine identity governance. Once APIs become the primary interface for regulated and revenue-generating systems, the real control plane is no longer the endpoint catalogue. It is the identity and policy layer that decides which humans, workloads, and agents can invoke which actions. That makes API programmes inseparable from NHI governance, because every machine consumer is now part of the identity perimeter.

AI agents expose the API trust model's biggest blind spot. Traditional API design assumes that consumers follow documented paths, but agentic consumers can chain requests, explore workflows, and operate at machine speed. The 24% figure for AI-agent-ready APIs shows the category has not caught up to that behavioural shift. Practitioners should read this as a sign that static API controls are being asked to govern dynamic runtime intent, which they were not built to do.

Machine-readable contracts are now a governance requirement, not a documentation feature. OpenAPI alignment, overlays, and orchestration specs matter because they let security, compliance, and operations interpret the same access model. Without that common language, policy drifts across gateways, environments, and protocols. The implication is that identity teams need contracts they can enforce, not just specifications they can publish.

Boundary sprawl is the new API risk multiplier. Multi-gateway estates, event-driven flows, and commercialised network APIs increase the number of places where identity decisions can fragment. That creates more opportunities for inconsistent scopes, orphaned access paths, and weak observability. The practical conclusion is that governance has to follow the traffic, not just the platform diagram.

From our research:

• 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.
• That governance gap is why practitioners should also review OWASP Agentic AI Top 10 alongside API policy controls.

What this signals

The practical signal for IAM leaders is that API security reviews will increasingly overlap with workload identity, delegated authorization, and agent governance reviews. With 98% of companies planning to deploy even more AI agents within the next 12 months, per AI Agents: The New Attack Surface report, the pressure on identity teams will come from scale, not from isolated incidents.

Runtime API policy gap: the next control failure will be a mismatch between protocol diversity and identity enforcement consistency. If a programme cannot produce one auditable answer across REST, GraphQL, gRPC, and event-driven paths, it is already operating with fragmented governance.

Teams should expect policy work to move closer to contract management, gateway configuration, and telemetry design. For readers building agentic controls, the best next reference point is OWASP Top 10 for Agentic Applications 2026, because API consumers are no longer only human or static workload identities.

For practitioners

• Reclassify API governance as identity governance Inventory every API consumer type, including service accounts, workload identities, and AI agents, and map each to an owner, scope, and review cadence.
• Revalidate OAuth flows against current best practice Replace deprecated grant patterns, tighten token scope, and verify that sender-constrained or bound token patterns are used where bearer replay would be material.
• Unify policy across protocols and gateways Check that REST, GraphQL, gRPC, WebSocket, and event-driven interfaces all inherit the same authorization rules, logging, and rate-limiting logic.
• Build audit coverage for AI agent access paths Ensure every agent-facing API call can be traced to an identity, a policy decision, and a business owner so that review and incident response remain possible.

Key takeaways

• APIs are now a governance surface for humans, workloads, and AI agents, which makes identity policy central to the API stack.
• The gap between broad API adoption and AI-agent-ready design shows that many organisations still rely on human-centric assumptions.
• Practitioners should unify authorization, auditability, and contract enforcement across every protocol before agent traffic scales further.

Key terms

• API-first: An API-first organisation designs application interfaces before or alongside the application itself. In identity terms, that means the access model, scopes, and policy enforcement are part of the product architecture rather than added later as a retrofit.
• Sender-constrained token: A sender-constrained token is bound to a specific client so that a stolen bearer token cannot be reused elsewhere. This reduces replay risk and is especially relevant when non-human clients, gateways, or agents move credentials between systems.
• Machine-readable contract: A machine-readable contract is an API specification that software can validate, enforce, and monitor automatically. For identity teams, it becomes a governance asset because scopes, policy, and auditing can be aligned across development, operations, and security.

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 Rapidly Changing Landscape of APIs: Navigating the 2026 API Ecosystem. Read the original.