The tenant asks. The platform proves. Then the edge changes.

The complete allow rule

Each purge accepts exactly one FQDN. It is allowed if and only if GitHub's real caller repository and that requested hostname are provisioned for the handed PROJECT_ID in platform-owned Front Door route inventory. Nothing about possessing the id—or creating a storage folder—is sufficient on its own.

1. Identity GitHub sets github.repository; the caller cannot replace it with a workflow input. Its repository name is the production FQDN.
2. Lookup The caller supplies PROJECT_ID to select one leaf’s provisioned routes. A wrong UUID leads to denial.
3. Membership The caller repository name must be attached as a custom domain to a route whose origin path is exactly /<PROJECT_ID>/<fqdn>/public.
4. Requested scope The one FQDN sent to Front Door must pass the same route-and-domain test. Production and provisioned environments on one site are peers; a neighbor leaf is not.

Federated identity

The stack application's flexible federated credential checks three independent pieces: the immutable organization owner id, job_workflow_ref pointing at our purge workflow, and sub matching GitHub's immutable repo:org@id/repo@id:… caller form. A tenant may call that file, but a copied or modified version in its own repository cannot mint the token.

The purge client id may be visible because it is only an identifier. The application has no client secret, and the tenant never receives another authentication method.

What this identity can—and cannot—do

It can read platform-owned Front Door routes and custom domains, then purge the shared endpoint. It cannot write or delete blobs, change routes, edit rule sets, touch custom domains, or manage certificates. Storage folders are deliberately excluded from the allow decision because a tenant can write names under its own project prefix.

Paths come from one durable queue

Before public origin changes, the uploader writes and verifies state/to-purge-YYYYMMDD.txt. Its body contains only FQDN-relative Front Door content paths—/, /index.html, /blog/*—never hosts or $web paths. New deploys preserve the original unfinished queue date and union pending work with current durable paths and dropped unhashed paths.

More than 100 paths are compacted from the deepest, smallest overlapping directory groups upward. A directory wildcard does not replace its separate trailing-slash cache key, so /docs/* may travel with /docs/. The compacted request covers every original path; nothing beyond entry 100 waits for another purge. /* is the deterministic last resort, not an ordinary-deploy shortcut.

Manual Purge all

Each tenant has a manual GitHub dispatch where an operator types one of that leaf’s provisioned FQDNs. The platform authorizes the host from route inventory; the tenant then durably queues /*, the platform purges it, and the workflow compares every current durable origin object through that FQDN. The queue clears only after all of that succeeds.

A purge failure or public-verification failure leaves the queue in storage. No lifecycle policy may sweep it, and an unfinished queue older than about 30 days should warn loudly rather than disappear.

Enforced boundaries

Tenant uploaders have blob-only access under their conditioned project prefixes and no Front Door purge or Reader role. The stack identity performs purge through the trusted workflow, whose credential matches GitHub's immutable organization and repository subject fields rather than trusting mutable names.

The automatic deploy path requires a byte-verified pre-mutation queue, exact-route authorization, purge of trailing-slash and explicit-index cache keys, parallel public fetches, staged/fetched SHA-1 matches for current paths, 404 for dropped paths, unchanged-queue comparison, and queue deletion.

Manual Purge all applies the same authorization and durable-state rules to an explicit full-host recovery operation.

Read the narrative in why invalidation became a service, or return to the operations overview.