API design has historically assumed a human behind a browser or mobile app. That assumption is breaking down as AI agents increasingly call tools autonomously, chaining multiple APIs together to complete a task. Apollo's August 2026 webinar on "GraphQL API Security in the Agentic AI Era" is one signal that this shift is now a mainstream concern, not a niche one.
This post compares gRPC and GraphQL specifically through the lens of agent-driven traffic, and covers an authorization gap that's easy to miss.
Agents call APIs differently than humans do
A human client issues requests shaped by UI constraints. An AI agent issues requests shaped by whatever the LLM generated as a tool call, which changes the risk profile:
- Bursts of calls happen in short windows, as a side effect of task decomposition
- Call parameters are less predictable than human input — and can be influenced by prompt injection
- The API schema itself is handed to the LLM as a tool definition, so schema clarity directly affects execution correctness
Given that, API-layer decisions stop being purely a performance question and become a security question too.
Where gRPC fits
For service-to-service traffic — especially tools an agent calls internally — gRPC's strict schema definition is a good fit.
// tool.proto
syntax = "proto3";
service InventoryTool {
rpc CheckStock (StockRequest) returns (StockResponse);
}
message StockRequest {
string sku = 1;
int32 warehouse_id = 2;
}
message StockResponse {
int32 available_units = 1;
bool backorder_allowed = 2;
}A Protocol Buffers contract structurally reduces the chance of an LLM generating malformed arguments. gRPC's fixed request/response shape also limits how much an agent can over-fetch by asking for unexpected fields. gRPC-js adoption reflects this trend too — weekly npm downloads hit 4.1M in early 2026, tracking steady growth in microservice-to-microservice usage.
Where GraphQL fits — and what to watch for
For edge-facing APIs used by both humans and agents, GraphQL's flexibility is still valuable. But when an agent is the caller, field-level authorization needs to be enforced more strictly than it typically is today.
// Enforce authorization at the field level, not just the query level
const resolvers = {
Customer: {
ssn: (parent, _args, context) => {
if (!context.caller.hasScope("pii:read")) {
throw new Error("insufficient scope for field: ssn");
}
return parent.ssn;
},
},
};An agent may request any field it judges "potentially useful" for completing its task, so a design that trusts the whole schema by default is the wrong posture. Every field needs its own scope check. GraphQL's flexibility is an advantage for human clients, but for an agentic caller, that same flexibility widens the attack surface — worth keeping in mind explicitly rather than assuming existing auth patterns carry over unchanged.
A practical rule of thumb
- Internal service-to-service or agent-to-tool calls: gRPC — prioritize strict typing and predictable call shapes
- Edge APIs touched by both humans and agents: GraphQL, with field-level authorization as a hard requirement, not an afterthought
- Simple CRUD with limited agent call patterns: plain REST is still often the right answer
Don't pick a technology because it's newer — pick it based on whether the caller being an agent changes your security requirements.
Takeaways
- Agent traffic differs from human traffic in ways that change API design assumptions
- gRPC's strict typing makes it a strong fit for internal agent-to-tool calls
- GraphQL used for agent-facing edge APIs needs field-level authorization as a baseline, not an add-on
- Technology selection now needs to weigh agent-specific security characteristics, not just performance
As more products embed AI agents directly, treating API design and security design as separate conversations is becoming a real gap in architecture reviews — and one we now flag by default with clients.