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

At a glance

What this is: This is Kong's analysis of securing AI agents with MCP Proxy, DataKit, and gateway controls, with the core finding that protocol-level enforcement matters more than trusting the model.

Why it matters: IAM, platform, and security teams should treat agent access as a governed interface problem, because control must be enforced at the tool boundary rather than inside the model.

Context

The central governance problem is not whether an AI system can produce the right answer, but whether it can reach internal APIs, business data, and operational workflows without the right control plane. For AI agents, the attack surface shifts from prompt quality to tool invocation, authentication, authorization, and auditability.

Kong's article frames Model Context Protocol as the decoupling layer that separates the model from backend implementation. That matters for AI agent identity because the practical control question becomes how to expose only approved capabilities, not how much the model can be trusted to self-restrain.

The article's architecture uses Volcano SDK for agent execution, DataKit for API orchestration, and Kong MCP Proxy for policy enforcement. The key point is that secure agent design depends on a deliberate boundary between model intent and governed backend access, which is typical of current agentic AI adoption patterns.

Key questions

Q: What breaks when AI agents can call backend tools directly?

A: Direct tool access collapses the boundary between model output and enterprise action. Once an agent can reach raw APIs, schemas, or databases, prompt injection and malformed tool calls become operational risks instead of contained errors. The practical failure is loss of policy enforcement at the point where execution actually happens.

Q: Why does protocol-level enforcement matter for AI agent governance?

A: Because agents can generate requests at runtime, governance must decide whether those requests become actions. Protocol-level enforcement lets teams authenticate the caller, limit tool scope, log every call, and block unsafe requests before they reach backend systems. That is stronger than relying on the model to behave well.

Q: How should security teams scope access for AI coding agents in development workflows?

A: Security teams should treat AI coding agents like any other privileged actor and scope them to the smallest task they need to complete. That means issuing runtime credentials, limiting repository and system access, and tying permissions to a specific workflow step. Teams should also require clear success criteria and session logging so they can verify what the agent did and reduce overreach.

Q: How do teams know whether agent tool controls are working?

A: They are working when every allowed call is attributable, every disallowed call is blocked at the gateway, and the agent cannot reach systems outside its exposed MCP endpoints. If the model can still influence backend behavior outside those paths, the control boundary is incomplete.

Technical breakdown

Why MCP changes the security boundary for AI agents

Model Context Protocol is acting here as the interface between the agent and downstream systems, which means the security problem moves from raw API calls to mediated tool access. Instead of letting a model discover and invoke backend endpoints directly, MCP exposes approved functions through a consistent protocol layer. That gives teams a place to apply authentication, authorization, rate limits, and logging without wiring every application path by hand. The architectural value is not the protocol itself, but the fact that it creates a policy checkpoint before the agent reaches the backend.

Practical implication: govern AI tools as exposed capabilities, not as direct model connectivity.

Why gateway enforcement matters more than model trust

The article's key security claim is that prompt injection or escalated model output should not be able to translate into backend action unless the gateway allows it. This is a classic control-plane pattern: the model can request, but the proxy decides. By placing authorization and observability at the MCP boundary, teams keep policy enforcement outside the model's probabilistic reasoning. That matters because model behaviour is not a reliable enforcement mechanism, especially when the same agent can touch multiple systems with different risk profiles.

Practical implication: enforce policy where the tool call happens, not where the prompt is generated.

How curated API orchestration reduces agent blast radius

DataKit is presented as a curated aggregation layer that exposes task-specific views of backend systems instead of raw database or API access. That design matters because agents do not need unrestricted schema knowledge to perform business tasks, and they should not be able to improvise parameters against internal services. When the agent only sees sanitized, deterministic interfaces, the blast radius of a bad prompt or malformed output is smaller. In governance terms, this is about constraining what the agent can discover, combine, and execute.

Practical implication: publish task-scoped interfaces that hide raw schemas and unsafe backend complexity.

Threat narrative

Attacker objective: The attacker aims to use agent-mediated access to reach internal systems, invoke unsafe actions, or extract data through trusted tool paths.

1. Entry occurs when an AI agent is allowed to invoke backend tools through a loosely governed interface rather than a policy-enforced gateway. This creates the initial exposure point for prompt-driven misuse.
2. Escalation happens when the model is able to request capabilities beyond the intended task, such as broader API access or unsafe commands, because the backend trusts the request path too much. The article treats prompt injection as a realistic trigger for this misuse.
3. Impact follows if the agent reaches internal systems directly, bypasses guardrails, or overuses resources, which can expose data, break workflows, or drive uncontrolled cost and operational risk.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Protocol boundaries, not model intent, now define the control surface for AI agents. The article is describing a shift from prompt-level trust to tool-level governance, which is the right mental model for agentic AI. Once a system can independently call tools, the security question becomes which capabilities are exposed, under what policy, and with what audit trail. Practitioners should treat the protocol boundary as the enforcement point, not the model output.

MCP is becoming the governance layer where AI agent identity is operationalised. The model may generate intent, but the proxy decides whether that intent can become a backend action. That makes authentication, authorization, and observability part of the same control plane rather than separate concerns. In practice, this brings agent access much closer to NHI governance than to traditional chatbot design.

Curated interfaces create identity blast-radius control for agentic systems. By hiding raw schemas and forcing task-specific views, the architecture reduces what an agent can discover and misuse in a single session. That is a named control concept worth carrying forward: identity blast radius is no longer just about privilege size, but about how much backend complexity an agent can touch through one governed path. Teams should design for constrained capability exposure, not general-purpose tool access.

This pattern validates a broader move from application trust to delegated capability trust. Agent governance cannot depend on the model choosing responsibly because the model is not a policy engine. The real control problem is delegated access with bounded authority, observable execution, and explicit conditions for tool use. Security programmes should reframe agent risk as a governed delegation chain, not a conversation problem.

OWASP-AGENTIC and OWASP-NHI both apply here because the article spans tool misuse and non-human access governance. The same agent behaviour that raises agentic security concerns also resembles over-privileged NHI access when the tool boundary is weak. Practitioners should align gateway controls, lifecycle governance, and auditability so agent access is treated as an accountable identity, not an experimental feature.

From our research library:

• 88% of organisations have embedded AI agents in their workflows, according to KPMG's 2026 report.
• Read next: Zero Trust for AI Agents

What this signals

Identity blast radius is the right lens for secure AI agents. The important question is no longer whether the model can answer correctly, but how much enterprise capability it can touch through a single governed path. For practitioners, that means limiting tool scope and backend visibility before agent rollout accelerates beyond governance.

Protocol enforcement should sit closer to the tool boundary than to the application layer. If policy only exists in application code, agents will eventually find paths around it as orchestration grows more complex. Gateway-based control gives IAM and security teams a durable place to apply authorization, observability, and denial logic across agent workloads.

The fact that 88% of organisations have embedded AI agents in their workflows, according to the 2026 Infrastructure Identity Survey, shows that the control problem is already mainstream rather than experimental. That makes agent identity, not model capability, the governance issue practitioners need to operationalise now.

For practitioners

• Define an MCP enforcement boundary Place authentication, authorization, and logging in front of every agent-facing tool so the model never talks directly to raw APIs or databases.
• Expose task-scoped backend views Publish curated interfaces that return only the data and functions required for the specific agent task, and remove direct access to backend schemas.
• Instrument every tool invocation Log each MCP call, request context, and denied action so security teams can audit what the agent attempted and why it was blocked.
• Treat prompt injection as a policy test Validate that a malicious prompt cannot escalate into unsafe tool use, data access, or destructive actions when it reaches the gateway.
• Separate agent intent from backend authority Keep orchestration logic in the agent runtime and keep approval, schema control, and backend entitlement decisions in the gateway layer.

Key takeaways

• AI agents need governed tool boundaries because direct model access to backend systems turns prompts into execution risk.
• The article's architecture reduces exposure by placing policy, logging, and authorization at the MCP proxy rather than inside the model.
• For practitioners, the priority is to constrain what an agent can invoke, observe, and combine through its exposed interface.

Key terms

• MCP proxy: An MCP proxy is a middle layer that sits between an AI agent and MCP servers, forwarding requests, enforcing policy, and often logging activity. In technical terms, it mediates Model Context Protocol traffic, can normalize tool calls and responses, and helps control authentication, authorization, auditing, and data exposure across connected resources.
• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Curated interface: A curated interface is a task-specific view of backend capability that exposes only the functions and data an agent actually needs. It reduces the chance that a model will improvise against internal schemas or overreach into systems it should not see.

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.