Kong and Noma target runtime security gaps in agentic AI

At a glance

What this is: Kong’s article argues that agentic AI security has to move from static filtering to runtime governance because agents, MCP tools, and LLM flows create new execution-time risk.

Why it matters: IAM, PAM, and NHI teams need to treat agentic AI as a live identity and access problem, because policy decisions now have to follow autonomous actions as they occur.

Context

Agentic AI runtime security is the control problem created when agents can select tools, move across protocols, and act against live data in real time. The article argues that older gateway and WAF models assume payloads can be understood without semantic context, which breaks down once autonomous workflows start chaining model, tool, and data access decisions.

For identity practitioners, the core question is governance at execution time. When AI services, MCP servers, and LLM traffic are managed in separate silos, teams lose visibility into who or what is authorised to act, when those actions happen, and whether policy can still be enforced before the runtime completes the task.

Key questions

Q: How should security teams govern AI agents that can choose tools at runtime?

A: Security teams should govern runtime agent choice as an access event, not as a simple application action. That means scoping permissions to the task, limiting token lifetime, logging every tool decision, and blocking the agent from reaching systems outside its approved context. Static roles alone are not enough when the execution path changes on each run.

Q: Why do existing WAF and API gateway controls fall short for agentic systems?

A: WAFs and API gateways were designed for narrower traffic patterns than modern AI systems produce. They can rate limit and filter known web abuse, but they do not understand agent intent, tool semantics or whether a delegated request is outside scope. That leaves a gap between inspection and true enforcement across AI-driven execution paths.

Q: What are the signs that agentic AI governance is too focused on the agent and not the system?

A: Common signs include strong controls around individual identities but weak oversight of orchestration, action chaining, and inter-agent trust. If teams can describe each agent yet cannot explain how autonomous decisions are approved, audited, and contained across the system, governance is too narrow.

Q: What should teams do in the first 24 to 72 hours after discovering a compromised AI agent runtime?

A: Contain the instance, disable external access, rotate all reachable secrets, and review whether any scheduling, configuration, or file-write paths were abused. Then hunt for adjacent instances using the same plugin chain or access pattern. The first response objective is to stop the agent from continuing to act as an attacker-controlled identity.

How it works in practice

Why semantic context changes agentic AI security

Traditional web and API security controls inspect traffic, but they do not understand the intent carried inside an AI interaction. In agentic systems, the same request may trigger model inference, tool selection, or downstream data access, so the security decision has to account for runtime context, not just syntax. That is why prompt filtering and generic WAF logic are weak fits: they cannot reliably distinguish a benign completion from a tool-abuse sequence or a prompt-injection payload that changes the agent’s behaviour mid-session.

Practical implication: security teams need controls that evaluate AI actions in context, not just payloads at the gateway.

How MCP and agent-to-agent flows expand the identity surface

The article’s architecture shows three distinct paths: A2A communication, MCP tool consumption, and LLM inference flows. Each path creates a different identity control point. A2A needs mediation and protocol normalization, MCP needs tool validation and abuse prevention, and LLM flows need protections against prompt injection and data leakage. The key architectural change is that access is no longer only about authenticating a caller; it is about governing which tools, models, and outputs the agent can reach in sequence.

Practical implication: map each AI traffic path to its own authorization and monitoring control, rather than treating all AI traffic as one policy domain.

Why centralized control planes matter for agentic AI governance

Kong describes a control plane that pushes policy to gateway nodes while a runtime security layer returns decisions back into the flow. That pattern is significant because agentic AI cannot rely on after-the-fact review alone. If an agent can discover tools dynamically, route across models, and execute actions quickly, governance has to be enforced where traffic is orchestrated and where decisions are still reversible. The architecture therefore combines configuration distribution, telemetry, and runtime guardrails into one enforcement loop.

Practical implication: place policy distribution and runtime inspection in the same operating model so autonomous actions can be checked before execution completes.

NHI Mgmt Group analysis

Runtime security has become the new identity boundary for agentic AI. The article is not really about gateways versus WAFs, but about where enforcement must sit when agents can make tool decisions in flight. Once autonomous workflows can move from model to MCP tool to output without a stable human checkpoint, the control point shifts from static access design to live runtime governance. Practitioners should read this as a structural change in where identity security now has to operate.

Prompt filtering is the wrong mental model for agentic AI governance. The article’s core weakness in older tooling is not speed, but semantic blindness. Security controls that inspect packets or headers cannot reliably judge whether a tool call is legitimate, coerced, or chained into unsafe behaviour. That means the category is moving toward context-aware authorization, where the meaning of the interaction matters as much as the transport. Practitioners should stop treating AI traffic as conventional API traffic with new branding.

Shadow AI becomes a governance failure when model connections are created outside centralized control. The article links fragmentation to unauthorized LLM connections and blind spots across AI services. That is a governance problem, not just an ops problem, because the enterprise loses both inventory and enforceable policy once AI paths are spun up ad hoc. The named concept here is runtime governance gap: the distance between an AI action being requested and the organization still being able to decide whether it should proceed. Practitioners should collapse that gap before scale makes it unmanageable.

AI gateway architecture is converging with identity governance logic. The article shows policy distribution, telemetry, and guardrails being applied to agents, MCP servers, and LLMs as one operational system. That convergence matters because it makes AI runtime security look more like privileged access governance than like conventional network security. The practitioner conclusion is simple: if the system can act, route, and choose tools, then identity controls have to follow the action path rather than the application boundary.

Agentic AI security now depends on proving which decisions are allowed before execution starts. The article’s runtime model implies that governance has to happen at the moment of orchestration, not after a log review. That shifts programme design toward continuous authorization, telemetry, and contextual policy enforcement. Practitioners should treat every new agent integration as a governance event, not just an integration task.

From our research library:

• 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.
• Read next: Agentic AI Security Guide

What this signals

Runtime governance gap: agentic AI changes the control problem from static permissioning to decision-time enforcement, because the risk now appears between orchestration and execution. Teams that keep treating AI traffic as ordinary API traffic will miss the point where unauthorized behaviour actually becomes possible.

Enterprises should expect AI gateway and identity governance functions to converge. Once agents can discover tools dynamically and move across MCP and LLM paths, the next control question is not whether the request was authenticated, but whether the action remained authorised at the moment it executed.

For practitioners

• Define runtime authorization points for every agent flow Separate A2A, MCP, and LLM paths so each has explicit policy checks, logging, and owner accountability before any autonomous action is allowed to complete.
• Inventory unauthorized model and tool connections Look for shadow AI by mapping where developers or business teams have created unapproved LLM links, MCP access paths, or agent integrations outside central control.
• Move from payload filtering to context-aware decisioning Use controls that can evaluate the intent, tool choice, and downstream effect of an agent action instead of relying only on prompt or traffic inspection.

Key takeaways

• Agentic AI introduces a governance problem that conventional traffic inspection cannot solve because the risky decision happens at runtime, not at receipt.
• The article links fragmented AI services to shadow AI, unauthorized model connections, and blind spots that weaken enterprise control.
• Practitioners need contextual authorization, unified policy distribution, and runtime telemetry if they want to govern autonomous actions before they complete.

Key terms

• Agentic AI runtime security: Agentic AI runtime security is the protection of an AI agent while it is actively making decisions and using tools. It covers controls for prompts, memory, tool calls, permissions, and output handling, so the agent cannot be hijacked, leak data, or perform unsafe actions during execution.
• Context-Aware Authorization: Context-aware authorization evaluates signals such as device posture, time, resource sensitivity, and request type before allowing access. It moves IAM away from static permission checks and toward decisions that reflect current risk, which is essential in cloud-native environments with frequent identity changes.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Governance Gap: A governance gap is the distance between knowing an asset exists and being able to enforce policy on it. In identity programmes, it appears when discovery, review, and enforcement are split across different tools or teams, leaving access partially visible but not truly controlled.

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.