Kong Connect 2026 in Los Angeles: IAM implications for builders

At a glance

What this is: Kong Connect 2026 is a Los Angeles conference focused on APIs, platform tooling, and technical sessions that intersect with identity, access, and security operations.

Why it matters: It matters to IAM practitioners because API gateways, workload access, and emerging agent-facing controls often become the practical enforcement layer for NHI, autonomous, and human identity governance.

👉 Read Kong's full Kong Connect 2026 event page

Context

Kong Connect 2026 is a two-day in-person conference in Los Angeles on Sept. 30 to Oct. 1, with an additional certification training option beginning Sept. 29. The article positions the event around keynotes, product launches, workshops, and deep technical sessions rather than a single security theme.

For identity teams, the relevant question is not whether this is an API conference but how API infrastructure increasingly becomes identity infrastructure. When access to services, tokens, and automation flows sits inside gateway and platform layers, IAM, NHI governance, and runtime authorisation all become part of the same control plane.

Key questions

Q: How should security teams govern identity at API gateways and platform layers?

A: Security teams should treat API gateways, service meshes, and platform policy engines as identity enforcement points, not just traffic infrastructure. The goal is to align authentication, token validation, authorisation, and logging across the whole request path so revocation and review still work when access is distributed across multiple runtime layers.

Q: Why do workload identities create governance gaps in platform environments?

A: Workload identities create governance gaps when credentials, certificates, and tokens are issued in one system but consumed in many others. The risk is lifecycle fragmentation. Teams lose sight of where access is used, how it is rotated, and whether revocation is effective everywhere the identity exists.

Q: What do teams get wrong about agent-facing API access?

A: Teams often assume static service permissions are enough for agents, but agent-driven work is selected at runtime and can change within a session. That makes conventional provisioning models too coarse. Security teams need policy checks that evaluate action, context, and delegation at the moment the request is made.

Q: Who should own access decisions when identity controls are spread across multiple platforms?

A: One accountable owner should be assigned for each control layer that can grant, narrow, or revoke access. Without that split of responsibility, identity control plane drift sets in and no team can explain which system is authoritative for denial, revocation, or audit evidence.

Background and context

API gateways as identity enforcement points

An API gateway is not just a routing layer. In many enterprises it becomes the place where authentication, token validation, rate limiting, and policy enforcement converge before requests reach back-end services. That makes it a practical control point for both human users and non-human identities, especially where tokens or service credentials are being exchanged at runtime. The architectural risk is that gateway policy can drift away from upstream IAM assumptions, leaving access decisions fragmented across teams and systems.

Practical implication: map gateway policies to the identities they actually govern, then test whether token handling, scope checks, and revocation paths still align.

Workload identity and secret handling in platform layers

Workload identity is the pattern of identifying machines, services, and automated processes without relying on shared human-style credentials. In practice, platform teams often mix certificates, API keys, JWTs, and vault-backed secrets across services, which creates hidden trust dependencies. The problem is not just exposure of a secret, but the operational uncertainty around where it is used, how long it remains valid, and whether access can be revoked cleanly. That is why NHI governance often fails at the integration boundary, not the vault itself.

Practical implication: inventory where workload credentials are minted, stored, and exchanged so revocation and rotation can be verified end to end.

Agent-facing APIs and runtime authorisation

As agents begin to call tools and services, the API layer starts to mediate actions that are selected at runtime rather than fixed in advance. That changes the security model from simple access control to contextual authorisation, because the same identity may request different tools, datasets, or scopes within a single session. The key architectural question is whether the platform can express least privilege when intent is dynamic and execution timing is not human paced. Where it cannot, the API layer becomes an amplifier of privilege rather than a constraint.

Practical implication: require per-action policy checks for agent-facing APIs and separate static service access from runtime tool invocation.

NHI Mgmt Group analysis

API infrastructure is increasingly where identity governance is actually enforced, even when IAM teams do not own it. Conferences like this matter because gateway, platform, and developer tooling now sit on the path of authentication, token exchange, and service-to-service access. That makes the operational boundary between API management and identity management far less clean than most programmes assume. Practitioners should treat API layers as identity control points, not just application plumbing.

Workload access fragmented across gateways, vaults, and service tokens creates governance debt. The article’s mix of workshops, launches, and technical sessions reflects where practitioner attention is going: distributed control rather than centralised identity enforcement. Once access spans multiple runtime systems, the real problem becomes lifecycle consistency across secrets, certificates, and machine identities. The implication is that access governance must be validated where the workload executes, not only where the secret is issued.

Agent-facing APIs introduce a new control problem because intent is dynamic at runtime. That is a different challenge from conventional service authentication, which can often be provisioned and reviewed in advance. When an autonomous or semi-autonomous actor selects actions during execution, the authorisation boundary must evaluate context continuously. Practitioners should recognise that traditional static access models lose precision once the actor is choosing its own path through the API surface.

Named concept: identity control plane drift. This is the condition where identity decisions migrate into API gateways, platform tooling, and runtime policy engines without a single accountable model. The drift is not inherently bad, but it becomes a governance failure when teams no longer know which layer owns authentication, authorisation, revocation, or review. Practitioners should define ownership across the entire request path before policy sprawl turns into blind spots.

Event programming around product launches is a signal that security teams are still being asked to evaluate architecture while the market is moving underneath them. For IAM leaders, that means platform events are no longer just product showcases. They are places where identity assumptions about services, agents, and workflows are being operationalised in public. Practitioners should use that signal to reassess whether their current governance model still matches how access is actually being consumed.

From our research:

• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
• 35.6% of organisations cite managing consistent access across hybrid and multi-cloud environments as their top NHI security challenge.
• For a broader governance baseline, Ultimate Guide to NHIs frames the lifecycle and visibility controls teams need before platform sprawl becomes identity drift.

What this signals

Identity control plane drift: as API gateways, service meshes, vaults, and agent-facing tools each gain enforcement power, the risk is not only broken policy but broken accountability. Platform teams should expect more identity decisions to move out of the IAM console and into runtime systems, which means ownership maps and audit paths must follow the traffic, not the org chart.

That shift also changes operating priorities. When security teams are still confident in workload identity governance at a low rate, the next phase is not more abstraction but better traceability across issuance, use, and revocation. For practitioners, the practical question is whether current controls can still explain who or what was authorised at the moment access was consumed.

For practitioners

• Audit API gateways as identity enforcement points Trace where authentication, token validation, and policy enforcement occur across gateway and mesh layers. Verify that the same request path has clear ownership for denial, revocation, and logging.
• Inventory workload credentials across platform layers Map certificates, API keys, JWTs, and vault-issued secrets to the services that consume them. Confirm that rotation and revocation work across every runtime location where those credentials are cached or exchanged.
• Separate static service access from runtime agent actions Do not let a long-lived service identity inherit the same permissions as a session-driven agent. Require per-action checks for tool calls, data access, and delegation paths that can change during execution.
• Define ownership for identity control plane drift Assign one accountable team to each layer that can authenticate, authorise, or revoke access. That includes gateways, vaults, service meshes, and any policy engine that can override or narrow access decisions.

Key takeaways

• API and platform layers are becoming de facto identity enforcement points, which makes their governance an IAM problem as much as an application problem.
• Workload identity sprawl creates lifecycle fragmentation when credentials, tokens, and certificates are managed in separate runtime systems.
• Security teams should define ownership for every layer that can authenticate, authorise, or revoke access before policy drift creates blind spots.

Key terms

• API gateway: A gateway that sits between clients and services to enforce access, route requests, and apply policy. In identity security, it often becomes a real-time checkpoint for authentication, token validation, and authorisation, which makes governance depend on the quality of the policies configured there.
• Workload identity: The identity assigned to a machine, service, or automated process so it can authenticate without a human user account. It is usually represented through certificates, tokens, or service credentials, and it needs lifecycle controls that cover issuance, rotation, scope, and revocation.
• Identity control plane drift: The gradual spread of identity decisions across gateways, vaults, policy engines, and runtime tools without clear accountability. This creates a governance problem because no single team can reliably explain which system is authoritative for authorisation, revocation, or audit evidence.

Deepen your knowledge

API gateway governance, workload identity, and runtime authorisation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are aligning platform security with identity controls, it is worth exploring.

This post draws on content published by Kong: Kong Connect 2026 in Los Angeles. Read the original.