They need both, but for different reasons. MCP governs discovery and connection, while GraphQL governs meaning and shape. If the problem is who can find and invoke a tool, review MCP registration. If the problem is what the agent can understand, query, and combine, review the schema and its field-level exposure.
Choosing the Governance Lens for MCP Versus GraphQL
MCP and GraphQL both sit in the path of agentic systems, but they expose different control surfaces. MCP is about which tools and servers can be discovered, registered, and called. GraphQL is about which data shapes, objects, and fields can be queried, combined, and overexposed. Teams usually need to govern both, but they should tune the strictest review to the failure mode that is actually most likely.
The practical test is simple: if the concern is tool entry, broker trust, or which connector an agent can reach, MCP deserves tighter scrutiny. If the concern is data minimisation, field-level exposure, or abusive query construction, GraphQL deserves tighter scrutiny. That distinction helps security, platform, and application owners avoid applying the same review process to two very different surfaces.
What MCP Governance Is Actually Protecting
MCP governance is primarily about discovery, registration, authorization boundaries, and the trust relationship between an agent and a tool source. A weak MCP posture can let an agent find the wrong server, inherit unsafe defaults, or invoke a tool that was never meant to be broadly callable. The most important questions are who may publish a server, how clients are authenticated, and whether the server’s scope is narrow enough for the task.
Because MCP sits close to execution, governance usually focuses on connection approval, token handling, and the safety of tool metadata rather than on the content returned by the tool itself. Teams should treat the registry, broker, or gateway as a control point, not just an inventory. NHIMG’s MCP Security Guide is useful here because it frames the concrete authorization and gateway decisions that sit behind “can the agent call this tool at all?”
For teams operating agentic systems, the broader issue is not just access to one tool, but whether tool invocation can become a confused deputy path or a way to smuggle authority across boundaries. That is why MCP governance often becomes stricter than teams expect once the first production agents start chaining tools.
What GraphQL Governance Is Actually Protecting
GraphQL governance is primarily about query semantics, schema design, and the breadth of data that a client can assemble from one request. The same endpoint can be safe for one consumer and dangerous for another if the schema exposes too much structure, allows expensive or nested traversal, or leaves field-level authorization too loose. In other words, GraphQL risk is often less about “can you reach the API” and more about “what can you infer or combine once you are inside.”
That makes schema review central. Teams should examine object exposure, field sensitivity, query depth, resolver behavior, and whether authorization is enforced at the field or object level rather than only at the endpoint level. Where GraphQL supports highly flexible queries, the governance question becomes whether that flexibility is bounded tightly enough to preserve least privilege for data access. The OWASP API Security Top 10 remains a strong external reference because it captures broken authorization, sensitive business flow exposure, and other API risks that show up quickly in GraphQL implementations.
GraphQL can also become a governance problem when teams assume schema correctness equals access correctness. A well-designed schema may still leak through resolvers, nested associations, or over-broad introspection if the control model is not aligned to the data model. That is why GraphQL reviews usually need closer involvement from application security and API owners than from integration teams alone.
How Teams Decide Which One Needs the Tighter Review
The decision usually comes down to the dominant blast radius. If a failure would let an agent discover unauthorized tools, call a privileged connector, or bypass intended routing, MCP is the stronger governance concern. If a failure would let a client over-query data, combine sensitive fields, or traverse relationships that should remain hidden, GraphQL is the stronger governance concern. Many teams end up with both under governance, but not the same control depth.
When the architecture includes both, assign the strictest review to the layer that can most directly widen impact. Tool discovery and registration controls matter most at the MCP layer, while schema hardening and field-level authorization matter most at the GraphQL layer. If you can only improve one first, start where a single mistake creates the larger privilege or data exposure jump. The Model Context Protocol: Authorization specification is a useful external anchor for the MCP side because it clarifies how authorization is expected to work for MCP servers.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP tool invocation and agent authority directly affect agent privilege boundaries. |
| Recommendation — Constrain agent tool access and privilege boundaries before approving new MCP connections. | ||
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | GraphQL often fails when object access is allowed beyond the caller's rights. |
| API3 — Broken Object Property Level Authorization | GraphQL field exposure can leak sensitive attributes even when the object is allowed. | |
| API5 — Broken Function Level Authorization | MCP and tool-like API actions can expose privileged functions without proper checks. | |
| Recommendation — Enforce object-level checks on every GraphQL resolver and query path. Apply field-level authorization to suppress sensitive GraphQL properties by role or context. Restrict high-risk operations so only approved callers can invoke them. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Both MCP and GraphQL need narrower authority to reduce tool and data exposure. |
| Recommendation — Limit each caller to the minimum tools, objects, and fields required. | ||
Practitioner Guidance
What to prioritise: Review MCP first when tool invocation is the main trust boundary, and review GraphQL first when data shape and field exposure are the main trust boundary. The correct answer is rarely “pick one globally”; it is usually “apply stricter controls where the blast radius is greatest.”
What to verify: For MCP, verify server registration, client authentication, and whether the agent can reach only approved tools. For GraphQL, verify field-level authorization, query depth limits, and whether sensitive objects can be assembled indirectly through nested queries.
Practitioner takeaway: Governance should follow the failure mode, not the protocol name, because MCP usually widens execution reach while GraphQL usually widens data reach.