[antoinetoussaint-byte]

Refs #1083. Follows #1019. This is the host half. #1083 stays open until the delivery half lands: codefly-dev/cli rendering a solution's declared consumption into its signed authority document (codefly-dev/core#784 and codefly-dev/cli#972, both merged; a solution adopting it needs a core/CLI release).

What reaches the ceiling, and what does not (corrected)

The record this PR reads is the consumer's registry grant. The renderer produces it from a delivered authority document, and the renderer derives that document from module.contract.codefly.yaml and from nothing else.

Layer	Owner	Today	Reaches this ceiling?
Module contract bindings (audience slot + per-operation scope ceiling)	core contracts/module	Read by the renderer (cli pkg/gitops/authority.go, authorityInstancesOf → modulecontract.Load).	Yes, for any module that publishes a contract and a module-identity service.
Authority document	core solutionhost	Signed by delivery; the host derives OperationAudiences from it, the applied presence and the envelope.	It is the record.
A solution's api.consumes (solution.codefly.yaml)	core solution/manifest, cli	Feeds SDK generation (cmd/sync/solution_sdk.go) and CODEFLY__API_CONSUMES (pkg/solutionrun). It names module/service/endpoint and no scopes.	No.
solution-runtime-go Server.Contract	solution-runtime-go	Its own schema at /.well-known/module-contract. The runtime's own source says the renderer does not read it.	No.

So after this PR, no solution in a composition today can receive a confined mint: none publishes a module contract. A solution's confined mint (for example an MCP tool calling documents) is refused, and no setting an administrator controls can admit it. This does not break a path that works on main. #1072 already requires a registry principal to install a solution or be entitled to it, so a confined StartTask through a contract-less solution is already refused at the gateway. What this PR does is make the host ready for the delivery half. It does not close #1083.

The earlier version of this PR claimed the solution's declaration already reached the ceiling and listed the runtime declaration as "no change needed". Both claims were wrong, and both are corrected here and in module/services/auth-gateway/AGENTS.md.

What changes

holdConfinedMintToItsConsumer (accounts, StartTask):

1. Unchanged: the resource must be one this host issues, the credential's own organization is required, and an installation must be stated.
2. The ceiling is the consumer's delivered authority. business.ConsumerInvokeCeiling(org, installation) reads the installation's delivered principal. It then runs the same decision every capability of that consumer goes through (authorizeModuleCapability, sealed to that installation). The result is the envelope ∩ signed authority ∩ installation consent, and its invoke bindings are the ceiling. The audience must be one the consumer declares, and the scopes must fit one binding there.
3. The installation's allowed_audiences / allowed_scopes only narrow. They are applied through the ordinary ceiling: an empty list adds no bound, and a wider list admits nothing extra. Security posture audit 2026-10-04: the 21 findings this repo owns (Closes #1018) #1019's "an empty list refuses a confined mint" is replaced.
4. Each refusal names its cause, so the operator knows who has to act:
   • Not consented (M2). Consent stays fixed at install; that is the safe rule and it is unchanged. A module the consumer declares that this installation does not consent to is refused as not consented by this installation, and the message says that installing again consents to what the consumer declares now. It used to read as "undeclared".
   • Undeclared, or scopes outside what is declared at that audience.
   • The consumer's own audience (m4). Since the merge with main, a self-admitting binding (headless or delegation work) may name its own module and carries invoke scopes. The own-audience refusal runs before any binding is read, so such a binding never admits a confined mint (TestASelfAdmittingBindingNeverAdmitsAConfinedMint). Decided: refused by name, because the credential already reaches that consumer's own routes. Both its prefix and solution:<its binding> count.
   • Capabilities withdrawn (m2) by the installation's consent: named as such, not as "installation not active".
   • No delivered principal (an installation that predates the recording): FailedPrecondition, naming the remedy.
5. Fencing (m3). StartTask opens the authority use span for a confined request before any other transaction, so an uninstall or narrowed consent waits for the mint. The span does not hold the in-memory registry a redelivery replaces. So after signing, and before the capability leaves the process, ConsumerCeilingStillCurrent decides again through authorizeModuleCapability in the same span. It requires the declaration and the consent to be unchanged, and otherwise refuses with Aborted ("ask again"). A withdrawal published after that check lands after issuance, bounded by the capability's lifetime like every other one. A republish that changes nothing about the consumer does not refuse.

M1: an invoke-only binding is no longer dropped. validateOperationAudiences required non-empty lookup scopes, so the reconciler omitted every binding that declares only invoke. Published module contracts in use today declare bindings of exactly that shape: a person-attenuated read against a document store with "nothing to look up", and a separate caller-scoped write binding. I checked one such contract (in the coordinator's review, named there). Those bindings were omitted from that module's registry entry, so its person-attenuated ExchangeDelegatedOperationAudience for them failed too, not just this ceiling. I picked accepting invoke-only, because refusing the delivery would refuse that module's whole authority document, and its declaration is correct. Lookup is now optional, like headless:

• absent means "this binding redeems no lookup";
• present but empty is still a misconfiguration;
• a lookup exchange under an invoke-only binding is refused by name instead of signing a scopeless capability;
• installation consent intersects lookup to nil instead of to an invalid empty list.

WORK_CONTEXTS.md states the rule.

Classification: fix, at the place that owns each behaviour: the confined-mint ceiling and the registry's binding validation are accounts'. No hack, no stopgap. Nothing is added to unrouted_capability_paths.txt: the after-signing re-check goes through authorizeModuleCapability instead of reading the registry directly.

Tests (the reviewer's adopted, renamed, with assertions flipped where the finding is fixed)

• Issue cases. An undeclared audience, and undeclared kinds or actions, are refused whether the installation's lists are empty or wider. Declared requests are issued with empty lists. The lists still narrow.
• Consent, read through real seams. A module declared but not consented gets the "not consented, install again" message. Capabilities withdrawn get their own message. Other covered cases: no delivered principal, a withdrawn installation, an unreadable live authority (Unavailable), and a different installation of the same principal.
• Shape of the declaration. Resource-bound declarations work. Two bindings for one module are not unioned. Consumption derived through the real deriveModulePrincipalGrant is bounded by both the envelope and the document. An invoke-only declaration reaches the ceiling (the reviewer's M1 test, now passing). A consumer cannot declare itself. A table covers every Admit verdict.
• Fencing. One authority span is held through the mint. A redelivery that withdraws the binding mid-mint refuses it (the reviewer's m3 test, now asserting Aborted), and a republish that changes nothing does not. ConsumerCeilingStillCurrent is tested for unchanged, withdrawn, moved binding and principal gone.
• Postgres (pkg/infra/consumer_invoke_ceiling_db_test.go): the declared and consented binding is the ceiling. A module declared after install gets the not consented verdict (the reviewer's M2 test, now asserting the verdict). A row without delivered authority is refused by name.
• Updated. TestAnAudienceWithoutItsLookupIsOmittedByName becomes TestAnInvokeOnlyAudienceIsKept. TestInstalledOperationAudiencePolicy now holds invoke-only as valid and present-but-empty lookup as invalid.
• Mutations fail the suite: deleting the declared ceiling, the list narrowing, the installation seal, the span StartTask opens, or the after-signing re-check.

Docs updated

• module/services/auth-gateway/AGENTS.md: what reaches the ceiling and what does not, each refusal and who acts on it, consent fixed at install, and fencing. m1: it no longer promises operators the "no delivered authority" refusal, because the gateway's entitlement check answers a generic 403 first.
• module/WORK_CONTEXTS.md: lookup scopes are optional.
• The InstallSolutionRequest.allowed_audiences proto comment no longer says a solution's declaration is the ceiling. Regenerated with CI's pinned CLI 0.1.185: both contract descriptors, catalog, module package, generated Go, both TypeScript copies, both swagger documents, and the saas-sdk contract. saas-sdk is now 0.3.27: main took 0.3.26 while this PR was open, and the merge regenerated the contract from both protos.
• The install dialog's description of the field.

Verified, and not

Green:

• accounts go vet ./... untagged, and go test -tags pure ./...;
• accounts pkg/business and pkg/adapters untagged, with Postgres and Vault booted;
• accounts pkg/infra full DB suite (Postgres);
• module/tools (both authority gates);
• frontend solution-installations (58);
• the naming gate (tree and this body) and check-boundaries.sh.

Not verified:

• codefly ci run, the full frontend suite and tsc.
• No booted graph and no MCP client driven end to end.
• No module with invoke-only bindings was exercised running. M1's effect on such a module is inferred from its contract and the derivation code, not observed.

m5 (from review): the fence connection (authorityUse pool, default size) is held for the whole confined mint. No self-deadlock path exists: nothing on that path takes a second authority lock on another connection. But pool pressure under MCP load is new, and nothing measures it yet.

🤖 Generated with Claude Code