I have spent this whole series making the case for governance the way we have practiced it for a decade: lint the OpenAPI, enforce a style guide, shift it left, put it in the IDE, and put it where the agent can reach it. Every one of those posts is about the same person — the one building the API. That is producer governance, it is Spectral’s home turf, and it is largely a solved problem that almost nobody adopts. The next decade of governance is a different problem entirely. It happens at integrate-time and run-time, for the people — and increasingly the agents — who consume the API. Those are different moments, with different questions and different tools, and we keep trying to make one set serve both. This is me arguing we should stop.
Start with the honest read on producer governance, because it sets up everything else. The engine works. The rules work. What didn’t land was the promise that everyone would sit down, author governance rules in YAML, and wire them into CI. Most teams just turned Spectral on and stopped — they took the defaults and never wrote a rule of their own, because authoring is work nobody wants. That is not a failure of the tool, it is a failure of the burden we placed on people, and it is the single most important lesson to carry into what comes next. Remember it, because the reason consumer governance actually works is that it asks nobody to author anything.
Producer governance asks “is my API good?” Consumer governance asks a different question: can I safely wire this into my system — and stay within bounds once I have? That question gets asked at two moments producer tooling never even addressed. The first is integrate-time — the moment a consumer binds the capability, reads the manifest, accepts the constraints, provisions credentials, and generates the client. The second is run-time — every call after that, checking whether this actor is within its scope, its rate, and its budget. Naming integrate-time as a first-class governance moment is the whole spine of this argument. It is the seam between “here is an API” and “something is now acting through it,” and nobody has a manifest for that seam. We do, and we have had it for years: APIs.json.
Agents are what turn this from a nice idea into an urgent one. A human developer integrates once, slowly, reads the docs, and remembers. An agent integrates constantly, at machine speed, and reads machine-readable signals or it reads nothing. An agent that learns its rate limit from a 429 has already failed. An agent that guesses at its scopes is a security incident waiting to happen. Consumer governance has to be something an agent can read and reason about before it acts, or it isn’t governance at all — it’s hope. And here is the quiet payoff hiding in that constraint: agents don’t refuse to read declarations the way humans refused to author rules. The adoption problem that sank producer-side governance simply doesn’t exist on the consumer side, because there is nothing to author — only something to read.
That works because the governable payload of an API is mostly declarative. Scopes, quotas, rate tiers, plans, data classes, allowed workflows — these are facts about the API, not policy logic. So they can live in the description, travel in the manifest, and compile straight down to a gateway, with no policy language wedged in the middle. You don’t write governance, you declare it. That cleanly separates three concerns we usually smear together: declaration (what is this capability and what are its constraints — OpenAPI, plans, limits, scopes, data classes, Arazzo), conformance (is that declaration well-formed and on-standard — Spectral, and Spotlight when it’s ready), and enforcement (meter, gate, and authenticate the actual call — a gateway like Tyk). Declaration and conformance are design-time and stay exactly where they are. Enforcement is the new muscle, and it lives at integrate- and run-time.
The unit that carries all of this is what I’ve been calling the capability bundle: an APIs.json manifest that binds the OpenAPI, the conformance rules, the declared constraints, the gateway binding, the FinOps signals, and the provenance into one addressable, governable package. The point is that declaration, constraint, and enforcement travel together, so the thing you hand a consumer is no longer “an API” — it’s a governable capability. Producer governance gets a new and better job here: Spectral (and Spotlight’s validator) becomes the gate that says this bundle is complete and governable before it ever ships. That is producer governance in direct, concrete service of consumer governance, instead of the two living in separate worlds.
But a richer producer manifest is still just a better description of the API — it is not yet consumer governance. The missing half is that governance is a merge. The producer can only ship what it offers: the scopes, the rate tiers, the data classes it’s willing to expose. The consumer — the agent operator — overlays what it permits: which agents, whose budget, what egress rules, what organizational policy. The behavior you actually govern at run-time is the intersection of those two, and the gateway is where that intersection gets enforced. Without the imposed layer, you’ve only described the API more thoroughly. With it, you have real consumer governance: a producer-offered ceiling, met by a consumer-imposed overlay, enforced as the narrower of the two.
Which lands us on the payoff. Because the bundle is machine-readable, a consuming agent reads its own guardrails straight out of the manifest at integrate-time — its scopes, its limits, its allowed workflows, its cost ceiling — and reasons about them before it makes a call. Governance stops being something done to the agent at run-time and becomes something the agent can account for up front. None of that means anything, though, if the manifest is forgeable, so provenance is a requirement and not a nicety: the bundle is signed by the domain that owns the capability — the same posture as domain-verified MCP registry publishing — and the consumer verifies that signature before it trusts a single declared constraint. And to be very clear, none of this rips out Spectral. Spectral still governs the quality of the declaration layer — the well-formedness of the OpenAPI, the Arazzo, the constraints, the rules going into the bundle — and it does it at design-time, exactly where it belongs. The gateway enforces the declared-plus-imposed constraints at run-time. Two jobs, one package, no third policy language. The ask is simple: let’s standardize the capability bundle as the unit of exchange for consumer governance, on APIs.json, in the open — so governance stops being a document that producers write and nobody reads, and becomes a package that consumers, and the agents acting for them, can actually act on.
