MCP connects AI agents to APIs, but GraphQL controls what they see

The Model Context Protocol (MCP) has simplified the process of connecting artificial intelligence agents to internal application programming interfaces, yet it introduces a critical security gap regarding data visibility. As organizations rush to integrate agentic workflows into their operations, engineers face the urgent challenge of defining exactly which data fields these autonomous tools can read or modify. Without strict controls, agents risk exposing sensitive personal or financial information hidden within broad API responses.

What happened

Integrating an AI agent with an internal system, such as an order management platform, is now technically simple using MCP servers. However, this ease of connectivity creates a significant security dilemma because standard APIs often return extensive datasets, including personally identifiable information, fraud details, and operational notes that should remain restricted. An engineer building an MCP tool that simply passes through all upstream data creates a severe vulnerability, effectively granting the agent unrestricted access to the entire database schema.

The alternative approach involves filtering responses within each individual tool, but this method quickly becomes unmanageable at scale. Different teams, such as finance, support, and inventory management, require distinct views of the same data objects. Maintaining separate, overlapping tools for every team leads to code duplication and increased maintenance burdens. This fragmentation makes it difficult to ensure consistent security policies across the organization, leaving gaps where sensitive data might inadvertently leak through less rigorously maintained endpoints.

Key details

• MCP enables rapid connectivity between AI agents and internal systems but does not inherently manage data access permissions.
• Standard APIs often return broad datasets containing sensitive fields like social security numbers or internal fraud scores.
• Filtering data at the tool level requires maintaining dozens of similar tools for different teams, increasing complexity.
• GraphQL provides a deterministic, field-level contract that specifies exactly what data an agent can access.
• Queries in GraphQL request only specific fields, ensuring the response contains no unauthorized data regardless of the upstream payload.
• Write operations, or mutations, can be restricted to specific business actions like requesting inventory transfers rather than allowing general database writes.

Background

GraphQL is a query language for APIs that allows clients to request exactly the data they need, nothing more. Unlike traditional REST APIs that return fixed structures, GraphQL enables developers to define precise schemas where each field has specific access rules. This technology was originally designed to optimize data transfer for mobile applications by reducing payload sizes, but its ability to enforce strict data boundaries makes it ideal for security-conscious architectures. Major companies like Shopify, Netflix, and Walmart have used GraphQL for over a decade to manage complex data interactions securely.

In the context of AI agents, a field-level contract acts as a security layer independent of the underlying transport protocol. Whether the backend services use REST, gRPC, or SOAP, a GraphQL layer can sit on top to mediate access. This setup allows the internal systems to continue functioning with their existing broad data models while ensuring that external agents only receive permitted subsets of information. The runtime environment enforces these rules, blocking requests for restricted fields like internal notes or customer private data before they reach the agent.

Why it matters

For teams running their own software, the adoption of AI agents introduces new vectors for data leakage that traditional perimeter security cannot address. Agents operate autonomously, composing operations at runtime based on user prompts, which means they may attempt to access data fields that human developers did not explicitly anticipate during initial tool creation. Without a deterministic contract, every new agent integration becomes a potential security incident waiting to happen, requiring constant vigilance and manual code reviews to prevent exposure of sensitive operational data.

Implementing a field-level contract reduces the operational overhead of managing multiple agent integrations. Instead of building and maintaining custom filtering logic for every team and use case, engineers can define a single source of truth for data access. This approach ensures that finance, support, and logistics teams all interact with the same underlying systems but receive only the data relevant to their specific roles. It transforms security from a reactive patching process into a proactive architectural feature, aligning with the principle of least privilege.

What you can do

• Audit existing API endpoints to identify sensitive fields that should not be accessible to AI agents.
• Implement a GraphQL layer over your internal services to enforce field-level access controls.
• Define specific mutations for write operations to restrict agents to approved business actions only.
• Avoid passing full upstream API responses directly to MCP tools; always filter or transform data first.
• Use schema directives to mark sensitive fields as unreachable for specific agent roles or contexts.
• Test agent interactions regularly to ensure they cannot bypass field-level restrictions through complex queries.