MCP connects AI agents to your APIs, but it does not decide what they see

On September 29, 2026, The New Stack published an argument by Matt DeBergalis, co-founder and CEO of Apollo GraphQL, about giving AI agents access to internal APIs through the Model Context Protocol. Reaching a system is easy now; deciding what the agent should see once it gets there is the problem MCP leaves open.

Reach is solved, visibility is not

The scenario: an employee asks their AI assistant which orders will miss today's shipping cutoff, checks inventory at other warehouses, and creates transfer requests where shortages can be covered. That needs current orders, live inventory, and a write path back into the fulfillment system.

Exposing it through an MCP server is the fastest way to make the system reachable. The harder question, DeBergalis writes, predates MCP: what the agent may see once the connection exists.

Why the obvious fixes fail

An order management API can return far more than order status: personal identifiers, financial and fraud details, and operational data never meant to leave the trusted network. Traditional apps check permissions upstream and return only the view that user should have.

Agents break that pattern. A tool that passes through everything its upstream returns is a security risk. Filtering the response instead creates a second problem: finance needs a different view of orders, support needs internal notes, another team connects inventory, and the organization maintains dozens of overlapping tools.

A field-level contract as the enforcement layer

The proposed way out is a deterministic, field-level contract stating what each agent can see and do. MCP governs how agents discover and call tools; the contract governs what those tools may touch. Both layers are needed.

DeBergalis points to GraphQL as the practical implementation. A query for a status and a shipBy field returns just those two fields. If an agent requests a field such as internalFraudScore or customerSSN, the server can reject the request or make the field unreachable. The rule belongs to the field itself.

Writes follow the same model: a read-only connection blocks legitimate work, while unrestricted access lets the agent change stock counts, cancel orders, or issue refunds. A mutation such as requestInventoryTransfer exposes one business action: the runtime authorizes it, while the underlying service checks availability and approvals. None of this requires replacing the APIs that run the business: the layer can sit over REST, gRPC, or SOAP.

What it means in practice

The recommendation is not neutral, since the author leads a GraphQL vendor. The general point holds regardless of tooling: agent access needs an explicit permission boundary between the API and the tool, set per field and per action. Field-level contracts have run in production for over a decade, powering billions of daily transactions at Shopify, Netflix, Airbnb, Expedia Group, and Walmart.