Apollo GraphQL's CEO argues that an MCP server without field-level permissions is a security risk

An MCP server is easy enough to stand up on top of an internal API that many teams have. What that server hands the agent, once the agent asks, is where the trouble starts.

That is the argument Matt DeBergalis, CEO and co-founder of Apollo GraphQL, sets out in a piece The New Stack published on 29 September 2026. His point is that the Model Context Protocol solved the reach problem for agents, so the next problem, deciding what an agent can read and change on a real internal system, is now urgent.

The scenario

DeBergalis frames it with an operations query a team might ask their agent, in his words: "Which orders are going to miss today's shipping cutoff? Check inventory at the other warehouses and create transfer requests where we can cover the shortages."

That call, he writes, needs current orders and available inventory, and it needs to write transfer requests back into the fulfillment system. To make the order-management API available, an engineer builds an MCP server around it. The API, though, returns a wide record: personally identifiable information, financial and fraud details, operational notes that were never meant to leave the trusted network. A tool that passes the whole record along to the agent is a security risk.

Why filtering per tool does not scale

The obvious fix, DeBergalis writes, is to filter the tool's response. But finance needs a different view of orders, support needs some internal notes, another team connects the inventory system, "and now you have to maintain dozens of similar, overlapping tools."

His alternative is what he calls a deterministic, field-level contract: rules attached to each field, so the rule travels with any operation that asks for that field, without any tool having to remember it. MCP still defines how agents discover and call tools. The contract layer defines what those tools may access.

The GraphQL pitch

DeBergalis is running Apollo GraphQL, and the piece is his argument for GraphQL as the layer that expresses those rules. GraphQL was built around callers naming the fields they need, so a rule that says the field customerSSN or internalFraudScore is unreachable applies once and covers every operation that requests it. Writes get the same treatment: a mutation such as requestInventoryTransfer is the business action an agent may take, and the underlying service still checks availability and approvals before accepting it.

None of this, he writes, requires replacing the APIs that run the business. A GraphQL layer can sit over existing services that speak REST, gRPC, SOAP or anything else. The order API still returns the wide record to the integration layer; the agent gets only the fields it is permitted to see. He cites Shopify, Netflix, Airbnb, Expedia Group and Walmart as running exactly this shape at scale over the last decade.

The piece is vendor advocacy from a GraphQL company, and it should be read as such. But the problem it names is real for any team wiring an MCP server to an API that returns more than the agent's job requires: the tool is the point of authorisation, and the moment the agent's task list grows, tool-by-tool filtering turns into a stack of near-duplicates that nobody wants to maintain. A field-level rule that survives that growth is worth designing for, whether the layer that carries it is GraphQL or something else.

Source

• MCP gets AI agents into your APIs. It doesn't decide what they should see, Matt DeBergalis, The New Stack, 29 September 2026