TL;DR: AI voice agents can be orchestrated through an API gateway that centralises routing, policy enforcement, observability, and model access across STT, LLM, and TTS workloads, with MCP support and cost control in the path, according to Kong’s reference architecture. The governance question is less about model choice and more about whether identity, traffic, and logging controls are applied consistently to every AI-facing endpoint.
NHIMG editorial — based on content published by Kong: AI Voice Agents with Kong AI Gateway and Cerebras
Questions worth separating out
Q: How should security teams govern AI voice agents that chain multiple model calls?
A: Govern them as a set of machine identities, not as one application.
Q: Why do AI gateways matter for NHI governance?
A: They concentrate routing, authentication, and logging for AI traffic in one control point, which makes it easier to govern model access consistently.
Q: How do teams know whether their AI model access is actually under control?
A: They should be able to trace every model request from application to route to upstream endpoint, with the policy decision and credential context attached.
Practitioner guidance
- Map every AI route to an owning service identity Inventory each STT, LLM, and TTS route, identify the credential or token used upstream, and assign an accountable owner for lifecycle, rotation, and review.
- Enforce upstream secrets handling at the gateway boundary Store and inject API keys or bearer tokens through controlled gateway configuration rather than embedding them in agent code.
- Require per-route logging for AI investigation Capture route name, upstream target, request category, and policy outcome for every model call so security teams can reconstruct the full AI transaction path during incident response or cost review.
What's in the full article
Kong's full blog covers the operational detail this post intentionally leaves for the source:
- The full route and service configuration used to connect STT, LLM, and TTS endpoints through Kong AI Gateway
- The exact ai-proxy-advanced plugin settings for model targets, headers, and payload handling
- The implementation details behind the LiveKit-based voice agent and how its session is wired to gateway routes
- The dashboard and observability examples that show how Kong presents model consumption and traffic patterns
👉 Read Kong's analysis of AI voice agents with Kong AI Gateway and Cerebras →
AI voice agents and gateway controls: are your guardrails keeping up?
Explore further
AI voice agents turn model access into an identity governance problem, not just an application design problem. Once STT, LLM, and TTS services are chained through shared gateway controls, each model call becomes part of the enterprise identity surface. That means access scope, token handling, and policy enforcement need to be governed as infrastructure, not left to application teams alone. The practitioner conclusion is simple: AI voice workloads should be assessed as machine identity estates with real control boundaries.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, which leaves 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: What is the difference between routing control and identity governance in AI systems?
A: Routing control decides where traffic goes, while identity governance decides who or what is allowed to use that path and for how long. A gateway can enforce both, but only if the upstream credentials, reviews, and exceptions are managed as part of the identity lifecycle rather than as incidental configuration.
👉 Read our full editorial: Kong AI Gateway for voice agents: what practitioners need to know