How to run a proof of concept for an MCP gateway

Published 2026-08-18 · NextGen Identity Security desk · 4 min read

An MCP gateway sits between AI agents and the MCP servers they call, so a proof of concept has to test two things: that legitimate work still flows, and that the failures the specification warns about are stopped. This plan is built on the MCP specification's authorization rules and security best practices. It does not assume any particular vendor.

1. Pick three real workflows

Choose work your teams already want agents to do, at three levels of risk: one read-only task, such as searching tickets or documents; one that writes, such as creating an issue or updating a record; and one that is sensitive, such as anything touching money, access or customer data. Name the person accountable for each.

2. Write the policy before installing anything

For each workflow, write down in plain language which agent may call which tool and operation, on whose behalf, and which calls need a person to approve them. The gateways we score express this differently: Docker by server, tool, transport and call; Silverfort as approve or block decisions per tool call; NewCore at the operation level, with routing for human approval. Writing the policy first lets you check whether a product can express it, rather than bending your policy to fit the product.

3. Check where the credential lives

Find out where the downstream credential is during a call. The strongest pattern keeps it away from the agent entirely. Aembit and NewCore state that agents never hold the credential, and Docker reads credentials from your secret store at call time rather than placing them in client configuration. After setup, look in the agent's configuration and environment for any token or key.

4. Turn the specification's rules into tests

The MCP authorization specification and its security best practices page describe specific failures. Turn each into a test:

• Audience: send the gateway a token issued for a different server. It must be rejected.
• Token passthrough: confirm the gateway obtains its own token for each upstream service rather than forwarding the client's token.
• Resource parameter and PKCE: confirm clients name the target server and use PKCE when obtaining tokens.
• Sessions: confirm that a session ID alone does not grant access, and that every request is verified.
• Scopes: request a broad scope and confirm it is narrowed, in line with the specification's advice to start with minimal scopes.
• Local servers: if developers run local MCP servers, confirm the client shows the exact command and asks for approval before running one.

5. Test the approval path

Trigger the sensitive workflow and check who is asked to approve, how the request reaches them and what happens if nobody answers. If the product has no approval step, decide whether a block is an acceptable substitute for that workflow.

6. Read the logs as an auditor would

For each test call, find the record and check that it names the agent, the person, the server, the tool and operation, the policy and the decision. Send the records to your SIEM and confirm they arrive in a usable form. Docker streams one structured event per evaluation; Aembit logs each request with agent identity, user identity, target server and policy decision.

7. Check isolation and deployment

If agents will call third-party MCP servers, ask how those servers are run. Docker's gateway runs each server in its own container and lets you approve servers before agents can reach them; the other gateways we score do not describe server isolation on the pages reviewed. Confirm where the gateway itself runs: Aembit's MCP Identity Gateway runs as a Linux VM in your environment, and Docker's runs in your cloud account or as an air-gapped appliance.

8. Write it up against the same criteria

Score each product on the six criteria of the MCP security page, using what you saw rather than what the vendor's page says. Where your results differ from our scores, trust your results: they come from your environment.