Application Integration Makes Run Identity Explicit

Google Cloud quietly shipped one of the more important backend governance changes of the week: Application Integration runs are moving to explicit execution identity. For teams using Application Integration as an orchestration layer around SaaS connectors, Google Cloud tasks, approval flows, scheduled jobs, or agent-triggered workflows, this changes which integrations keep running and which ones fail when no human credential is available.

The short version is simple: an integration run now needs a real actor. That actor is either the person who triggered the run, or a configured run-as service account. If neither exists, the integration is expected to stop instead of inheriting some vague ambient authority.

That is the right security direction. It is also the kind of change that breaks production automations when nobody owns the identity model.

What Happened

On August 28, 2026, the Google Cloud release notes published an Application Integration announcement titled "Upcoming authorization changes for integration runs." The release note says Application Integration is updating how identities are handled for integration runs. Each run will act as either the user who triggered it or a configured run-as service account, and running an integration will require permission to act as that service account. Integrations that run without a person, including scheduled and event-started integrations, need an explicitly configured run-as service account.

Google also published a dedicated preparation guide, last updated on August 28, 2026. The guide is direct about the operational risk: most integrations should continue working, but some need configuration changes first, and integrations without an available identity will stop.

The affected class is narrower than "all integrations," but it is exactly where production surprises tend to live:

• Asynchronous runs, where a person may trigger the work but the queued execution no longer carries that person's credentials.
• Unattended runs started by schedules or events.
• Integrations with Cloud Scheduler, Cloud Pub/Sub, Salesforce, or Integration Connectors event triggers.
• Integrations scheduled through the API with scheduleIntegrations.
• Asynchronous sub-integrations called by another integration.
• Runs that use Suspend or Approval tasks and can sit paused until a later resume or expiry path.

The preparation guide also calls out a second identity surface: authentication profiles. A run-as service account and a service account referenced by an authentication profile are not automatically the same account. If an authentication profile of type Service account or OIDC token names a service account, callers need permission to act as that account too.

Why It Matters

Integration platforms often become the hidden backend of a company. They start as glue for "just sync this ticket" or "copy this customer record," then grow into invoice workflows, security approval paths, support operations, internal admin actions, and AI-assisted business processes. By the time a platform team notices, a low-code or managed integration layer is sitting on top of sensitive APIs.

That is why execution identity matters.

If an integration calls Cloud Run, reads Secret Manager, appends to Sheets, invokes a connector, updates a SaaS record, or runs a Vertex AI task, the security question is not only "who can click run?" It is "whose authority does this workflow exercise after it starts?" Those are different questions. The person pressing a button may be gone from the call path by the time asynchronous work executes. A scheduler has no human principal at all. An approval task may resume hours later under conditions that do not map cleanly to the original user.

The old failure mode in integration systems is ambient privilege. A workflow can appear to work because a platform service agent, default service account, broad editor grant, or connector credential is carrying it. You cannot reason about blast radius when the identity boundary is implicit.

Google's change pushes Application Integration toward the model most cloud engineers already expect from Compute Engine, Cloud Run, Cloud Build, GKE, and other managed runtimes: a workload should have a declared identity, and a human or automation principal should need iam.serviceAccounts.actAs permission before it can attach or run as that identity.

This also matters for AI engineering. Agentic systems rarely perform every action directly from the model host. A safer design routes irreversible operations through deterministic workflows: create the Jira issue, enrich the customer profile, call an internal API, open the approval, run the data export, notify the owner. Application Integration is a plausible place for those controlled actions. If an agent can trigger an integration that uses a powerful run-as account, then the actAs boundary becomes part of the agent security model.

An AI agent's prompt policy is not enough. The cloud identity behind the workflow is the actual authorization boundary.

How It Works

The new model separates invocation from execution identity.

For synchronous execution, a person starts the integration and waits for the result. In that case, the run can act as that person, and the downstream systems apply that user's access. If the integration only ever runs synchronously, Google says it does not need a run-as service account.

For asynchronous execution, the situation changes. A person may have triggered the run, but queued work does not keep that person's credentials for the whole execution. Google treats asynchronous runs as needing a run-as service account because, by the time the work runs, there is no user credential available to authorize the full run.

For unattended execution, the answer is even clearer. A schedule or event has no human identity. Those integrations need a configured run-as service account.

The operational checklist from Google's guide has three important steps, and the order matters:

1. Grant Service Account User on existing run-as service accounts to everyone who runs, approves, edits, or publishes the integration, including automation service accounts.
2. Set a run-as service account on integrations that run without a person and do not already have one.
3. Grant Service Account User on service accounts named in authentication profiles of type Service account or OIDC token.

The ordering is not bureaucracy. Setting or changing a run-as service account requires publishing the integration, and publishing is itself permission-checked. If you change the run-as account before granting the publisher roles/iam.serviceAccountUser, the publish that would save the fix can be rejected.

The IAM primitive underneath this is familiar. Google Cloud's IAM docs say attaching a service account to a resource requires iam.serviceAccounts.actAs, and the predefined Service Account User role, roles/iam.serviceAccountUser, contains that permission. In Application Integration, that means the principal running, approving, editing, publishing, or automating the integration may need that role on the relevant service account.

The service account's project matters. If the run-as service account lives in a centralized identity project, granting the role in the integration's project is not enough. The binding has to be applied in the project that owns the service account.

Google's guide also gives a practical inventory command using the Application Integration API. It lists active integration versions in a region and prints each version's runAsServiceAccount, defaulting missing values to NONE. The important detail is to keep the API filter at state=ACTIVE. The wildcard endpoint returns one version per integration, and filtering after the fetch can miss active published versions when the latest modified version is an unpublished draft.

If you are running this across many regions, scripts should page through nextPageToken, preserve the active-state filter, and join the result with trigger metadata so you can distinguish harmless synchronous integrations from unattended ones that need a run-as account.

Example

Imagine a support escalation integration used by an internal AI assistant. The assistant reads a support thread, gathers structured context, and triggers an Application Integration workflow. The integration enriches the customer record, checks entitlement data, posts to a private incident channel, and opens an approval before changing account status.

There are three identities in this system:

• The user or agent service that triggers the integration.
• The run-as service account for the integration execution.
• The service accounts referenced by authentication profiles used by specific tasks.

Before this change, the team might only verify that the assistant can invoke the integration. That is no longer enough. The assistant's service account must be allowed to act as the integration run-as account. Human approvers and CI/CD publishers may need the same permission. If a task uses an OIDC-token authentication profile backed by a different service account, that account needs its own actAs grant.

A migration script should not just find missing runAsServiceAccount values. It should answer four questions:

Does this integration ever run without a human for the whole execution?
If yes, what dedicated service account should own the runtime authority?
Who can trigger, approve, edit, or publish this integration?
Which task-level authentication profiles introduce additional service accounts?

The service account design should be boring and specific. Do not create one broad "integration-runner" account for every workflow. Google's Application Integration security guidance recommends separate service accounts and least privilege. Google's IAM best practices make the same point: shared service accounts blur lifecycle ownership, accumulate permissions, and make audit logs harder to interpret.

For this example, the support escalation workflow should get a service account named for the workflow, with only the permissions needed to read entitlement data, post the specific notification, and request the account-status change. The approval step should not magically broaden the run's privileges. It should gate a specific operation already represented in the workflow's identity and audit trail.

The failure modes are worth testing explicitly. A trigger can be rejected with PERMISSION_DENIED before the run is queued, leaving no execution log for the failed run. If a task uses an authentication profile whose service account cannot be acted on, that task can fail while the rest of the run continues. If an approver lacks permission, the approval path can appear to stall until expiry. A single "check execution logs" runbook is not enough.

My Take

This is a good breaking change, assuming Google gives customers enough runway before enforcement. Integration identity should not be implicit. If a workflow can mutate state in production systems, it should be clear whether the authority comes from a user, a service account, or a task-specific credential.

The most interesting part is that Application Integration is being pulled toward the same security discipline as code-first infrastructure. Low-code integration tools often sit outside normal platform engineering review. They may not live in the same Terraform modules. They may be owned by operations teams rather than application teams. They may contain production writes that never pass through the service deployment pipeline.

Explicit run identity gives platform teams a handle. You can inventory integrations, assign owners, apply least privilege, inspect audit logs, and decide which humans and automation systems are allowed to bind workflows to service accounts.

I would treat this as more than a checkbox migration. Use it to clean up the authority model around integrations:

• Give every unattended or asynchronous production integration a named, single-purpose service account.
• Prefer group grants for human operators instead of per-user bindings.
• Grant roles/iam.serviceAccountUser on the service account resource, not broadly at the project level, unless there is a deliberate platform reason.
• Separate run-as identity from connector or task authentication identity in your documentation.
• Add preflight checks to deployment pipelines so publishing fails in CI, not during an emergency console edit.

As teams connect AI assistants to operational workflows, the safest pattern is often to keep the model away from raw credentials and expose constrained workflow entry points. That pattern only works if the workflow's own identity is constrained. Otherwise the agent is pressing a button attached to a privileged backend.

Application Integration's change makes that button easier to reason about.

Conclusion

Google Cloud's August 28, 2026 Application Integration authorization announcement is easy to miss in a long release-notes page. It should not be ignored.

The platform is moving integration runs to explicit identity: user credentials for synchronous human-triggered work, or a configured run-as service account for asynchronous and unattended work. Callers, approvers, editors, publishers, and automation may need roles/iam.serviceAccountUser on the accounts involved. Authentication profiles can introduce separate service account requirements.

For backend teams, this is a migration task. For platform teams, it is a chance to remove ambient privilege from a layer that often escapes normal code review. For AI engineering teams, it is a reminder that agent safety depends less on clever prompt restrictions than on boring cloud identity boundaries.

Inventory the integrations. Name the runtime identities. Scope the service accounts. Test the failure modes before the enforcement date arrives.

Sources

• Google Cloud release notes
• Prepare for upcoming authorization changes
• Application Integration security guidelines
• Manage authentication profiles
• Attach service accounts to resources
• Best practices for using service accounts securely
• Application Integration error codes