CanEnterProject

Federating into a ServiceAccount homed in a GCP project gives the federated principal a foothold in that project.

A principal in project A creates a Batch job in project B whose runtime SA has power in B.

Executing as a service account in a different GCP project = entering that project (GCP-scoped extension of can-control.yaml escalation logic).

A cross-project requester forging a cert a privileged consumer in the CA's project trusts enters that project.

A principal in project A controls code/config of a function in project B whose runtime SA has power in B.

A cross-project principal that can read a bucket containing credentials for a principal privileged in the bucket's project effectively enters that project.

A cross-project principal that can set the bucket IAM policy can grant itself objectViewer, read the bucket contents, and enter the bucket's project data boundary - especially when the bucket contains privileged credentials.

Decrypting another project's key that unlocks a materialized credential privileged in that project enters it.

A cross-project principal reading a secret whose payload is a credential privileged in the secret's project enters that project.

A principal in project A can execute code as a SA that holds privilege in project B by submitting a training job or creating a notebook bound to that cross-project SA.

Federating into a WIF-impersonated ServiceAccount gives the external principal a foothold in the SA's home project.

Control of a parent administrative boundary inherits transitively to every descendant boundary and resource via Contains*.

Materialize a foothold identity inside a subscription/project/tenant/organization when a principal can impersonate/assume/federate into an identity homed there; escalate to Controls only when entry implies admin at a top boundary.