API + AI Summit 2026 spotlights production AI and security

At a glance

What this is: This is a call for proposals for Kong’s API + AI Summit 2026, and its key finding is that production AI, API architecture, security, observability, and zero trust are being treated as one operating problem.

Why it matters: It matters because IAM, NHI, and platform teams now have to govern AI systems where connectivity, access, and operational reliability are intertwined rather than separately owned.

Context

API and AI convergence is no longer a design curiosity. The article frames production AI, API architecture, security, zero trust, observability, and automation as the same operating environment, which means identity governance has to follow the runtime path rather than stop at the model boundary.

For IAM and NHI practitioners, the important shift is that governance questions move into platform engineering decisions. Access scope, workload trust, service-to-service authentication, and operational visibility all become part of how AI systems are built and run, not just how they are approved.

The article is a call for real-world sessions, but the underlying signal is broader than an event agenda. It shows that teams are looking for practical accounts of how modern systems behave in production, and that makes identity, policy, and observability inseparable from AI operations.

Key questions

Q: How should teams govern AI agents that can reach APIs, events, and memory?

A: Teams should govern those agents as runtime identities, not as isolated integrations. That means enforcing policy at execution time, logging every tool and data access, and binding actions back to a clear initiating workflow or identity. If the control plane cannot show who acted, what they reached, and why, the programme does not have usable governance.

Q: Why do production AI systems increase the need for zero trust?

A: Because the risk is no longer only user access, it is the set of machine-to-machine paths that AI workloads can follow once they are deployed. If those paths inherit broad trust, the AI can reach data and tools that were never meant to be continuously available, which weakens the zero-trust model.

Q: What breaks when organisations rely only on observability for AI governance?

A: Observability breaks at the point where action is needed, because it records the event after the response has already been generated or delivered. That is useful for investigation, but it does not stop hallucinated policy, off-brand content, or prompt manipulation. The result is visibility without control.

Q: How do NHI and workload identities affect AI governance?

A: They define who and what can move data, retrain models, invoke services, and export outputs. That makes service accounts, tokens, and workload credentials part of the AI security boundary. If those identities are over-privileged or poorly tracked, the model inherits that exposure.

Background and context

Production AI depends on API-mediated identity paths

Production AI systems do not sit outside the application stack. They depend on API calls, service credentials, orchestration layers, and platform controls that decide what the system can reach at runtime. In practice, that means the trust model is not only about model output quality, but about which services, data sources, and execution paths the AI can invoke through authenticated interfaces. When teams treat the AI as isolated from the surrounding platform, they miss the actual control plane where access is granted and observed.

Practical implication: govern AI runtime access through the same identity and authorization paths that control other production services.

Zero trust for AI is about execution boundaries, not slogans

Zero trust in this context means the AI system should not inherit broad trust simply because it runs inside an approved environment. Every call, credential use, and downstream action still needs explicit authorization and visibility. For AI platforms, that becomes a question of workload identity, short-lived access, and how far an orchestration layer can move before a control decision is made. If teams only apply zero trust to user logins, they leave the machine-to-machine path largely ungoverned.

Practical implication: define explicit execution boundaries for AI services and verify them continuously at the API layer.

Observability is the governance layer that exposes AI drift

Observability is not just an SRE concern when AI is in production. It is the only way to see when an AI workflow is making unexpected calls, chaining requests in unusual sequences, or touching systems that were not part of the intended design. That matters for identity because overreach is often visible first as a path through logs, traces, and API usage patterns. Without that telemetry, teams cannot tell whether the AI is acting within its intended scope or slowly expanding into adjacent services.

Practical implication: instrument AI-connected APIs so that access anomalies, scope drift, and unusual call chains are visible to security and platform teams.

NHI Mgmt Group analysis

Production AI governance now lives inside the API control plane. The article is not really about an event. It is a signal that organisations are starting to treat AI runtime behaviour as part of API architecture, where authentication, authorisation, observability, and policy enforcement are already managed. For IAM teams, that collapses the old separation between “AI governance” and “platform security”.

Zero trust for AI is an execution model, not a branding layer. The relevant question is whether AI-connected services can be constrained at the point of request, call, and downstream invocation. If the AI can reach data or tools through broadly trusted service paths, the zero-trust claim is mostly cosmetic. Practitioners should read this as pressure to move policy closer to runtime control.

API and AI convergence strengthens the case for workload identity discipline. Production AI systems inherit the identity properties of the services around them, which means weak service authentication becomes AI governance debt. This is where NHI practice matters most: short-lived credentials, scoped access, and clear ownership of service identities. The programme implication is that AI security and NHI security are now the same operational conversation.

Observability is becoming an identity control, not just a reliability control. When AI systems chain API calls in production, the first sign of scope expansion may be in telemetry rather than policy. That makes logs, traces, and request correlation part of governance evidence. Teams that separate security review from runtime visibility will miss the control failures that matter most.

Runtime governance gap: This article describes a field that is maturing around production AI, but the real gap is the absence of a stable governance model for AI systems that can act through ordinary platform credentials. The implication is not that teams need more AI talk tracks. It is that they need a unified identity and policy model for every API call an AI makes.

What this signals

Production AI is forcing security and platform teams to converge on the same control plane. That shift matters because the most important governance questions now sit where APIs, workload identity, and runtime policy meet, not in a separate AI review process.

Runtime governance gap: The defining issue is not whether AI is in the stack, but whether its service identities are being governed as production assets. Teams that cannot trace AI-driven calls back to scoped credentials will struggle to prove control over the environment.

For practitioners, the next stage is to stop treating observability as an operations-only concern. When AI systems make real calls in production, telemetry becomes the evidence base for access review, policy enforcement, and exception handling.

For practitioners

• Map AI-to-API dependency chains Inventory which AI workloads call which APIs, data services, and orchestration endpoints, then identify where credentials, tokens, or service identities are reused across those paths.
• Constrain service identity scope Apply the minimum feasible permissions to the workloads that support production AI so that each service identity can only invoke the functions it truly needs.
• Treat observability as governance evidence Correlate API logs, traces, and access records so that unusual request chains or tool calls can be reviewed as identity events rather than only operational anomalies.
• Separate demonstration logic from production access Require a clear boundary between conference-worthy prototypes and the identities, credentials, and controls that govern live AI services in production.

Key takeaways

• The article signals that production AI, API architecture, and security are converging into one governance problem rather than three separate ones.
• For IAM and NHI teams, the practical risk is uncontrolled machine-to-machine access, especially when service identities and orchestration paths are not tightly scoped.
• Identity governance for AI now depends on runtime visibility, workload identity discipline, and explicit boundaries around what production systems can call.

Key terms

• Production AI: AI that is embedded in live business processes rather than isolated in experimentation. Once AI reaches production, its inputs, outputs, and decision paths become operational controls, making governance, traceability, and accountability part of the system design.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
• Runtime Governance: Runtime governance is the set of controls that verify what a system or agent is actually doing after deployment. It combines monitoring, authorization checks, and access validation so teams can detect drift, misuse, or excessive privilege in motion rather than assuming build-time policy still holds.
• Zero Trust: A security model that assumes no identity, human or non-human, should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.

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 building or maturing an IAM programme, it is worth exploring.