API + AI Summit 2026 reframes AI and API governance

At a glance

What this is: Kong’s summit FAQ frames AI infrastructure and API platforms as a single operating problem for builders, architects, and platform leaders.

Why it matters: It matters because IAM teams increasingly have to govern human access, service identities, and autonomous AI behaviours through the same control plane.

By the numbers:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems.

👉 Read Kong's API + AI Summit 2026 FAQ on AI and API platform governance

Context

API and AI platforms now share the same identity problem. When builders connect models, tools, APIs, and cloud services, access decisions stop being a back-office IAM concern and become part of runtime system behaviour. That is why the keyword lens here is AI infrastructure governance, not simply event marketing.

Kong’s summit FAQ is a signal that practitioners are treating AI, APIs, and microservices as one architectural surface. For identity teams, that means service accounts, API keys, and AI-enabled automation cannot be governed in separate silos if the platform itself is mixing them in production.

Key questions

Q: How should security teams govern AI infrastructure that depends on APIs and microservices?

A: They should treat the combined stack as one identity system and map every machine-to-machine handoff, token, and delegated permission to an accountable owner. The key control is not the API gateway alone. It is the ability to trace, limit, and revoke access across the entire runtime path without relying on manual exception handling.

Q: Why do AI-enabled platforms complicate least privilege for IAM teams?

A: Because the system can initiate multiple tool calls and service interactions in one workflow, which expands the number of credentials and scopes that must be governed. Least privilege still matters, but it must be applied to runtime behaviour, not just to the initial request. That makes static role design an incomplete control on its own.

Q: What do IAM teams get wrong about AI and API security boundaries?

A: They often assume the boundary is the gateway or the front-door application layer. In practice, the larger risk sits in downstream delegated access, where credentials can be reused, inherited, or over-scoped across services and workflows. If that chain is not visible, the boundary is already broken.

Q: How can organisations tell whether their AI infrastructure governance is working?

A: Look for evidence that every sensitive credential has a named owner, a short lifespan, and a documented revocation path. If teams cannot answer who can act, when access expires, and how authority is withdrawn, governance is still aspirational rather than operational.

Background and context

AI infrastructure governance across APIs and microservices

AI infrastructure governance is the control problem created when models, APIs, gateways, and cloud-native services operate as one delivery stack. Identity is no longer limited to users and service accounts. It now includes tokens, credentials, and delegated access paths that move between systems at runtime. In that model, the gateway is only one enforcement point. The deeper issue is whether access is traceable, scoped, and revocable across every handoff in the execution chain.

Practical implication: map every AI and API dependency to an accountable identity owner before adding new automation paths.

Why AI and API platforms change trust boundaries

Traditional trust boundaries assume relatively stable callers and known service-to-service relationships. AI and API platforms break that assumption because the system may orchestrate multiple tools, call multiple endpoints, and change execution paths dynamically. That increases the importance of least privilege, short-lived credentials, and clear delegation rules. The problem is not that the stack is new. The problem is that the trust model becomes probabilistic unless identity controls are continuously enforced.

Practical implication: review where static credentials, broad scopes, and default service permissions still exist in AI-connected workflows.

Hands-on workshops and deep technical sessions as governance inputs

For identity teams, practitioner events matter when they surface implementation detail that strategy documents omit. Workshops and architecture sessions often reveal how teams are actually handling secrets, federation, token exchange, and access policy across mixed API and AI systems. That operational detail is useful because control design fails most often at integration boundaries, not in policy statements. The real value is learning how peers are instrumenting identity decisions where runtime automation meets platform engineering.

Practical implication: use peer implementation examples to test whether your current IAM and PAM controls still hold at the integration layer.

NHI Mgmt Group analysis

AI infrastructure is becoming an identity governance problem, not just an architecture problem. Once AI systems sit inside the same delivery path as APIs, microservices, and cloud services, identity controls stop being perimeter checks and start becoming runtime governance. Kong’s event framing reflects that convergence across platform engineering and security operations. Practitioners should treat AI infrastructure as a shared control plane where access, delegation, and revocation must be legible across the whole stack.

API platforms now expose the weakest part of many IAM programmes: delegated access. Service-to-service trust has always been fragile, but AI-connected systems multiply the number of places where a token, key, or session can be reused beyond the original intent. That creates governance pressure across NHI, PAM, and access review processes. The practitioner conclusion is that delegation chains need ownership, not just policy.

Identity governance for AI systems will be judged by operational traceability, not policy intent. Leaders can write standards for model access and platform use, but the real test is whether they can answer who or what had access, for how long, and under whose authority when a model calls a tool. That is the same accountability question that now spans human users, service identities, and autonomous behaviours.

Named concept: AI infrastructure identity sprawl. This is the condition where model tooling, API access, and cloud integration create more identities and credentials than teams can govern manually. It matters because the control problem shifts from provisioning a few trusted service accounts to containing a growing mesh of runtime identities. Practitioners need to treat identity inventory as part of AI platform design, not as an afterthought.

The summit agenda suggests the market is moving toward integrated platform governance. Builders, architects, and technology leaders are being brought into the same conversation because separate AI, API, and identity programmes are no longer operationally clean. That points to a governance model where security, platform engineering, and IAM share responsibility for the runtime behaviour of modern systems. The practitioner implication is to align those teams before adoption outpaces control design.

From our research:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to The 2026 Infrastructure Identity Survey.
• That same survey found 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• For a broader control model, see OWASP Agentic AI Top 10 for runtime risk patterns that overlap with API-connected AI infrastructure.

What this signals

AI infrastructure identity sprawl: the practical challenge is no longer just secret storage or gateway policy, but the number of identities created by model-driven workflows across APIs and cloud services. Once those identities multiply, governance depends on inventory, ownership, and revocation discipline across the full path. Teams should expect platform engineering and IAM to share the same control surface rather than operate in sequence.

With 70% of organisations already granting AI systems more access than a human employee would receive for the same job, per the 2026 Infrastructure Identity Survey, the risk is structural rather than theoretical. Programmes that still separate API governance from AI governance will struggle to explain who actually had authority when a workflow touched production systems.

The forward signal is clear: practitioners will need to align AI platform design with identity controls from the start, not after adoption. Resources such as the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework are becoming useful references for that convergence.

For practitioners

• Inventory AI-connected identities List every service account, token, API key, and delegated credential used by model-driven workflows, then assign an owner and revocation path for each one.
• Tighten scopes on runtime credentials Replace broad standing permissions with short-lived credentials and the smallest viable API scopes for each AI-connected integration.
• Test governance at the integration layer Run access reviews against the actual AI and API execution path, including gateways, orchestration layers, and downstream services.
• Separate platform convenience from authority Do not let the same identity that deploys or configures the platform also retain broad runtime access to production AI and API systems.

Key takeaways

• AI infrastructure and API platforms are converging into a single identity governance problem that security teams can no longer manage in separate silos.
• The main control issue is delegated runtime access, where service accounts, tokens, and AI-driven workflows can expand authority faster than review processes can track.
• IAM and platform teams should align on inventory, ownership, and revocation for every AI-connected credential before scaling automation further.

Key terms

• AI Infrastructure Identity Sprawl: The growth of identities, tokens, keys, and delegated permissions created by AI-connected workflows across APIs, services, and cloud platforms. It becomes a governance problem when teams cannot reliably inventory who or what can act, how authority is granted, and how access is removed.
• Delegated Access: Access that one identity uses on behalf of another identity or workflow. In AI and API environments, delegated access often crosses multiple services, which makes ownership, revocation, and accountability harder to maintain unless the chain is explicitly governed.
• Runtime Governance: The control of identity and access decisions while a system is operating, not just when it is designed or provisioned. For AI-connected platforms, runtime governance covers session scope, token use, tool calls, and revocation paths as they happen.

Deepen your knowledge

AI infrastructure identity governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI-connected APIs and runtime workflows, it is worth exploring.

This post draws on content published by Kong: API + AI Summit 2026 FAQ on AI and API infrastructure. Read the original.