Why can a subgraph's _entities field bypass the authorization it enforces on root fields?

## The second front door Every subgraph, by the composition specification, gains two extra fields on its `Query` type: `_service`, which returns the subgraph's own SDL, and `_entities(representations: [_Any!]!): [_Entity]!`, which turns key-shaped stubs into whole objects. `_entities` is how a router resolves any entity that a *different* subgraph referenced. Its argument is a list of representations — small objects carrying the type name and that type's key fields. Now the trap. A subgraph's own root fields are exactly where authorization rules get written, because that is where a request "starts" in the mental model of whoever wrote them. In a charity donations graph, `Query.donation(id:)` in the donations subgraph loads the record and asserts that the caller is either the supporter who gave it or an administrator on the campaign it funded. That assertion runs when someone asks *that subgraph* for a donation. It does not run when the router wants the same object, because the router never calls `Query.donation`. It calls `_entities` — and the reference resolver behind `_entities` is very often a bare lookup by key, written by whoever wired federation up, months after and several files away from the rule it is quietly skipping. ## How the bypass is reached without doing anything exotic The campaigns subgraph owns `Campaign.recentDonations: [Donation]` and returns 24 stubs — key fields only, because it does not own `Donation`. The client's document asks for `amountMinor` and `donorNote` under those donations. The router flattens the list into a single fetch and sends one `_entities` call to the donations subgraph with 24 representations, selecting those two fields inside an inline fragment on `Donation`. The caller asked a perfectly legitimate supergraph question. The donations subgraph answered through a path its own ownership check was never attached to. Nothing was forged, nothing was malformed, and every log line looks ordinary. ## Direct reachability turns a gap into an enumeration If the subgraph can be reached by anything other than the router — another service, a debugging shell, a misconfigured ingress — an attacker does not need the campaigns subgraph at all. They write their own `_entities` document with representations of their choosing and read entities by key. Key fields are ordinary identifiers, frequently sequential, and they are visible to every service that references the type. The composition specification places no authorization on `_entities` whatsoever; it is an ordinary root field on `Query` that happens to be named with a single underscore by convention to keep it out of the client-facing surface. ## Where the check actually belongs The rule of thumb worth saying out loud is **authorize the data, not the door**. Three levels, in increasing robustness: 1. Duplicate the check in the reference resolver. Correct, and it decays — two copies of a rule drift. 2. Push the check into the loader or repository that both paths call, so the entry point stops mattering. 3. Make the data layer caller-scoped, so an unfiltered read is not expressible. Now a new entry point inherits the rule instead of escaping it. Field-level rules deserve the same treatment: if `donorNote` is only for the supporter who wrote it and the campaign's administrators, that rule belongs on the field, and it then holds no matter which parent object carried the caller there. Ownership directives widen the surface further. `@requires` causes a subgraph to be handed sibling fields it does not own, and `@provides` lets another subgraph return fields on your type inline. Any rule that assumed "these fields can only be reached through my root query" is not true in a supergraph. ## Decide the shape of a denial once, for the whole graph A reference resolver that refuses can return `null` in that entity slot, or raise a field error with a path. This is a design choice, not a specified behaviour — but it interacts with the schema: a null landing in a non-null position removes the parent instead of the field. That is precisely why the shape of a denial should be decided once for the whole graph rather than per subgraph. ## Testing the path that has no test Supergraph-level tests almost never exercise the entity path with an unauthorized caller, because from the client's side there is only one graph. Write tests that post an `_entities` document straight at each subgraph, as a caller with no relationship to the data, and assert refusal. In review, the useful question is not "is this field authorized" but "which entry points reach this field" — in a federated graph, the answer is always at least two.