Notifications
Clear all
Topic starter
24/06/2026 8:42 pm
TL;DR: AI systems can standardize tool access through JSON-RPC, OAuth 2.1, and protocol mediation, while also exposing where current gateway and identity controls still need discipline, according to Kong. The underlying issue is not just connectivity but governing who or what can invoke tools safely across agent workflows.
NHIMG editorial — based on content published by Kong: Kong AI/MCP Gateway and Kong MCP Server Technical Breakdown
By the numbers:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams govern AI agents that access tools through MCP?
A: Security teams should govern MCP access the same way they govern other non-human identities, with explicit scopes, strong token validation, and complete audit trails.
Q: When does MCP create more risk than it reduces?
A: MCP creates more risk when it standardises access but fails to narrow privilege, because the same convenience that improves integration can also enlarge the blast radius of a compromised or over-permissioned agent.
Q: What do teams get wrong about gateway-based AI access control?
A: Teams often assume a gateway alone solves the problem.
Practitioner guidance
- Map every MCP tool to an explicit entitlement Create an inventory of tools, resources, and prompts exposed through MCP and assign owners, scopes, and review cadence for each one.
- Enforce token validation at the gateway Require OAuth 2.1 introspection, audience validation, and narrow scope checks before any MCP request reaches a tool server.
- Log identity and method at the translation layer Capture caller identity, tool name, method, parameters, and downstream API target in a single audit trail so protocol conversion does not erase evidence.
What's in the full article
Kong's full technical breakdown covers the operational detail this post intentionally leaves for the source:
- Deck configuration examples for the AI MCP Proxy and AI MCP OAuth2 plugins
- JSON-RPC request and response walkthroughs for MCP tool invocation
- Streamable HTTP client and server examples showing how sessions are established
- Token introspection flow details for Keycloak-backed authorization
👉 Read Kong's technical breakdown of MCP Gateway and MCP server controls →
MCP gateway controls for AI agents: what IAM teams need now?
Explore further
25/06/2026 5:26 am
MCP access control is becoming a non-human identity problem, not just an integration problem. Once an AI application can invoke tools through a gateway, the real governance unit is no longer the application alone but the authenticated, auditable, non-human caller. That changes how IAM, PAM, and API security teams divide ownership. The implication is that MCP traffic needs identity policy, not only transport policy.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, 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: Who should own MCP authorization in an enterprise?
A: MCP authorization usually sits at the intersection of IAM, API security, and platform engineering, but the ownership model should be explicit. Identity teams should own authentication and policy standards, platform teams should own gateway enforcement, and application teams should own the tool inventory and business justification.
👉 Read our full editorial: Kong MCP gateway shows where AI agent access control breaks
