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.
One check, several identities, and a denial that does not always reach the execution log.
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.
Each identity needs its own grant, made in the project that owns the service account.
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.
Enforced, planned and not stated are three different states.
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.
Diagnostic: "If a trigger's service account lost its Service Account User grant tonight, which surface would tell you by morning, and would the event come back?"
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.
Architect's Verdict
A permission check that rolls out by creation date, region setting and trigger type is several changes, each reaching an integration at a different time and failing somewhere different.
The hard part is not granting a permission. It is identifying every principal that needs it, applying the grant in the correct project, and verifying the failure surface for each execution path. Denial lands on whichever surface the trigger uses: an error to an API caller with nothing in the execution log, a failed execution that is never redelivered, a paused run that waits to expire, a publish failure in a pipeline nobody reads.
Additional Resources
- Cloud Strategy — the pillar hub for placement, ownership and control-plane decisions across cloud architecture.
- Enterprise Architecture Has Identity Governance. It Doesn't Have Delegation Governance. — the Principal and Delegate fields of the relationship the run-as check enforces.
- Application Integration security bulletins — GCP-2026-067 and GCP-2026-068, with CVE-2026-85298 and the actAs requirement.
- Prepare for upcoming authorization changes — Google's guide: explicit run identity, rollout stages and the order of the change.
- Troubleshoot authorization errors — where each denial surfaces, and why a grant may not have taken effect.
Originally published at rack2cloud.com
