In a GraphQL schema many teams extend, how do you guarantee every new field is authorized before it ships?

## Why this is a systems question, not a code question Every individual authorization rule in a large graph is easy. The hard property is *closure*: that no field anywhere returns protected data without a decision having been made about it. In a schema of a few thousand fields extended by dozens of teams, closure cannot be maintained by attention. Someone adds a convenience edge, the reviewer is a peer on the same team who shares the same mental model, and the field ships open. Nothing in the process was negligent; the process simply had allow as its default. So the principal-level answer starts by changing which state is the failing one. ## Default deny, enforced at build time The mechanism to argue for: a field on a non-public type that carries no declared rule and no entry in a reviewed exemption list **fails the schema build**. Not a warning, not a dashboard — a red build on the pull request that introduced it. Three properties make this work in practice: 1. **It is local.** The failing check names the field and the team that added it, in the change that added it, when context is still in someone's head. 2. **It is cheap to satisfy.** Adding a rule is one annotation; declaring a field public is one reviewed line. If compliance is expensive, teams route around it. 3. **It has an escape hatch with a name on it.** The exemption file is the audit artefact. "Which fields are public and who decided?" becomes a diff, and the security review has somewhere to focus. Baselining is what makes this adoptable on an existing schema: snapshot today's unannotated fields as accepted debt, block anything new, and burn the baseline down by type. Trying to annotate everything first stalls, and the interesting risk is in the fields being added this quarter anyway. ## Coverage as a published number Because the rule is declared in the schema, coverage is countable: per type, per team, what fraction of fields carry a rule versus an exemption versus nothing. Publishing that per owning team does more than any policy document — it turns an invisible obligation into a number a team can move. It also gives the platform team a way to prioritise: types carrying financial or personal data first, not the schema alphabetically. ## Proving enforcement, not annotation The subtle failure of declarative schemes is decoration. An annotation whose wiring was never registered, or that the server silently ignores on a location it does not support, reads exactly like a protected field. So the test that matters asserts an actual denial: given a viewer without the right, selecting that field returns the denial shape. Generating one such test per declared rule from the schema itself is cheap and catches the entire class. The second test to insist on is the *unexpected path* test. Pick a protected object and assert denial along every edge that returns its type, generated by walking the schema rather than written by hand — because hand-written tests cover the paths the author already thought of, which are exactly the paths that were already protected. ## Rolling out rule changes safely Tightening a rule is a deployment risk, not just a security improvement. A worked example: a platform team narrows the rule on `Leg.driver` in a freight-tracking graph so only the shipper's own account may read it. Reads degrade politely. A tracking subscription, whose payload selects that field, does not — for a whole class of dispatch users the stream simply stopped delivering anything useful, and because a payload that resolves to nothing looks like quiet, nobody filed a bug for two days. The lesson generalises: any long-lived or background consumer turns an authorization change into a silent failure rather than a loud one. So run new and tightened rules in **log-only mode** first: evaluate the rule, allow the request, record what *would* have been denied with the field, the viewer class and the operation name. Read that for a period long enough to include the weekly and monthly jobs, fix the legitimate callers, then enforce. Keep the denial rate per field as a standing metric afterwards, with an alert on a step change — a spike means a rule is wrong or a client broke; a drop to zero on a field that used to deny means enforcement itself stopped. ## Ownership and the tradeoffs to name Split it: the platform team owns the mechanism, the default, the build check, the exemption process and the metrics; the product team owns the policy for its own fields, because only it knows whether a field is sensitive. Centralising the *policy* in a small team makes that team the bottleneck and, worse, makes them accountable for decisions they cannot evaluate. The tradeoffs worth conceding out loud: default-deny slows down teams shipping genuinely public fields, and generates friction that has to be kept small or it will be routed around. A declarative scheme cannot express instance-level policy, so it guarantees a *decision was made*, not that the decision was right. And no build check helps a field whose value comes from somewhere the enforcement layer does not sit on. The claim to make is narrow and honest: this converts an unbounded per-field human obligation into a bounded one, and makes what remains visible.