Notifications
Clear all
Topic starter
24/06/2026 8:07 pm
TL;DR: Secure AI agents need a layered control plane around MCP, data orchestration, and gateway enforcement so models cannot reach raw APIs or bypass policy, according to Kong. The real governance issue is that agent security depends on protocol boundaries, not on trusting the model to behave correctly.
NHIMG editorial — based on content published by Kong: Building Secure AI Agents with Kong's MCP Proxy and Volcano SDK
By the numbers:
- 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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
Kong's full post covers the operational detail this post intentionally leaves for the source:
- Step-by-step architecture for exposing backend systems as MCP servers without direct model access
- Gateway enforcement details for authentication, authorisation, rate limiting, and observability across agent tool calls
- Quickstart workflow for connecting Volcano SDK, DataKit, and MCP Proxy in a working agent stack
- Semantic guardrail examples showing how prompt injection attempts are blocked at the protocol layer
👉 Read Kong's analysis of secure AI agents with MCP Proxy and Volcano SDK →
MCP proxy control for AI agents: what IAM teams should change?
Explore further
25/06/2026 5:18 am
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.
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, 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.
A question worth separating out:
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.
👉 Read our full editorial: Secure AI agents need protocol-level controls, not model trust
