Security teams and platform engineers share a common assumption: once a gateway authenticates a request, access is handled. It isn't. For anyone building or securing agent infrastructure, this gap is likely already present, just unnamed.
The question a gateway can't answer
A gateway like Kong answers one question well: “Is this request authenticated and allowed through?”
AI agents raise a harder one: “Should this specific agent access this specific data, for this specific intent, right now?”
That second question matters because an autonomous agent can call a dozen MCP servers and tools in a single task, each carrying its own mix of user identity, agent identity, and intent. Authentication tells you who's knocking. It doesn't tell you what they can touch once inside. Without a layer that evaluates these factors, authentication alone cannot enforce those access boundaries.
An authorization layer, not a bigger gateway
Closing the gap means adding a Policy Enforcement Point (PEP) directly into the request path: inline, ahead of the MCP server or backend, asking a different question than the gateway does.
TrustLogix built this as a plugin, tlx_pep, that runs inside Kong's own data plane. It enforces access decisions before a request ever reaches an upstream service. No new gateway. No re-architecture.
Before a request reaches an MCP server or data source, the checkpoint evaluates:
- Who the agent is acting on behalf of
- Which agent is making the call
- What it's trying to do
- Which tool and resource it's requesting
- How that resource is classified
- What the underlying user is actually entitled to
- The policy conditions the organization has defined
That's the difference between controlling AI traffic and controlling what AI is allowed to do with data.
Four moving parts
- PAP: Where policies and entitlements are authored and versioned, outside the runtime path
- PIP: Supplies context: identity, resource, and session attributes
- PDP: Evaluates policy against that context and returns Allow or Deny
- PEP: The plugin in Kong's data plane that enforces the decision inline
Policy changes flow down from the PAP. Every runtime component (PDP, PEP service, plugin) initiates outbound connections only, over mTLS. No inbound access to your network is ever required.
A concrete example
An agent tries to call issue_refund on a finance MCP server. The gateway authenticates it and prepares to route it. Before the request reaches the server, the PEP asks the PDP whether Agent A, acting on behalf of User B, can invoke that specific tool.
Two identities get evaluated, not one:
- Is the agent itself authorized to invoke that tool? A read-only reporting agent might be denied outright.
- Is the user it's acting on behalf of entitled to issue a refund?
Both checks must pass. If either check fails, the request never reaches the server.
This is why two agents acting on behalf of the same user shouldn't necessarily have the same permissions. One might be scoped to read-only status checks. Another might be trusted with refunds. Same user identity, different permissions.
Gateway routing sees only an authenticated destination. This checkpoint sees agent identity, user identity, and the specific tool as separate dimensions of one decision. Authentication got the request through the door. Authorization decides what it can do once inside.
Why this matters now
Gateways already carry a huge share of enterprise API traffic. More and more of it comes from autonomous agents that can chain dozens of calls in the time it takes a person to read one.
Gateway-level controls can't constrain that risk based on the specific agent, data, intent, and current context. That's a separate problem. It deserves a purpose-built layer, not one bolted onto routing after the fact.
Stay in the Know
Subscribe to Our Blog
.png)
.png)