TL;DR: Enterprise AI agents need typed, semantically rich API access rather than endpoints alone, and Apollo GraphQL CEO Matt DeBergalis argues GraphQL plus MCP gives agents the transport and meaning layers they need, according to WorkOS. The identity implication is that machine access now depends on governable schema, scope, and delegation rather than simple connectivity.
NHIMG editorial — based on content published by WorkOS: GraphQL meets the agent era, focusing on APIs, MCP, and enterprise AI adoption
Questions worth separating out
Q: How should security teams govern AI agents that access APIs through GraphQL and MCP?
A: Security teams should govern the agent, the transport, and the schema as one access path.
Q: Why do typed API layers change the risk profile for AI agent access?
A: Typed API layers change the risk profile because they reveal object relationships and valid query shapes to the agent at runtime.
Q: What breaks when legacy systems are exposed to agents without schema governance?
A: What breaks is the assumption that connectivity alone is safe enough.
Practitioner guidance
- Inventory agent-facing API surfaces Map every MCP-connected tool and GraphQL endpoint that an AI agent can reach, then document the business objects, fields, and actions exposed through each path.
- Classify GraphQL fields by business effect Assign sensitivity and decision-impact labels to fields, not just to entire APIs, so teams can see which objects reveal customer data, operational data, or privileged relationships when queried by an agent.
- Limit schema breadth for agent workflows Expose only the objects and relationships required for the use case, and split high-risk operations into separate governed tools rather than leaving them inside one broad schema.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- The full HumanX 2026 interview context and direct quotes on how Apollo sees GraphQL in the agent era
- The product bridge between MCP tools and GraphQL queries that the post only summarized at a high level
- The enterprise adoption anecdotes about non-developers building agents inside real organisations
- The procurement and modernization observations that show how AI is changing internal build-versus-buy decisions
👉 Read WorkOS's analysis of GraphQL, MCP, and enterprise AI agents →
GraphQL for AI agents: what changes for API and identity teams?
Explore further
Semantic access control is becoming a governance problem, not just a developer convenience. GraphQL schemas do more than document APIs. They define what an agent can understand, discover, and combine across systems, which means schema design now influences effective privilege. When agents are the caller, the interface itself becomes part of the control surface. Practitioners should treat schema exposure as an identity decision point, not only an application concern.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
A question worth separating out:
Q: How do IAM and platform teams decide whether an agent should use GraphQL at all?
A: They should allow it only when the schema can be reduced to the smallest set of objects and operations needed for the task. If the use case requires broad relational discovery, stronger review and tighter tool segmentation are needed. The decision should be based on how much business meaning the agent can infer, not just on technical feasibility.
👉 Read our full editorial: GraphQL and MCP in the agent era reshape enterprise AI access