Secure AI agents need protocol-level controls, not model trust

At a glance

What this is: This is an analysis of how Kong frames secure AI agent architecture around MCP, DataKit, and gateway enforcement to keep model-driven workflows governed.

Why it matters: It matters because IAM, PAM, and platform teams need to decide where authentication, authorisation, audit, and rate limits sit when AI agents consume enterprise APIs and data.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Kong's analysis of secure AI agents with MCP Proxy and Volcano SDK

Context

AI agent security is increasingly a governance problem as much as a technical one. Once an LLM is allowed to reach internal data, APIs, or operational workflows, the question shifts from prompt quality to who can invoke tools, what data they can touch, and how every action is logged.

Kong's article frames MCP as a protocol boundary that separates model intent from backend execution. That framing is relevant to NHI, agentic AI, and broader identity programmes because it places authorisation, observability, and rate limiting in the control plane rather than inside the model.

The starting position here is typical of current agent builds: developers want fast orchestration, but security teams inherit the blast radius. The article is useful because it shows why many AI architectures become difficult to govern as soon as they touch real business systems.

Key questions

Q: How should security teams govern AI agents that access internal APIs?

A: Security teams should govern AI agents by placing authentication, authorisation, rate limiting, and logging at the tool boundary rather than trusting the model. The safest pattern is to expose only curated capabilities through a protocol layer, assign each agent a clear owner, and treat every tool invocation as auditable non-human identity activity.

Q: Why do AI agents complicate existing IAM and PAM controls?

A: AI agents complicate IAM and PAM because they can invoke tools dynamically, chain actions quickly, and operate without a human deciding each step. Traditional access models assume a stable user, a stable session, and a predictable request path, but agentic workflows can change the execution path at runtime.

Q: What breaks when an LLM can call raw backend APIs directly?

A: Direct API access removes the sanitised boundary that prevents an agent from seeing schemas, guessing parameters, or reaching services it was never meant to use. That increases the chance of unsafe requests, data exposure, and ungoverned side effects because the model becomes a de facto operator instead of a constrained consumer.

Q: How do teams decide whether an AI gateway is necessary for production agents?

A: Teams should add an AI gateway when the agent can reach sensitive data, operational systems, or shared infrastructure that requires consistent policy enforcement. If the workflow needs logging, authorisation, throttling, or auditability across many tool calls, the gateway is no longer optional plumbing.

Technical breakdown

MCP as a governed execution boundary

Model Context Protocol standardises how an AI system discovers and invokes tools, but the security value comes from treating MCP as a controlled interface rather than a convenience layer. If the model talks directly to raw APIs, the backend schema, parameter space, and business logic are exposed to unconstrained requests. With a governed MCP layer, the model only sees curated capabilities, which makes it possible to enforce policy, audit usage, and constrain tool exposure without relying on the model's judgement.

Practical implication: expose only the minimum MCP tools required for each agent task and place authorisation at the protocol boundary.

Why an AI gateway matters for agent identity and access

An AI gateway becomes the enforcement point for authentication, authorisation, rate limits, and observability across agent traffic. That is important because agentic systems can generate large volumes of calls, chain actions quickly, and move from one tool to another without human review between steps. In identity terms, the gateway is acting like a policy choke point for a non-human actor that needs tightly scoped access and consistent evidence of what was attempted, approved, or blocked.

Practical implication: route agent tool traffic through a gateway that can record every request, apply policy, and stop overuse before backend services are exposed.

DataKit-style orchestration and sanitised data views

A data orchestration layer sits between the agent and business systems to present a sanitised view of data and functions. That matters because an LLM should not infer schema, guess parameters, or improvise against databases and operational services. A curated interface can combine sources, enforce rules, and return only task-appropriate results, which reduces the chance that the agent will see or request data it was never meant to handle.

Practical implication: create task-specific data views for agents instead of exposing production services or databases directly.

NHI Mgmt Group analysis

Protocol boundaries are becoming the new identity boundary for AI agents. When an agent can call tools, query data, and trigger workflows, the control problem shifts from login to execution. That makes MCP governance an identity issue, not just an application design choice, because the real question is which non-human actor is authorised to invoke which capability and under what evidence trail. Practitioners should treat the protocol layer as the first place where agent risk becomes governable.

Model trust is not a security control. Kong's article correctly separates model behaviour from enforcement, because prompt quality cannot replace authentication, authorisation, and auditability. The industry still overestimates how much discipline can be delegated to the model itself, even though the model is the least trustworthy part of the path. Practitioners should assume that anything the model can request must be governed outside the model.

Agentic AI increases the value of a control layer between intent and execution. A secure agent architecture is not just about allowing an LLM to do work faster, it is about constraining the work so the agent cannot infer more, do more, or retain more access than intended. That is why AI gateway design now sits alongside IAM and PAM decisions, not underneath them. Practitioners should re-evaluate where runtime policy enforcement lives in their stack.

Least privilege for agents is only meaningful when tool exposure is explicitly scoped. The article's architecture shows that a model can only be governed if the capabilities it sees are already narrowed to task-specific views. That is a direct reminder that non-human identity governance depends on the shape of the interface as much as on credential issuance. Practitioners should redesign agent access around explicit capability boundaries, not broad backend reach.

MCP tool exposure creates a new identity blast radius concept. Once a tool is exposed through a protocol layer, the blast radius is no longer the whole backend, but it is also no longer just the model. The boundary between authorised capability and latent backend reach becomes the security object to manage. Practitioners should model that blast radius before agents are allowed into production workflows.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, 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.
• For a deeper governance lens, read OWASP Agentic Applications Top 10 for the control failures that commonly shape agent abuse.

What this signals

Agent governance is moving from policy debate to operating requirement. With 92% of organisations saying AI agent governance is critical but only 44% having implemented policies, the gap is no longer conceptual. Teams that do not define protocol-level controls now will end up reviewing agent behaviour after the fact, when the audit trail is already partial.

Capability exposure is becoming a measurable security boundary. The more an agent can see and invoke, the larger the governance problem becomes, especially when only 52% of companies can track and audit what agents access. That blind spot means access review, incident investigation, and compliance evidence all need a new control surface.

Identity programmes should prepare for the control layer pattern in agentic AI. The market is converging on gateways, protocol mediation, and curated tool exposure because those are the places where policy can actually be enforced. Practitioners should align agent architecture with the NIST AI Risk Management Framework and the agent control patterns described in OWASP Agentic AI Top 10.

For practitioners

• Place agent traffic behind a policy enforcement point Route all MCP and tool calls through a gateway that can authenticate the caller, enforce authorisation, apply rate limits, and log each request for later review.
• Expose task-specific capabilities, not raw APIs Create sanitised data and function views for agents so they consume only approved operations instead of discovering backend schemas or calling production services directly.
• Separate orchestration from business logic Keep agent runtime logic, data transformation, and security enforcement in distinct layers so changes in one layer do not silently expand access in another.
• Review agent access like non-human identity access Map each agent to a named owner, a bounded tool set, and an explicit audit trail so lifecycle review, offboarding, and privilege changes are visible.

Key takeaways

• AI agent security fails when teams rely on model behaviour instead of protocol enforcement, because the model is not the control plane.
• Curated tool exposure, gateway policy, and auditability are the controls that turn agentic workflows into something IAM and PAM teams can actually govern.
• The practical shift is from asking what the model can do to defining which non-human identity is allowed to invoke each capability.

Key terms

• MCP Gateway: A control point that sits between an AI agent and backend tools or APIs. It decides which capabilities are exposed, which requests are allowed, and what gets logged, turning tool access into a governed execution path rather than an open integration channel.
• Agentic AI identity: The identity assigned to an AI system that can act through tools on behalf of a business process. It must be governed like a non-human actor with scoped permissions, ownership, auditability, and lifecycle controls, because the model can initiate action rather than only respond to users.
• Sanitised data view: A restricted representation of backend data and functions built for consumption by an AI system. It limits schema exposure, removes unnecessary fields, and reduces the chance that the agent can guess parameters or infer access beyond its approved task.
• Identity blast radius: The range of systems, data, and actions that become reachable when an identity is compromised or overexposed. For AI agents, the blast radius is shaped by protocol exposure and tool permissions, not just by the credentials themselves.

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: Building Secure AI Agents with Kong's MCP Proxy and Volcano SDK. Read the original.