API + AI Summit 2026 spotlights production AI and security

At a glance

What this is: Kong is framing API + AI Summit 2026 around production AI, API architecture, security, and reliability, with in-person sessions in Los Angeles on September 30 to October 1, 2026.

Why it matters: For IAM, NHI, and platform teams, the agenda reflects where identity control, zero trust, and operational resilience are converging in live AI systems rather than isolated pilots.

👉 Read Kong's call for proposals for API + AI Summit 2026

Context

API + AI Summit 2026 is not a product briefing, but a call for practical sessions on how AI systems run in production. The primary governance question is simple: when AI, APIs, and platform engineering meet in the same architecture, which identity and access assumptions still hold?

That matters because modern AI delivery depends on service accounts, tokens, orchestration layers, and cross-system permissions that are easy to accumulate and hard to govern. The event’s focus on security, zero trust, observability, and reliability points to a broader shift in which identity is becoming part of the runtime substrate, not a separate control plane.

Key questions

Q: How should security teams govern AI systems that rely on APIs in production?

A: Security teams should treat every API connection as an access path that must be owned, scoped, logged, and revocable. That means assigning identities to workloads, limiting token scope to the minimum required function, and recording which downstream action each request triggered. If the system cannot prove who acted and why, governance is incomplete.

Q: Why do AI and API architectures change the identity risk model?

A: They change it because the system now acts through multiple non-human identities, not just through one authenticated user. Each integration adds a new trust edge, and each edge can widen the blast radius if permissions are reused or left standing. The result is a governance problem built around execution paths, not just accounts.

Q: What should teams measure to know whether AI access controls are working?

A: Teams should measure identity lineage, token scope, privilege duration, and the percentage of AI actions that can be traced to an approved owner. If logs cannot connect the initiating identity to the executed action, then the control set may exist on paper but not in practice.

Q: Should organisations use zero trust for AI orchestration and automation?

A: Yes, but only if zero trust reaches the point where AI systems actually take action. That means verifying the requester, the workload, and the execution boundary at runtime instead of assuming a secure deployment is enough. Otherwise, orchestration becomes a trusted shortcut around governance.

Background and context

API and AI connectivity in production

Production AI does not live in a vacuum. It depends on APIs for retrieval, orchestration, authentication, logging, and downstream execution, which means the security model is really a permission model across multiple systems. When an LLM, agent, or workflow touches external tools, the identity questions shift from login to runtime authorization, secret handling, and traceability. In practice, the risk is less about a single compromised account and more about how many connected paths can be reached through one poorly governed integration.

Practical implication: map every AI-connected API call to an owning identity, entitlement, and revocation path before the system goes live.

Zero trust for AI systems and platform automation

Zero trust in AI environments is not just about network segmentation. It is about assuming that every component, human or machine, can be over-permissioned, reused, or misrouted unless continuously verified. Platform automation often hides this problem because the pipeline looks controlled while the actual execution path may span multiple identities, scopes, and approval states. For AI systems in production, zero trust means verifying the requester, the workload, the data path, and the action boundary at runtime, not just at deployment.

Practical implication: enforce continuous verification across the AI request path, especially where automation can trigger actions outside the original approval scope.

Observability and reliability as identity controls

Observability is often treated as a performance discipline, but in AI and API ecosystems it is also an identity control. If you cannot trace which identity initiated a request, which token was used, and which downstream action was taken, then you cannot reliably investigate abuse or privilege drift. Reliability matters for the same reason: a failing control plane can cause teams to grant broader standing access as a workaround, which turns an operational issue into an access issue. The architectural lesson is that telemetry and entitlement governance are now tightly coupled.

Practical implication: require logs that preserve identity lineage from user or workload through token use to downstream action.

NHI Mgmt Group analysis

API + AI programmes are now identity programmes in disguise. Once AI systems execute real tasks through connected APIs, the main governance problem is not model quality but who or what is authorised to act. That makes token scope, service-account ownership, and revocation discipline core controls, not back-office details. Practitioners should treat AI connectivity as an identity boundary, because that is where misuse will concentrate.

Zero trust becomes operationally meaningful only when it reaches the AI execution path. Many organisations apply zero-trust language to network access while leaving orchestration layers, service accounts, and automation identities broadly trusted. That mismatch creates an assumption gap: the system is verified at the edge but not at the point of action. The result is a governance model that looks modern while leaving the highest-risk identities under-controlled.

Observability is the control that makes AI governance auditable. A platform cannot govern what it cannot attribute, and AI systems amplify that problem because the same request may pass through multiple identities before it produces an outcome. Naming identity lineage is therefore as important as recording the event itself. Practitioners should view telemetry, access, and execution logs as a single governance layer, not separate functions.

Platform engineering is becoming the practical home of NHI governance. The summit topics reflect a reality security teams already feel: workload identities, API keys, orchestration tokens, and deployment automation now determine how AI behaves in production. That shifts NHI governance from a niche inventory exercise into a cross-functional platform discipline. Teams that leave it fragmented will keep discovering access risk only after the system is already running.

API + AI security will be decided by runtime controls, not architecture diagrams. The session themes point to a market that is moving from design-time principles to execution-time enforcement. That is where least privilege, zero standing access, and verification become measurable. Practitioners should expect architecture reviews to matter less than whether the system can prove who acted, with what authority, and under which boundary conditions.

From our research:

• Organizations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases.
• That fragmentation and AI exposure pattern is why Ultimate Guide to NHIs – The NHI Market remains relevant for teams mapping where machine and agent identities actually live.

What this signals

API and AI convergence turns secrets sprawl into a governance problem, not just an operational one. When credentials are scattered across multiple managers and automation paths, the identity model becomes harder to audit and easier to bypass. Teams should expect access reviews to become less useful unless they can also trace how each secret is used inside production workflows.

The practical signal for readers is that platform engineering, security architecture, and identity governance now need a shared control model. If AI systems can invoke APIs, then token ownership, revocation, and logging belong in the same operating discussion as uptime and release management. The NIST Cybersecurity Framework 2.0 is a useful reference point for that convergence: NIST Cybersecurity Framework 2.0.

For practitioners

• Inventory AI-connected identities Catalogue every service account, API key, token, and certificate used by AI workflows, then assign an owner and a revocation path for each one.
• Bind runtime actions to identity lineage Make logging preserve the chain from initiating user or workload to token use, API call, and downstream side effect so investigations can trace authority end to end.
• Apply zero trust to orchestration layers Do not stop at the network edge. Verify the requesting identity, the workload context, and the action boundary wherever AI orchestration can trigger external systems.
• Review standing access for automation paths Replace broad, persistent permissions with task-scoped access where possible, especially in pipelines that let AI or automation call production APIs.
• Separate reliability fixes from access expansion When teams ask for broader permissions to keep AI services running, treat that as an access-control decision, not only an operational one.

Key takeaways

• API + AI summit themes reflect a simple reality: once AI systems execute through connected services, identity governance becomes part of application architecture.
• Secrets fragmentation and weak runtime attribution make AI-connected environments difficult to govern, investigate, and contain.
• Practitioners should align platform engineering, observability, and least-privilege controls before AI production usage expands further.

Key terms

• AI-connected identity: An AI-connected identity is any non-human credential used by a system that supports or executes AI workflows. This includes service accounts, API keys, tokens, and certificates that let the workflow retrieve data, call tools, or trigger downstream actions. Governance depends on ownership, scope, and revocation.
• Identity lineage: Identity lineage is the trace from the actor that initiates an action to the credential used and the system outcome that follows. In AI and API environments, lineage is what makes attribution and investigation possible when one request passes through multiple services. Without it, access control and telemetry stay disconnected.
• Runtime authorization: Runtime authorization is the decision to allow or deny an action at the moment the system tries to execute it. For AI systems, this matters because the relevant risk is often not login, but whether the workload may call a tool, access data, or trigger a business action right now.
• Secrets fragmentation: Secrets fragmentation occurs when credentials are spread across multiple tools, teams, or environments without consistent lifecycle control. The problem is not just storage sprawl. Fragmentation weakens ownership, delays rotation, and makes it harder to prove which secret is active in which workflow at any given moment.

Deepen your knowledge

API identity governance and AI-connected workload security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are mapping access control across orchestration, APIs, and automation, it is a strong fit for your programme.

This post draws on content published by Kong: API + AI Summit 2026 call for proposals and event details. Read the original.