A service account is an identity that belongs to a piece of software rather than to a person. It lets an application, a scheduled script or a server authenticate to an application programming interface (API) and act within defined permissions without anyone typing a password or clicking a consent screen. Google Cloud's documentation describes it as "a special kind of account typically used by an application or compute workload." It exists because automation breaks the assumption behind ordinary logins: a nightly job pulling Google Ads spend into a data warehouse cannot wait for a human to approve each request.

In advertising the term most often refers to the Google Cloud implementation, since Google's advertising APIs run through Google Cloud projects.

How a service account works

A Google Cloud service account is identified by an email address, typically in the form name@project-id.iam.gserviceaccount.com. It plays two roles at once. As a principal, it can be granted roles, such as read access to a BigQuery dataset. As a resource, it carries its own policy deciding who may act as it.

Google recognises three types. User-managed service accounts are created by a customer. Default service accounts appear automatically when certain services are switched on. Service agents are run by Google so its own services can act inside a customer's project.

The account has no password. It proves its identity in one of three ways:

  • Attached credentials. The account is attached to a virtual machine, container or serverless function, and the platform hands the code short-lived tokens automatically.
  • Impersonation. A person or another workload that is already authenticated requests short-lived tokens on the account's behalf, provided it holds the right to do so.
  • Keys. A user-managed key, downloaded as a JSON file, holds a private key. The application signs a JSON Web Token (JWT) with it and exchanges that assertion for an access token at Google's OAuth 2.0 authorisation server.

Access tokens obtained this way last 3,600 seconds by default, extendable to 43,200 seconds (12 hours) by organisation policy, according to Google Cloud's quota documentation. Each service account can hold a maximum of 10 keys.

How advertising platforms use them

A Google Cloud service account grants nothing inside an advertising product until it is admitted as a user, exactly as a colleague would be.

In the Google Ads API, an administrator adds the service account's email under Admin, then Access and security, and picks an access level. According to Google's developer documentation, last updated October 30, 2026, service accounts cannot hold the "Email only" level, cannot be granted administrator access by default, and a single email address can be associated with up to 20 Google Ads accounts. Anyone needing more adds the account to a manager account and sets the login-customer-id, the manager's 10-digit customer ID, on each request. The token uses the single adwords scope.

Google Ad Manager requires API access to be turned on for the network, after which an administrator selects "Add a service account user" under Admin, Global settings, Network settings. Display & Video 360 (DV360) offers two routes, and its documentation calls the first "the preferred way": create a DV360 user tied to the service account's email, which then sees whichever partners and advertisers that user has been given. The alternative, domain-wide delegation, lets the account impersonate DV360 users in a Google Workspace domain.

When Google released an open-source Model Context Protocol (MCP) server for the Google Ads API in October 2025, service account impersonation was one of the options for restricting access scope. The Google Analytics MCP server launched in July 2025 authenticates through Application Default Credentials, which accept either user credentials or impersonated service accounts.

Origin and evolution

Google announced service accounts on March 20, 2012, in a post by product manager Justin Smith titled "Service Accounts have arrived." The launch supported Google Cloud Storage, the Prediction API and the URL Shortener, using JWTs signed with a private key. "Certificates offer better security properties than shared keys and passwords," the post argued. On November 6, 2012, Google told developers building for Google Apps, now Workspace, that OAuth 2.0 service accounts were "the recommended authorization mechanism" for domain-wide delegation, replacing two-legged OAuth 1.0.

For years, that delegation requirement kept service accounts awkward for advertisers. A Google Ads integration could use one only by impersonating a Workspace user, which shut out businesses on consumer Gmail accounts. That changed on November 27, 2024, when Anash P. Oommen of the Google Ads API team announced that administrators could grant access to a service account directly. Offline applications no longer needed a refresh token, an OAuth consent screen or OAuth app verification.

Security has driven the other milestones. On April 8, 2021, Google introduced Workload Identity Federation, letting workloads on AWS, Azure or any OpenID Connect provider swap their own tokens for short-lived Google credentials. "The best way to alleviate the challenges around service account keys is not to use them at all," wrote product manager Vignesh Rajamani. Organisations created on or after May 3, 2024 have key creation and key upload blocked by default and no longer hand default service accounts the broad Editor role. Since June 16, 2024, Google has automatically disabled keys it detects in public repositories, using secret-scanning partnerships with GitHub and GitLab, unless an organisation opts out.

Why it matters for marketers

Service accounts sit underneath most marketing automation: warehouse pipelines, bid management tools, dashboards, offline conversion uploads and, increasingly, AI agents. They shape who is accountable for a change and how far a breach can spread.

Authentication rules for people have also moved, and service accounts sit outside them. On April 17, 2026, Anash P. Oommen announced that from April 21, generating a new OAuth 2.0 refresh token for the Google Ads API would require a second factor on top of a username and password. A post of July 27, 2026 went further: from August 5, rolling out over several weeks, the user flow accepts only a passkey, with passwords, authenticator codes and SMS no longer sufficient. Both posts carried the same line: "Service account workflows are not affected by this change, so no action is required." Existing refresh tokens keep working, but each new user-based connection now needs a person holding a passkey. That gives agencies running unattended reporting and bidding a practical reason to move to machine identities.

Google's recent policy changes have pulled the Google Cloud project, and the identities inside it, closer to the centre of advertising API access. On September 10, 2026, Google moved Google Ads API access levels from developer tokens to Google Cloud projects. Its developer policies of August 31, 2026 prohibited programmatic proxies and credentials embedded in "middleware that obfuscate the origin of the automated action," requiring each integration to connect through a dedicated project. When Google piloted faster API reviews tied to brand verification on July 7, 2026, it allowed the token-to-project link to be made through either the user flow or the service account flow.

Limitations and criticisms

The central weakness is the key file. A downloaded JSON key does not expire unless a policy forces it to, works from anywhere and is easily copied into code or chat messages. In a mandatory notice of March 3, 2026, Google warned Cloud customers that service account keys and API keys were at risk, telling them to "never commit keys to source code" and to "never give full permissions to a service account." The notice followed TruffleSecurity's finding that 2,863 live Google API keys in public web data could reach Gemini. Those were API keys, not service account keys.

According to Google's Cloud Threat Horizons report for H1 2026, weak or absent credentials accounted for 47.1% of observed initial access in Google Cloud in the first half of 2025 and 27.2% in the second half, when software exploitation overtook them for the first time.

Over-permissioning is the second criticism. Default service accounts in older projects may still hold the Editor role, and Google's best-practice guidance warns that impersonation chains across projects allow "lateral movement." Accountability is a third: when several tools share one service account, logs show the account, not the person or vendor behind a change.

Google's messaging is also inconsistent. Its Google Ads API guide, updated October 30, 2026, still opens with downloading a JSON key, the practice its security notices discourage, and no longer mentions impersonation.

  • User account with a refresh token. The traditional OAuth route authorises an app on behalf of a named person, who completes a consent screen once. Access disappears if that person leaves, the main operational argument for service accounts. PPC Land's OAuth explainer covers the protocol.
  • API key. A simple string, such as Google keys beginning "AIza," that identifies a project for billing and quota but does not represent an identity with its own permissions in the same way.
  • OAuth client ID. Identifies the application requesting access, not the identity being granted it.
  • Other "service accounts." Microsoft's Windows Server has offered managed service accounts since 2008 R2, and group managed service accounts, which rotate passwords automatically, since 2012. Meta's nearest equivalent is the system user, whose token, according to Meta's Marketing API documentation, "does not expire." In agency vocabulary, a "service account" can also simply mean a client account that an agency services, an unrelated commercial usage.

Recent developments

The newest pressure comes from AI agents. Google Cloud's documentation now describes Agent Identity, a SPIFFE-based identity for each agent that, unlike a service account, cannot be impersonated, is not shared across workloads and cannot carry long-lived keys. Agents are already reaching advertising systems: Amazon opened its Amazon Ads MCP server to open beta on February 2, 2026, and Meta opened its ads MCP server to any app in July 2026. Researchers flagged tool-poisoning risks in MCP implementations in July 2025.

Timeline

  • 2009 - Windows Server 2008 R2 ships with standalone managed service accounts
  • March 20, 2012 - Google announces service accounts for Google APIs, using signed JWTs
  • September 2012 - Windows Server 2012 adds group managed service accounts
  • November 6, 2012 - Google recommends OAuth 2.0 service accounts for domain-wide delegation, replacing two-legged OAuth
  • April 8, 2021 - Google introduces Workload Identity Federation for keyless access
  • May 3, 2024 - New Google Cloud organisations get key creation and upload blocked by default
  • June 16, 2024 - Google begins automatically disabling exposed service account keys by default
  • November 27, 2024 - Google Ads API allows direct service account access without Workspace delegation
  • July 22, 2025 - Google Analytics MCP server released
  • October 7, 2025 - Google releases open-source Google Ads API MCP server
  • February 25, 2026 - TruffleSecurity discloses Google API keys reaching Gemini
  • March 3, 2026 - Google issues mandatory notice on long-lived credentials
  • April 21, 2026 - Google Ads API begins requiring a second factor for new user refresh tokens; service accounts exempt
  • July 7, 2026 - Google Ads API brand verification pilot opens
  • August 31, 2026 - Google Ads developer policies ban programmatic proxies
  • August 5, 2026 - Passkey requirement for new Google Ads API user refresh tokens begins rolling out; service accounts exempt
  • September 10, 2026 - Google Ads API access levels move to Google Cloud projects

Summary

Who: Google Cloud created and operates the dominant model; advertisers, agencies, publishers and software vendors create service accounts and admit them to Google Ads, Ad Manager and DV360.

What: A non-human identity, identified by an email address, that software uses to authenticate to APIs through attached credentials, impersonation or a private key, without a person signing in.

When: Google introduced service accounts on March 20, 2012; Google Ads allowed direct service account access on November 27, 2024; key restrictions tightened from 2024, Google Ads API user logins moved to multi-factor (April 2026) and passkeys (August 2026) with service accounts exempt, and API access moved to Cloud projects on September 10, 2026.

Where: Inside Google Cloud projects, and in the user lists of advertising platforms that accept them, with comparable constructs at Microsoft, Meta and other cloud providers.

Why: Automated reporting, bidding and data pipelines need stable, auditable access that does not depend on one employee's login, though long-lived keys remain a leading source of credential exposure.