A service account is the machine identity behind every Google Wallet pass. Where Apple's model revolves around a certificate for one pass type, Google's revolves around a Google Cloud service account: a non-human account with a private key, which a platform uses both to call the Wallet API, creating classes and objects and updating them, and to sign the JSON web tokens inside save links.
The key is the sensitive part. It is a JSON file downloaded once from Google Cloud, and anyone holding it can create passes and sign save links as that account. Platforms keep it in a secrets store, never in a pass or a web page, and rotate it like any other credential.
Access is granted, not inherent. Creating a service account does nothing until the account's email address is added to a Google Wallet issuer account with permission to manage its passes. One issuer account can authorize several service accounts, and one service account can be authorized by several issuers, which is the mechanism that lets a platform issue passes on behalf of a merchant's own issuer account rather than its own.
That is where ownership lives. When the issuer account is the merchant's, the merchant grants the platform's service account access and can revoke it, with every class and pass object staying under the merchant's account. When the issuer account is the platform's, the merchant's passes belong to the platform's account, and taking them elsewhere means reissuing them. It is the Google counterpart to the Apple question of who holds the Pass Type ID certificate, and it should be settled the same way: before the first pass.