Kong Connect 2026 in Los Angeles: IAM implications for builders

At a glance

What this is: Kong Connect 2026 is a two-day in-person conference in Los Angeles focused on builders, with sessions that frame API and platform identity decisions around service access, secrets and agentic workloads.

Why it matters: IAM, IGA and platform security teams should pay attention because API and platform events increasingly shape how non-human access is designed, trained and operationalised before governance teams see the downstream control gaps.

By the numbers:

• Kong Connect 2026 runs in Los Angeles from Sept. 30 to Oct. 1, 2026.
• The early bird ticket price is $249.
• The standard ticket price is $449.
• Only 100 seats are available for the certification training add-on.

Context

Kong Connect 2026 is an in-person event in Los Angeles on Sept. 30 to Oct. 1, 2026, with a certification training add-on running Sept. 29 to Oct. 1. The article frames the conference around keynotes, product launches, hands-on workshops and deep technical sessions for builders.

For identity teams, the relevance is not the event itself but the operating model it reflects. API platforms, service authentication and developer tooling increasingly shape how non-human access is created, consumed and governed across modern application stacks.

The article also signals a training-led conference format, with a limited-seat certification track and tiered ticketing. That makes the event a useful marker for how vendors are packaging implementation knowledge around identity-adjacent platform controls.

Key questions

Q: How should security teams govern API access as a non-human identity?

A: Security teams should inventory APIs as identities, assign an accountable owner, and enforce lifecycle controls for issuance, rotation, expiry, and revocation. The goal is to make access explicit and reviewable rather than hidden in code, pipeline variables, or shared credentials. Without that discipline, machine access becomes unmanaged trust instead of governed identity.

Q: Why do builder platforms create governance gaps for service accounts and tokens?

A: Because builders can create, embed and reuse access in the same workflow that ships code. That collapses the distance between provisioning and use, so standing credentials can spread faster than central review processes can track them. The risk is not just weak policy, but identity control moving outside the governance boundary.

Q: What breaks when teams treat secrets management as only a developer responsibility?

A: When secrets management sits only with developers, governance gaps usually appear. Security teams lose visibility into how secrets are created, stored, shared, and rotated across platforms. That leads to inconsistent controls, weak auditability, and higher exposure risk. Effective programmes need shared ownership, policy enforcement, and continuous discovery across the software lifecycle.

Q: How can organisations tell whether platform identity governance is keeping up?

A: Look for whether access decisions, credential issuance and revocation are documented at the platform layer and not just in policy. If teams cannot show who owns service authentication, where secrets live, and how access is removed when workloads change, the governance model is lagging the architecture.

Background and context

Why API platforms now sit inside identity control planes

API gateways and platform tooling now influence who or what can authenticate, call services, and carry credentials through application paths. That matters because non-human identities are often created, brokered, or constrained in the same place developers enforce traffic policy and service access. In practice, the identity boundary is no longer just a directory or IAM console. It extends into runtime systems that decide how workloads, bots, and services obtain access and how long that access persists.

Practical implication: IAM and platform teams need shared governance over service authentication, credential issuance, and access boundaries.

Why builder-focused conferences increasingly cover secrets and service access

When an event combines keynotes, product launches, workshops and deep technical sessions, it usually reflects a shift from abstract strategy to implementation detail. In this case, the subject matter points to the mechanics of service access, API credentials, and the operational controls that support application builders. For identity practitioners, that is where governance fails most often: when teams treat developer convenience and access control as separate problems rather than one system.

Practical implication: review whether your governance model reaches the tools builders actually use to mint and store credentials.

What certification training signals about identity capability maturity

A limited-seat certification track is more than event marketing. It signals that the underlying subject has moved into repeatable practice, where teams need common language, shared operating procedures, and a baseline understanding of the control model. For identity programmes, that usually means the topic has progressed from awareness to implementation discipline. The question becomes not whether the capability exists, but whether teams can deploy it without creating blind spots in access review, offboarding, or privilege scope.

Practical implication: use the topic as a cue to test whether your builders and security teams share the same control vocabulary.

NHI Mgmt Group analysis

Builder platforms now shape identity outcomes before IAM teams do. When an API platform becomes the place where access is designed, the governance problem shifts left into developer workflows. That means the most important control decisions may be made before central identity teams ever see the request. For practitioners, this is a reminder that identity architecture is increasingly distributed across the platform layer, not just managed in a directory or access request tool.

Service access and secrets management are converging into one operational problem. The article points to a conference agenda built around product launches, technical sessions and hands-on workshops, which is usually where implementation detail lives. In identity terms, that detail matters because the same platform often brokers authentication, hides secrets, and enforces traffic decisions. The field should treat that convergence as a governance boundary, not a convenience feature.

Certification tracks are a signal that control knowledge is becoming a prerequisite for delivery. When training is attached to a builder conference, the market is acknowledging that teams need repeatable operational skill, not just policy statements. That aligns with NIST-CSF governance expectations and with identity lifecycle discipline across non-human identities. Practitioners should expect platform teams to need explicit identity guardrails, not informal understanding.

Identity control is moving into the application supply chain. Builders now assemble access patterns as part of their delivery process, which makes secrets, service authentication and workload boundaries part of the software operating model. For identity leaders, that means governance has to cover the path from development intent to runtime access, or the control framework will always lag the implementation reality.

Kong Connect 2026 reflects a market that is educating builders about identity-adjacent controls, not just shipping tooling. That matters because the next phase of NHI governance will depend on whether platform teams can adopt consistent access patterns before they scale them across services and environments. The practitioner takeaway is to align platform enablement with identity policy early, when conventions are still forming.

What this signals

Identity control is migrating into the platform layer. As builders absorb more of the access design work, central IAM teams lose some of their ability to govern by request flow alone. The programme question becomes whether platform engineering and identity governance are operating from the same lifecycle model for non-human access.

Certification and workshop formats are a sign of operational maturity pressure. When a conference adds hands-on technical training around builder workflows, it usually means practitioners need to translate policy into repeatable execution. That is where identity programmes often stall, because the controls exist but the platform teams do not own the operating language that makes them usable.

API platforms are becoming the place where NHI governance either succeeds or fails. If credentials are created, moved and consumed inside the development toolchain, governance has to follow those actions instead of staying at the perimeter. Teams should use this as a prompt to review whether lifecycle controls extend into the systems builders actually use.

For practitioners

• Map platform ownership of access decisions Identify where API gateways, service meshes, developer portals or runtime tooling currently create or broker access for non-human identities. Clarify which team approves, issues, rotates and revokes those credentials.
• Review secrets handling in builder workflows Trace how API keys, tokens and certificates move through build, test and deployment workflows. Remove any workflow where builders can persist credentials outside governed storage or bypass lifecycle controls.
• Align certification training with control ownership Use the conference training signal to identify whether your platform engineers and identity team share the same vocabulary for least privilege, service authentication and offboarding.
• Define governance for agentic workload access If your application roadmap includes AI agents or autonomous workflows, decide now how their access will be issued, reviewed and revoked before those systems are embedded in production paths.

Key takeaways

• API and platform teams are increasingly shaping identity boundaries for services, secrets and emerging automated workloads.
• The article shows a control-oriented conference model, with workshops and limited-seat training underscoring the need for repeatable operational knowledge.
• Identity governance needs to move closer to the platform layer if organisations want to manage non-human access consistently.

Key terms

• Platform-Led Identity Control: A governance model where identity decisions are made inside the developer or runtime platform rather than only in central IAM tools. It matters because access, secrets and service authentication are increasingly created where software is built and run, which can bypass traditional review points if not explicitly governed.
• Service Authentication: The process by which a workload, API or service proves its identity to another system before it can act. In practice, this includes certificates, tokens and other machine credentials, and it becomes a governance problem when teams cannot trace issuance, scope, rotation and revocation end to end.
• Credential Lifecycle: Credential lifecycle is the process of issuing, rotating, expiring, and revoking secrets, certificates, and tokens across their usable life. For non-human identities, lifecycle discipline is the core control that separates temporary access from persistent exposure.
• GitHub Workflow: A GitHub workflow is an automated sequence of build and test steps defined for a repository. In this context, it is used to prove that a codebase can compile into WebAssembly in a repeatable way and that the resulting build still passes unit tests in an automated environment.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.