Authentication issues with GCP secrets engine impersonated account path

So I have a bit of curiosity here as to how authentication works behind the impersonated accounts feature of the GCP secrets engine, and I’m wondering if I can get some clarification here.

What am I doing?
I am looking to use service account impersonation to generate an OAuth2 token that will be used downstream by a service to access GCP Artifact Registry. The config for the provisioned endpoint is like so:

  "name": "artifact-registry",
  "service_account_email": "",
  "ttl": "1800s",
  "token_scopes": [

What are my problems?
My issues arise when trying to manually hit the endpoint via the Vault CLI. In running the command :

VAULT_TOKEN=my_access_token VAULT_SKIP_VERIFY=true 
vault read gcp/impersonated-account/artifact-registry/token

The go library returns the error from GCP:

* unable to generate token source: impersonate: unable to generate access token: 
Post "": Forbidden

What have I tried?
First, I validated the GCP endpoint by sending an HTTP request to the Google IAM API generateAccessToken function. This was using an OAuth2 token tied to my GCP user account, where the role Service Account Token Creator has been enabled. This returned the token I was expecting.

This led me to looking at the source code for the impersonated account implementation and gave me a few questions to ponder over. What account is being used when making the Vault request?

In the file vault-plugin-secrets-gcp/plugin/path_impersonated_account_secrets.go at 187ca51b3db9053da95ab58235a016f3c1558d48 · hashicorp/vault-plugin-secrets-gcp · GitHub , the function utilizes GCP credentials. If these credentials are not supplied, default credentials are used (vault-plugin-secrets-gcp/plugin/backend.go at 187ca51b3db9053da95ab58235a016f3c1558d48 · hashicorp/vault-plugin-secrets-gcp · GitHub).

Looking up what this default would be, it states:

It looks for credentials in the following places, preferring the first location found:

A JSON file whose path is specified by the GOOGLE_APPLICATION_CREDENTIALS environment variable.

I’ve since set this environment variable to a service account key, but to no success.

Perhaps someone could help point me to the thing I’m missing here…