Google Cloud is making every Application Integration run execute under an explicit identity

On August 28, 2026, Google Cloud announced upcoming authorization changes for Application Integration. Every integration run will execute as one of two explicit identities: the person who triggered a synchronous run, or a configured run-as service account. Asynchronous runs, schedules and event-driven integrations do not retain a user's credentials for the full run and therefore need a run-as service account. Google also requires people and automation that run, approve, edit or publish an integration to have permission to act as the relevant service account, typically through `roles/iam.serviceAccountUser`. A run with neither usable identity will stop instead of continuing under the previous implicit behavior.

Integration platforms are often treated as configuration rather than application infrastructure, so identity assumptions can remain invisible until an unattended job fails. Google's change creates a real migration boundary: scheduled, Pub/Sub-triggered, Salesforce-triggered and connector-driven workflows can stop if no run-as account is configured, while deployment or approval workflows can fail if the human or CI principal lacks `iam.serviceAccounts.actAs`. The change also creates an opportunity to improve least privilege because each integration can run under a dedicated, narrowly scoped service account instead of relying on broader platform-level permissions.

A synchronous integration can run as the person who triggers it because that person's credentials remain available for the full operation. An asynchronous run loses that user identity after it is queued, while scheduled and event-triggered runs may never have a user identity at all. Google says those unattended paths require a run-as service account.

Setting or changing the run-as service account requires republishing the integration, and the publisher must already have permission to act as that account. Google warns teams to grant Service Account User before changing the configuration. Approvers can also become a hidden failure point: if they cannot act as the run-as account, approval can remain paused until it expires without a prominent runtime error.

The integration's run-as identity and a service account referenced by an authentication profile can be different accounts. Google says the appropriate principals need Service Account User on both where applicable. Cross-project accounts are especially easy to misconfigure because the grant belongs in the project that owns the service account, not necessarily the integration project.

Google recommends a dedicated, minimally scoped service account per integration. Teams can inspect the permissions currently available through the Application Integration service agent and grant the new account only what the individual workflow needs. That makes the migration more than a compatibility task: it can reduce the blast radius of a compromised integration.

Google says the change takes effect soon and has published preparation guidance, but the current documentation does not give one universal enforcement date. Teams should therefore remediate affected unattended integrations proactively rather than relying on a calendar deadline or a console warning.