GraphQL as a gatekeeper: controlling what AI agents can access in your APIs

Hooking up an AI agent to an internal API has become straightforward. The genuine difficulty emerges when you need to restrict which data fields the agent can read and which operations it can perform, all without building and maintaining separate implementations for each team.

Consider an operations staffer asking an AI assistant: "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." This kind of agentic workflow demands live API calls. The agent must fetch current orders and real-time inventory levels—last week's snapshot is useless. It also needs write access to submit transfer requests back into the fulfillment system.

An engineer wanting to expose the company's internal order management API to an agent can build an MCP server, which represents the quickest path to making a system accessible. Yet accessibility itself is no longer the bottleneck. The harder question—one that predates MCP—is what the agent should be permitted to see and do once connected. MCP simply makes this question impossible to ignore.

An order management API typically returns far more than agents should access: personally identifiable information, sensitive financial data, fraud indicators, and operational details meant to stay within the trusted network. Traditional applications solve this through backend access control: the system verifies the user's permissions, calls the upstream API, and returns only the appropriate subset of data.

Teams building flexible agents face a dilemma. An MCP tool that passes through everything from upstream systems becomes a security liability. That's one horn of the dilemma. The straightforward solution—filtering the tool's output—creates the other. Finance needs one view of orders, support needs internal notes, another team plugs in the inventory system, and suddenly you're maintaining dozens of overlapping, similar tools.

The solution is a deterministic, field-level contract that specifies precisely what each agent can access and modify, independent of both the upstream APIs and the downstream agents using them. MCP handles how agents discover and invoke tools. A field-level contract defines what those tools are permitted to reach. These are separate concerns, and both are necessary.

GraphQL, a mature and widely adopted technology, provides a practical mechanism for implementing this approach.

GraphQL was built on the principle that API requests should declare exactly which fields they need. An order status query can be minimal:

query {
  order(id: "order-1842") {
    status
    shipBy
  }
}

The response includes only those fields, regardless of what the upstream systems have available. Originally conceived to reduce API payload sizes on mobile connections and eliminate the need for backend-for-frontend layers, this principle now offers engineers a mechanism to enforce permissions for agents.

For instance, if an agent requests a field such as internalFraudScore or customerSSN, a GraphQL server can reject the request or render those fields inaccessible entirely. The permission rule attaches to the field itself and applies uniformly across all operations that reference it. Each tool author doesn't need to remember to strip the same sensitive property from every response.

Write operations follow the same pattern. The operations employee needs authorization to request inventory transfers. A read-only connection would block the work; unrestricted write access could allow the agent to modify stock counts, cancel orders, or process refunds. A mutation—GraphQL's term for write operations—such as requestInventoryTransfer exposes a specific business action. The runtime authorizes it, and the underlying service validates availability and required approvals before accepting it.

None of this demands replacing the existing APIs powering the business. A GraphQL layer can sit in front of services exposing REST, gRPC, SOAP, or any other protocol. The order API continues returning comprehensive records to the integration layer while agents receive only the fields they are authorized to access.

The granularity that enabled developers to build efficient applications quickly becomes even more valuable when the caller is an agent assembling operations dynamically. GraphQL has provided this field-level contract to applications for over a decade, handling billions of daily transactions at Shopify, Netflix, Airbnb, Expedia Group, and Walmart. These organizations and many others have accumulated extensive experience and battle-tested production systems running precisely this model.

MCP opens business systems to agents. A field-level contract ensures the organization retains control over that access. GraphQL represents a proven solution already available.