Prepare an access change for the correct owner. GitHub organization ownership, Cloudflare Access, gateway roles, and tenant membership are separate controls. There is no universal role assignment that grants all four.
-
Describe the actor, resource, required actions, and reason for the change. Identify the scope: organization, repository, hostname, platform role, or tenant. Do not infer application permissions from an email domain or GitHub organization membership.
-
Locate the owner using the table below. Read the current declaration or application contract before choosing a change path.
-
Review the requested permission against the required task. Include the revocation path and any consumers affected by removing access. Keep secret values and private user records out of public documentation.
-
For Terraform-owned controls, follow Administer the platform and review the resulting plan. For application roles, use only an implemented trusted administration path described by the owning app. If that path is missing, propose it explicitly; do not invent an administrative endpoint.
-
Verify both the intended allowed action and a denied action outside the new scope. Record the owner, change, and result without copying credentials.
| Boundary | Canonical owner |
|---|---|
| GitHub organization, repository, and workflow policy | org/github/; governance |
| Cloudflare Access application and policy | org/cloudflare/; affected application's reference |
| Platform route entry | Gateway authorization |
| Identity proof and sessions | Auth trust boundaries |
| Tenant, record, and action permissions | Command center or the receiving service |
A successful sign-in proves identity. It does not verify every authorization boundary. Use the affected app's health evidence as additional validation, not as a replacement for access tests.