How Kong AI Gateway changes controls for single LLM agents

At a glance

What this is: A Kong engineering post showing how a single LLM agent is built with LangGraph and protected with Kong AI Gateway controls.

Why it matters: It matters because agentic applications still inherit classic identity and access risks, so IAM, NHI, and API governance teams need shared controls rather than separate tool-specific policies.

👉 Read Kong's engineering post on building and protecting a single LLM agent

Context

A single LLM agent still relies on ordinary identity primitives such as API keys, scoped tool access, and enforced policy at the gateway layer. The governance problem is not that the agent is magical, but that its runtime behaviour can expand the attack surface faster than access reviews or manual approvals can keep pace.

For IAM and NHI programmes, this sits at the intersection of workload identity, secrets handling, and policy enforcement. Kong’s post is a practical example of why agentic systems should be treated as governed consumers of external functions, not as isolated application logic.

This also makes the naming of the OWASP Agentic AI Top 10 relevant, because agent-tool integration patterns create new ways for access, data, and execution boundaries to fail. The right question is not whether an agent can call tools, but whether the calling path is constrained well enough to survive abuse.

Key questions

Q: How should security teams govern tool calling in AI agents?

A: Security teams should govern tool calling as a privileged access problem, not as a developer convenience. Each callable function should be allowlisted, separately logged, and bounded by policy at the gateway or orchestration layer. The key test is whether the agent can reach a system or dataset that the requesting user could not access directly.

Q: Why do AI agents create new identity governance risks for IAM teams?

A: AI agents create new governance risk because they combine identity, policy, and runtime decision-making in one execution path. That means access is no longer just about who signed in or which key exists. It is also about what the model can decide to call, when it can do it, and how those actions are constrained.

Q: What breaks when agent access is reviewed only at provisioning time?

A: Provisioning-time review misses the real decision point, which is the moment the agent selects a tool or sends a request to an external service. The result is a gap between approved scope and actual behaviour. Teams need runtime enforcement and telemetry, otherwise the review process records an access model that never existed in practice.

Q: What frameworks should organisations use for agentic AI identity controls?

A: Organisations should align agentic AI controls to the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework, then map the runtime access path to existing IAM and NHI governance. That combination helps teams evaluate prompt abuse, tool misuse, and identity scope together instead of as separate problems.

Technical breakdown

LangGraph agent state and control flow

LangGraph models an agent as a graph made of nodes, edges, and state. Nodes perform work, edges decide what runs next, and the state carries context through the graph. In this post, the example is a simple single-node workflow that sends a user message to an LLM and returns the response. That architecture is useful because it makes execution explicit, but it also exposes where credentials, prompts, and outputs can be influenced if the surrounding controls are weak.

Practical implication: treat agent graph boundaries as enforceable trust boundaries, not just code structure.

Tool calling and external function access

The article shows how tool calling lets an agent decide which external function to use based on the model response. That is the point where identity risk rises, because the model is no longer just generating text. It is selecting an action that can affect systems, data, or business logic. Even when the workflow is simple, tool routing creates an execution path that needs allowlisting, validation, and clear separation between user intent and privileged action.

Practical implication: constrain tool permissions to the narrowest callable set and log every external function invocation.

Kong AI Gateway policy enforcement for LLM traffic

Kong positions the gateway as the enforcement point for API key security and token-based rate limiting around LLM calls. That matters because the agent and the model are not the control plane. The gateway is. When AI traffic crosses that boundary, security teams need policy that can inspect, limit, and attribute requests before they reach the upstream model or tools. This is especially relevant in shared environments where multiple agents or applications may consume the same model endpoint.

Practical implication: centralise policy at the gateway layer so model access is measurable, bounded, and revocable.

Threat narrative

Attacker objective: The attacker wants to turn ordinary agent access into unauthorised model usage, tool execution, or downstream data exposure.

1. Entry occurs when an application exposes an LLM agent backed by API credentials and callable tools, creating a usable interface for unauthorised prompting or credential abuse.
2. Escalation follows when the agent is allowed to select external functions, because a model-driven tool choice can widen effective access beyond the original user request.
3. Impact is the misuse of model calls, tools, or secrets to reach data or systems that the agent should not have been able to touch.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Single-agent AI still becomes an identity problem the moment it touches tools. Kong’s example shows that even a simple LangGraph agent is governed through API keys, external function calls, and gateway policy. That means the practical boundary is not the model prompt, but the access path into model and tool execution. Practitioners should treat every agent-tool link as an identity control point, not an application convenience.

Tool calling creates an identity blast radius that is larger than the visible code path. The model chooses which function to call at runtime, so the effective access path is determined after the request begins. That makes static review of the source code insufficient on its own, because the privilege outcome depends on runtime selection. The implication is that access scope for agentic systems must be evaluated as an execution-time property, not only a provisioning-time one.

Least privilege for agents is only real when the gateway can enforce it per request. A gateway that can authenticate, rate-limit, and constrain calls provides a much more reliable governance layer than assumptions embedded in agent code. This is where OWASP Agentic AI Top 10 concerns and NIST AI Risk Management Framework governance both become practical. The practitioner takeaway is to measure whether access is actually bounded where the traffic exits the agent, not where the agent was written.

Named concept: runtime tool authority drift. This article illustrates how an agent can begin with one bounded request and then expand into broader external action through tool selection and chained calls. That drift is not a bug in one library, it is a governance pattern created when runtime authority is inferred from model behaviour rather than explicitly constrained. Practitioners should recognise this as a distinct control problem, not just generic AI risk.

From our research:

• 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, leaving 48% with a complete blind spot for compliance and breach investigation.
• To see how these patterns translate into identity policy, compare them with OWASP Agentic AI Top 10 and the controls teams are mapping to runtime tool use.

What this signals

Runtime tool authority drift: once an agent can choose functions at execution time, conventional access review cadence loses meaning because the control failure is happening inside the session, not after it. Teams should expect agent governance to shift from periodic certification to continuous policy enforcement, telemetry, and revocation logic. The useful question is whether the platform can prove what the agent actually touched.

With 98% of companies planning to deploy more AI agents in the next 12 months, the operating assumption should be that agent sprawl will arrive faster than clean governance. That makes gateway-level policy, secret ownership, and auditability part of the base architecture rather than a later hardening task. Use the access path as the control plane, not the model wrapper.

For practitioner programmes, the next maturity step is to align agent controls with the same identity lifecycle discipline used for other non-human identities. That includes scoped onboarding, explicit offboarding, and evidence-rich monitoring, especially where shared model endpoints and external tools are involved. The governance target is not perfect trust, but measurable containment.

For practitioners

• Inventory every agent-to-tool trust path Map where each agent authenticates, which tools it can call, and which credentials are used at each hop. Make the gateway, not the agent, the point where those paths are approved and revoked.
• Separate model access from tool authority Do not assume that a user allowed to query a model should also be allowed to invoke downstream functions through that model. Bind tool access to explicit scopes and record each invocation for review.
• Apply rate limits to agent traffic, not just humans Use token-aware throttling and policy controls to limit burst behaviour, repeated retries, and runaway loops. Agent workloads can amplify cost and risk faster than traditional API consumers.
• Treat API keys as workload identities Assume every model or function call credential needs lifecycle ownership, rotation, and revocation paths. If a key can reach an LLM endpoint or tool API, it belongs in the same governance process as other non-human identities.

Key takeaways

• Even a single LLM agent becomes an identity governance issue once it can call tools and reach external systems.
• Runtime behaviour matters more than static code review because the model decides which action happens after the request begins.
• Gateway-enforced policy, token limits, and scoped credentials are the practical controls that make agent access measurable and revocable.

Key terms

• LangGraph agent: A LangGraph agent is an application built as a graph of nodes, edges, and shared state. It decides what runs next through explicit workflow logic, which makes execution easier to inspect, but still leaves identity and tool access risks wherever external calls are permitted.
• Tool calling: Tool calling is the pattern where a model selects and invokes an external function during runtime. In agent systems this turns text generation into action execution, so the access decision must be constrained, logged, and governed like any other privileged interaction.
• Runtime authority drift: Runtime authority drift is the gap between the access a system appears to have at design time and the access it effectively exercises during execution. In agentic environments, model-driven tool choice and chained calls can expand authority beyond the original approval boundary.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Kong: How to Build a Single LLM AI Agent with Kong AI Gateway and LangGraph. Read the original.