AI infrastructure governance at API Summit: what practitioners need

At a glance

What this is: Kong's AI + API Summit is a production-focused event about how AI infrastructure runs in practice and what that means for architecture and governance.

Why it matters: It matters because AI platforms increasingly sit on top of identity, secret, and access decisions that IAM and NHI teams must govern without assuming human-paced workflows.

By the numbers:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.

👉 Read Kong's AI + API Summit details for production AI infrastructure sessions

Context

AI infrastructure governance is the discipline of controlling how AI systems obtain identity, access, and operational authority in production. The gap is that many teams still treat AI runtime decisions as if they were conventional application workflows, even though AI systems are increasingly touching secrets, APIs, and infrastructure paths that change faster than review cycles can follow.

This summit is framed around production AI systems, which makes the identity question unavoidable. Once AI systems move into real operational environments, teams have to decide how they govern workloads, secrets, and delegated access without letting architecture conversations drift away from identity controls.

Key questions

Q: How should security teams govern AI infrastructure access in production?

A: Security teams should tie every AI runtime action to a named identity, a bounded secret, and a specific approval boundary. The practical test is whether access can be revoked without disrupting unrelated systems. If the same credential or role spans inference, orchestration, and data access, the governance model is too coarse to control real production risk.

Q: Why do AI infrastructure programmes create new identity governance risk?

A: They create risk because machine-speed workflows can combine APIs, secrets, and delegated authority faster than conventional review cycles can observe. That breaks assumptions built around human-paced approval, auditing, and recertification. The result is not just more access, but less clarity about which component exercised that access and whether it was still appropriate.

Q: What breaks when AI systems reuse the same secrets across environments?

A: Reused secrets collapse separation between development and production, making it impossible to prove that privileged access stayed within its intended scope. A compromise in one environment can expose higher-value systems in another. The control failure is not only exposure, but the loss of trustworthy boundaries around where a credential may be used.

Q: What should identity teams ask before approving AI platform expansion?

A: Identity teams should ask which actions are truly necessary, which ones require human approval, and which ones should be limited to workload identity with explicit context. If the answer is vague, the platform is likely accumulating hidden privilege. The right question is not whether AI can do more, but whether the governance model can still explain who is acting.

Background and context

AI infrastructure runtime models and delegated access

Production AI systems do not operate in isolation. They rely on APIs, service identities, tokens, and policy enforcement points to reach models, data, and downstream systems. That creates a runtime chain where access is often inherited rather than explicitly re-evaluated at each step. The technical risk is not just over-permissioning, but the loss of clarity about which component is acting, under what authority, and for how long. When the access path is assembled dynamically, traditional role assignment becomes a poor proxy for actual behaviour.

Practical implication: Map every AI runtime path to a named identity, a bounded secret, and an explicit approval boundary.

Secrets, tokens, and API access in AI pipelines

AI pipelines usually depend on credentials that are reusable, machine-consumable, and easy to embed in orchestration layers. That makes secrets a central control point, because compromise or misuse of a token can expose multiple upstream and downstream systems at once. In practice, the difficult part is not issuing access, but proving that access is still scoped to the task, environment, and duration originally intended. This is where many organisations discover that convenience has outrun governance, especially when development and production reuse the same access patterns.

Practical implication: Separate development and production secrets, and treat any shared credential path as a control exception.

AI system identity and zero trust architecture

Zero trust assumes every request should be re-evaluated rather than trusted because it originated inside the environment. That assumption matters even more in AI infrastructure, where the caller may be a pipeline, a workload, or a runtime component operating at machine speed. Identity must therefore be attached to the action, not just the platform. If the system cannot distinguish an intended model invocation from an unintended tool call, then policy enforcement becomes a generic network control rather than a real identity control.

Practical implication: Bind policy to workload identity and request context, not just to network location or cluster membership.

NHI Mgmt Group analysis

AI infrastructure governance is becoming an identity problem before it is an architecture problem. The event language is about sessions, workshops, and production systems, but the real issue is who or what is allowed to act inside those systems. When AI infrastructure touches secrets, APIs, and runtime automation, IAM and NHI controls become the limiting factor, not the compute layer. Practitioners should treat AI infrastructure as an identity governance surface, not just a platform stack.

Agentic preparation is still materially below the pace of adoption. Only 13% of organisations feel extremely prepared for agentic AI, according to our The 2026 Infrastructure Identity Survey. That gap shows that governance is being asked to catch up after deployment decisions are already underway. The implication is that architecture teams are making access decisions faster than identity teams can classify and control them.

Runtime authority is the named concept teams should track here. In AI infrastructure, the important variable is not whether a system is automated, but whether it can act with production authority through APIs, secrets, and delegated access. That runtime authority determines blast radius, auditability, and revocation complexity. Practitioners should evaluate every AI pathway by the authority it exercises at execution time.

Certification and workshops only help if they translate into access design choices. Training can improve shared understanding, but it does not replace governance decisions around identity scope, secret handling, and approval boundaries. The field is moving toward more operational AI infrastructure, which means security teams need a way to turn architecture discussion into identity policy. Practitioners should use summit learnings to tighten the control model, not just the vocabulary.

Zero trust for AI infrastructure will fail if identity is treated as a side concern. Machine-speed systems require continuous validation of workload identity, request intent, and secret provenance. That makes the governance model cross-domain by necessity, connecting NHI controls, cloud access design, and production policy enforcement. Practitioners should expect identity to become the primary control plane for AI infrastructure governance.

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.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the same survey.
• Read the Top 10 NHI Issues for the control gaps that commonly surface when machine identities outpace governance.

What this signals

Runtime authority will become the deciding control variable for AI infrastructure programmes. The teams that succeed will not be the ones with the most automation, but the ones that can prove which identity exercised which privilege at execution time. That means access design, not platform excitement, should drive implementation sequencing.

With 70% of organisations already granting AI systems more access than they would give a human employee performing the exact same job, per the 2026 Infrastructure Identity Survey, the governance problem is already structural. Practitioners should prepare for sharper questions about privilege scope, revocation speed, and auditability across production AI paths.

For practitioners

• Inventory AI runtime identities List every service account, token, certificate, and workload identity used by AI pipelines, then map each one to the system, environment, and owner that can revoke it.
• Separate production authority from development convenience Block shared credentials between non-production and production AI workflows, and require distinct secrets for inference, orchestration, logging, and data access paths.
• Bind approvals to execution context Require policy checks at the point of API use, not only at deployment time, so that access decisions reflect the current runtime context.
• Use summit planning to formalise governance questions Have architecture, IAM, and platform teams agree which AI actions need human approval, which need workload identity, and which should never inherit broad platform access.

Key takeaways

• AI infrastructure governance now depends on identity controls that can explain and limit runtime authority, not just on architecture diagrams.
• The strongest signal in the market is the gap between rapid AI adoption and weak preparedness for agentic governance.
• Practitioners should leave this topic with clearer rules for secrets, approvals, and workload identity in production AI systems.

Key terms

• Runtime authority: The actual power an AI system, workload, or service identity exercises while it is running. It includes the APIs, data, and downstream actions available at execution time, which can be broader or narrower than the permissions originally granted.
• Workload identity: A machine identity assigned to a service, pipeline, or application so it can authenticate without a human user. In AI infrastructure, workload identity should be tied to a specific runtime purpose and kept separate from broad platform access.
• Secrets sprawl: The uncontrolled spread of credentials such as tokens, keys, and certificates across tools, environments, and teams. In AI systems, secrets sprawl increases the chance that one exposed credential can reach multiple services or cross environment boundaries.
• Delegated access: Access that one component uses on behalf of another component or workflow. For AI infrastructure, delegated access matters because the system performing the action may not be the same system that originally received the permission, which complicates audit and revocation.

Deepen your knowledge

AI infrastructure governance and workload identity are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are formalising controls for production AI systems, it is a practical place to start.

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