Adding Model Context Protocol Permissions to Kong AI Gateway

What a complete MCP permission model involves

Routing agent traffic to MCP servers through Kong AI Gateway gives you a single place to apply policy. It does not, by itself, answer the question teams actually face: which agents, users and services may call which tools, with which inputs, and who approved the risky ones.

NIST SP 800-228 offers a useful frame. It says every service behind an API endpoint should perform two levels of authorization: service authorization and end-user-to-resource authorization. For MCP, the first is whether this agent or service may call this MCP server. The second is whether this user, acting through this agent, may invoke this tool on this target. Many first deployments implement only the first.

Both decisions depend on a prior one. NIST SP 800-162 states that an access request must be authenticated as originating from a unique subject. If agents share a credential, or the user behind the agent is not carried with the request, the second-level decision cannot be made and logs cannot attribute actions to a person or an agent.

Identity, routes and services: where gateway configuration fits

Start with an inventory of the credential types that agents, users and services present to the gateway. NIST SP 800-228 names authentication of both the user and the calling service as one of the most important policies a gateway enforces, and notes that handling many client credential types is a common gateway problem. Decide up front how the agent identity and the end-user identity are each carried and verified, and issue credentials scoped to a specific MCP server rather than reusing one broad credential across servers.

Route and service-level access is the natural fit for gateway configuration. NIST SP 800-233 describes service-to-service authorization as network-based authorization plus identity-based policy, for example "A can call B". Expressing which consumers may reach which MCP server routes is this kind of rule.

NIST SP 800-204B adds a design choice: enforcement can be native, using local configuration structures such as ACLs, or delegated to an external authorization server through a proxy extension. Local configuration is simpler to operate and easier to reason about. An external decision point is better when decisions depend on changing user, resource and permission data. Make this choice per decision type, not once for the whole deployment.

Tool-level authorization, arguments and responses

Route-level rules see the destination of a request. A tool-level rule has to know which tool is being invoked and with what arguments, and those sit inside the request payload. Whether a given gateway configuration can read, evaluate and act on the payload is the question to settle for each decision you need, and anything it cannot express becomes custom logic or a call to an external authorization service.

A practical model borrows from NIST SP 800-228. It recommends annotating endpoints and fields with the permissions they require, and enforcing resource-level authorization as a cross-cutting policy on every request. Applied to MCP, that suggests a tool-to-permission registry: each tool has a named permission, a sensitivity class, and a record of whether it changes state. Enforcement is driven from the registry rather than written separately for each server.

Per-tool allow or deny is only the start. Argument-level restrictions limit what an allowed tool can do, for example constraining a file path prefix, a record scope or an amount threshold. Response handling matters too, because a permitted call can still return data the agent or user should not receive, which calls for redaction before the result reaches the model. NIST SP 800-207A adds that access enforcement should use assigned permissions plus context about each request, so decisions can consider caller, target and request context rather than static roles alone.

For state-changing or sensitive tools, design human approval explicitly. The request must be held, the approver identified, and the outcome tied to the original call. Confirm early that your enforcement point can pause and resume a call, because this is where gateway-only designs most often fall short.

Ownership and evidence requirements

Assign an owner for the permission model. NIST notes that the authorization system must be kept current as users, resources and permissions change, so the registry and the policies that read it need a named team, a change process and a review cadence. Platform engineering typically owns the enforcement mechanism, while security or the tool owner approves the permissions and sensitivity classes.

Define evidence requirements with compliance and audit stakeholders before building, not after. A reviewer's core question is what an agent was permitted to do and what it did. Answering it means capturing, at the moment of enforcement: the authenticated user and agent or service identity, the tool and target, the arguments or a redacted representation of them, the policy version applied, the decision (allow, deny, redact, escalate), the approver where one was required, and the outcome.

Evidence reconstructed later from scattered gateway and server logs is weaker than a decision record written when the decision was made. It is also hard to retain consistently if each MCP server logs differently.

When enforcement in the execution path is needed beyond gateway configuration

Gateway configuration is enough when decisions are coarse: which consumer reaches which server, with rate limits at the route. It becomes insufficient when you need per-tool decisions with context, argument-level limits, response redaction, human approval and a durable decision record, and when a regulated enterprise must show an auditor the result.

Trussed addresses this part of the problem. It enforces policy in the execution path across MCP servers and tool calls: allow, redact, block, rate limit, or escalate for human approval, applied to individual interactions and tool calls. Enforced at runtime, not reviewed after the fact, each decision produces audit-ready evidence, mapped to frameworks including HIPAA, NAIC, NYDFS, the EU AI Act and NIST. It can be deployed self-managed in the customer cloud, with configurable retention and data residency. It has run continuously in production in a regulated enterprise for over 18 months.

This sits alongside the gateway rather than replacing identity, routing or service-level access, which remain gateway responsibilities. Use the registry and ownership model above to decide which decisions stay in configuration and which move to enforcement in the path.