Google’s Run-As Service Account Check Can Fail Without an Execution Log

Google’s bulletin GCP-2026-068 puts a run-as service account permission check into Application Integration: from October 15, 2026, the service requires iam.serviceAccounts.actAs on the run-as service account, and the test feature and any new integrations need the permission in place. The bulletin states that existing integrations and their new versions are unaffected. The guide and troubleshooting page behind it describe a wider change and where a failed check shows up. The three do not say the same thing.

Two bulletins carry the same CVE, and they should not be merged. GCP-2026-067, published October 14, lists CVE-2026-85298, an Incorrect Authorization vulnerability in AuthConfig validation and the integration execution runtime that could let an authenticated user escalate privileges and impersonate a service account. It says the vulnerability was patched on August 27, 2026 and that no customer action is required. GCP-2026-068, published October 15, lists the same CVE under the vulnerabilities it addresses and carries the requirement. Google lists CVE-2026-85298 in both bulletins, but does not explain the relationship between the August patch and the October authorization requirement. This note does not infer that relationship or claim that the new requirement is the vulnerability’s fix, and it says nothing about how the vulnerability could be exploited.

What the Bulletin and the Guide Each Say

Google’s guide to the authorization changes frames the change as every run needing an explicit identity: either the user who triggered the run, or a run-as service account that you control, scope and audit. The bulletin and the guide describe existing integrations differently, so the table keeps them apart.

Question	Bulletin GCP-2026-068	Guide: Prepare for upcoming authorization changes
Existing integrations	Unaffected, along with their new versions	Two separate facts. The Service Account User check applies to every integration whatever its creation date. The broader explicit-identity behavior for integrations created before October 15 waits for a later date that Google says it announces separately
Tests	The test feature requires the correct permissions after October 15	Every test uses the new behavior from October 15, including console tests and tests of integrations created earlier
New integrations	Require the correct permissions	New behavior from the first version. The run-as requirement is narrower: a new integration with a scheduled or event trigger cannot be published or tested without a run-as service account. The guide does not state that condition for every new integration

This note does not reconcile the two pages. The bulletin says existing integrations are unaffected; the guide says the Service Account User check applies to them and their tests already use the new behavior. Neither page states when the rest reaches them.

One Check, Several Identities

The check is not one permission on one account. Google’s troubleshooting page separates the identities that each need their own grant: the integration’s run-as service account, each authentication profile’s service account, and each sub-integration’s run-as service account. The grant is made in the project that owns the service account, which is not necessarily the project that owns the integration.

The principal needing the grant changes with how the run starts. A person or automation that publishes or tests needs it. An approver needs it, or the run stays paused. For event and scheduled triggers, Google’s troubleshooting page names the trigger’s service account as the principal needing the grant; it documents each trigger type’s failure behavior separately, and this note does not assume one shared authorization path. A sub-integration called asynchronously needs its own run-as service account even if the calling integration has one. Separately, whoever started the calling integration, or the caller’s run-as service account, must be able to act as the sub-integration’s run-as service account.

Two further checks sit beside it. The caller’s own IAM role is verified independently, so fixing one does not fix the other. And making the grant takes roles/iam.serviceAccountAdmin, a separate role from the integration roles.

In delegation terms, the check enforces one rule: a principal cannot hand an integration an identity it is not itself entitled to act as. The Principal and Delegate fields in delegation governance name that relationship. That is as much delegation theory as this note carries.

Staged Enforcement: What Is Enforced and What Is Planned

Whether a given integration meets the check today depends on its creation date, the region’s governance setting and its trigger type, and then on which principal is checked for which operation. The troubleshooting page marks some behavior as enforced and some as planned, and says some checks are still rolling out, so you might not see every error yet.

Condition	Documented behavior	Status
Created on or after October 15, trigger other than API or Private, no run-as service account	Publishing and testing fail with a set-a-run-as-service-account error	Enforced from October 15
Region has “Enable governance” on; a run without user credentials has no run-as service account	Publishing and testing fail, whatever the creation date	Enforced, per the troubleshooting page
Region has governance off; same condition	Not rejected from October 15. Planned to fail in a future release: tasks without an identity (Connectors, Call REST Endpoint, Cloud Run functions) and asynchronous runs without a run-as service account	Planned; date not stated
Created before October 15	Current behavior until a later, separately announced date. The Service Account User check and tests are the stated exceptions	Mixed; remaining date not stated
Service Account User checks generally	Google says some are still rolling out	Partial; which ones is not stated

The planned failures are Google’s description of a future release, not incidents, so the table keeps them in their own row.

Where a Run-As Service Account Denial Shows Up

The headline is scoped to one case: a run started through the API, where the error goes to the caller and nothing appears in the execution logs. Other surfaces report differently, and that variation is the operational problem.

Surface	What Google documents
API-started run	The caller receives the error. Nothing appears in the execution logs
Pub/Sub, Eventarc or Integration Connectors event trigger	One failed execution is recorded. The event is not delivered again
Cloud Scheduler job	The job reports PERMISSION_DENIED
Approver without the grant	Approving or resuming fails. The run stays paused until it expires, so approvals can seem to have stopped working
Publish by automation	The failure surfaces in the deployment pipeline, not in the console. Anything already published keeps running
Task running as the triggering person (JavaScript, Data Transformer Script, Data Mapping)	The run starts normally, then one task fails naming a resource, though nothing about the integration changed

The last row is the one least likely to look like authorization. In a new integration, and in a test of any integration from October 15, those task types run as the person who triggered the run. Google suggests moving the integration onto a run-as service account that already has the access.

If the grant does not fix the error, check four things before changing the integration again: was the grant made in the project that owns the service account; has IAM propagation and authorization caching had time to settle; does an authentication profile or sub-integration introduce another service account; and was the grant assigned to the principal that actually starts the run? Google identifies all four as reasons a correct-looking grant may not resolve the failure.

Google’s Order for the Change, and Two Additions

Google’s guide gives an order for the change, and the order matters. First, find the integrations that need a run-as service account: those that run asynchronously, on a schedule or from an event, and have none. Second, grant Service Account User (making the grant takes roles/iam.serviceAccountAdmin, a separate permission from the grant itself) on each run-as service account and each authentication profile’s service account to everyone who runs, tests, publishes or approves the integration, and to the service accounts that triggers and automation use. Third, set the run-as service account and publish. Google warns that the second step comes before the third, because publishing with a run-as service account requires Service Account User on that account, and the publish can otherwise be rejected.

Two additions are mine, not Google’s. Record, per integration, every identity that needs its own grant. And after the change, exercise each trigger path once and confirm which surface would report a denial, using the table above.

What This Does Not Argue

This note makes no claim about when the check reaches existing integrations, because neither page states a date. It makes no claim about how CVE-2026-85298 could be exploited, and it does not say whether the requirement is, or is not, the fix for it: Google lists the CVE on both bulletins and says no more. It does not say which checks are live in your region beyond what the troubleshooting page states, since Google says some are still rolling out.

Additional Resources