# Google Cloud is making every Application Integration run execute under an explicit identity Google Cloud is changing Application Integration authorization so every run acts either as the triggering user or as an explicitly configured run-as service account. Asynchronous, scheduled and event-driven integrations without a usable identity can stop running unless teams update service-account configuration and impersonation permissions. The migration turns integration identity from an implicit platform detail into an operational dependency. Teams may need new run-as accounts and `Service Account User` grants not only for runtimes but also for editors, publishers, approvers and deployment automation. - Status: Active - Published: 2026-08-31T06:10:27+12:00 - Updated: 2026-08-31T06:10:27+12:00 - Categories: Web Development, Cloud & Infrastructure, Cloud Platforms, Deployment & DevOps, Developer Tools - Tags: Application Integration, Google Cloud, IAM, service accounts - Canonical HTML: https://beyondthe.news/dossiers/google-cloud-application-integration-run-as-service-account-iam-migration ## What changed 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. ## Why it matters 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. ## Synchronous and unattended runs now have different identity models 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. ## Publishing and approving can fail even before runtime 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. ## Authentication profiles can introduce a second service account 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 narrowing identity instead of recreating broad platform access 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. ## The exact enforcement date is still not public 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. ## Key details - Google announced the Application Integration authorization change on August 28, 2026. - Every run will act as either the triggering person or an explicitly configured run-as service account. - Asynchronous runs require a run-as service account because the triggering user's credentials are not retained for the queued execution. - Scheduled and event-driven integrations require a run-as service account because no user's credentials are available. - Running, approving, editing or publishing can require permission to act as the configured service account. - Google identifies `roles/iam.serviceAccountUser` as the standard role used to grant the required `actAs` capability. - Authentication profiles can reference additional service accounts that require separate permission handling. - A run with neither an available user identity nor a configured run-as account will stop. - Google has not published a universal enforcement date in the current preparation guide. ## Builder takeaways - Inventory every Application Integration workflow by trigger type and flag asynchronous, scheduled, Pub/Sub, Salesforce and connector-event paths for a run-as identity review. - Grant Service Account User before republishing integrations with new run-as accounts so the migration change itself is not blocked. - Include CI/CD service accounts, approvers and automation in the permission audit; runtime permissions alone are not enough. - If service accounts live in another project, apply the `actAs` grant in the project that owns that account. - Prefer one narrowly scoped run-as account per integration or trust boundary instead of copying broad permissions from the platform service agent. - Test infrequently scheduled integrations manually because Google warns that a quiet console does not guarantee a workflow is ready for the new authorization model. ## What to watch - Google's final enforcement date and whether rollout timing varies by project or region. - Additional console diagnostics that identify integrations missing run-as identities or impersonation grants. - Whether Terraform or other deployment tooling adds first-class migration checks for the new authorization model. - Operational reports of silent approval stalls and cross-project service-account configuration mistakes. - Whether Google later removes any legacy implicit-identity behavior entirely from the product model. ## Uncertainties - Google says the change takes effect soon but has not published one universal cutoff date. - Warnings can depend on observed execution history, so a lack of console warnings does not prove an integration is unaffected. - Existing integrations differ by trigger type, authentication profile and IAM design, so the required migration steps are not identical for every workflow. - The migration changes authorization semantics, but it does not by itself change the permissions of resources called by an integration; those remain governed by the selected identity's roles. ## Sources - [Prepare for upcoming authorization changes](https://docs.cloud.google.com/application-integration/docs/prepare-for-authorization-changes) — Google Cloud · primary_documentation · 2026-08-29T00:00:00+12:00. Primary migration guide covering explicit identities, run-as requirements, Service Account User grants, asynchronous/scheduled/event-driven behavior and failure modes. - [Google Cloud release notes](https://docs.cloud.google.com/release-notes) — Google Cloud · primary_changelog · 2026-08-28T00:00:00+12:00. Primary release-note announcement for the upcoming Application Integration authorization changes.