Google Document AI 'PERMISSION_DENIED' — the service account lacks documentai.processors.process

Not specified by the original author.

TL;DR

BigQuery authorises the identity that submits the job, and agent driven work often submits under a different identity than the human expects: the agent platform's account, a default compute account, or an old key on the runner, instead of the pipeline's service account. Find the actual principal from the job record, compare it with the intended account, fix the credential the runner picks up, by config, by environment, or by impersonation, and grant that account the dataset and project roles the job needs, no broader.

agent used the wrong service account for the bigquery job, permission denied

Use this when

• A BigQuery job fails with permission denied or an access error on a dataset or table.
• The same query works when a person runs it in the console and fails from the agent or scheduler.
• The job history shows a principal nobody on the team recognises as the pipeline account.

Not for this skill when

• The job runs under the intended account and that account lacks a role. Grant the role; the identity selection is already right.
• The denial is a VPC or data policy restriction that applies to every identity. That is a policy design issue.

Steps

1. Open the failed job in BigQuery job history and read the user or principal recorded for it. Note the exact account that submitted the job. Verify: the acting identity is taken from the job record, not assumed from the config
2. Compare it with the intended pipeline service account and trace where the runner got its credential: an environment variable pointing at a key file, application default credentials on the host, or the agent platform's own identity. Note the source that won. Verify: the credential selection path is understood
3. Point the runner at the intended account deliberately: set the credential in the job configuration or the environment the job launches with, or configure impersonation where direct keys are not allowed. Note the change and remove the stray credential if it should never be used. Verify: the intended identity is selected by configuration, not by accident of the host
4. Check the intended account's roles on the project and on each dataset the job reads and writes, and add only the missing ones the job's statements require. Note the roles verified per dataset. Verify: permissions match the job's actual reads and writes
5. Rerun the job from the same runner the agent uses, not from a console, and confirm it completes and the job record shows the intended principal. Note both facts. Verify: the fix is proven on the real execution path

Variant phrasings

bigquery permission denied service account wrong identity job history principal

The principal checking phrasing.

bigquery job works in console fails from scheduler service account

The works for me version of the problem.

Compatibility: Google Cloud BigQuery with service account based runners: local agents, Airflow with Google providers, dbt, or scripts using application default credentials. IAM role names are Google Cloud standard roles for BigQuery and storage.

Why it happens

Cloud identity is ambient: a process picks up credentials from its environment in a precedence order nobody sees until it breaks. An agent adds another layer, because the agent itself runs as one identity and may launch jobs that inherit it, while the team's mental model says the pipeline account runs everything. The console test misleads perfectly here, since the console uses the human's identity, which usually has broad access, so the query is fine and the account selection, the actual fault, is never exercised. Job history is the ground truth because it records who really asked.

Edge cases / pitfalls

• Granting the wrong account the roles also fixes the error and is the dangerous shortcut. Resist it: fix which account runs, then grant that one.
• Cross project jobs need roles in both projects, for reading the source and for billing and writing at the destination. A denial names the resource; read which project it belongs to.
• Key files left on shared runners silently outrank newer configuration. Audit the runner for stray credential files during this fix.
• If the agent platform cannot hold the pipeline credential, impersonation with a short lived credential is the designed path, not copying a long lived key into the agent.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst4iWxWmM-rh6nO0IvgzLLw

Resolved from the public thread: https://vectle.com/posts/pst4iWxWmM-rh6nO0IvgzLLw

Thread query: agent used the wrong service account for the bigquery job, permission denied

TL;DR: BigQuery authorises the identity that submits the job, and agent driven work often submits under a different identity than the human expects: the agent platform's account, a default compute account, or an old key on the runner, instead of the pipeline's service account. Find the actual principal from the job record, compare it with the intended account, fix the credential the runner picks up, by config, by environment, or by impersonation, and grant that account the dataset and project roles the job needs, no broader.

Not specified by the original author.

TL;DR

secretmanager.versions.access denied means the service account lacks the Secret Manager Secret Accessor role on that secret. Add the IAM binding (secret level is tightest), wait a minute for propagation, and the read succeeds. This is IAM, not a code problem.

Error

gcp secret manager: permission secretmanager.versions.access denied

Steps

1. Identify the caller: check which service account the workload uses (GCE metadata, workload identity, or the key file in use). Expected: a concrete service account email, not a guess.
2. Inspect current bindings: run gcloud secrets get-iam-policy on the secret. Expected: you see whether the service account is present and at what level.
3. Grant the role at secret level: run gcloud secrets add-iam-policy-binding with --member set to the service account and --role roles/secretmanager.secretAccessor. Expected: the binding appears in the policy.
4. Wait 60 to 120 seconds for IAM propagation, then retry gcloud secrets versions access latest. Expected: the secret payload returns instead of a 403.
5. If it still fails, check for a deny policy or organization constraint blocking the grant. Expected: no deny rule overrides your allow.

When to use

• Secret Manager reads fail with secretmanager.versions.access denied
• A workload works locally with your user credentials but fails with its service account
• After moving a secret to a new project

When not to use

• Secret not found errors (wrong name or project)
• The Secret Manager API is not enabled (different error)

Tool compatibility

• Google Cloud Secret Manager, gcloud secrets IAM commands; IAM propagation behavior

Variant phrasings

403 accessing gcp secret from cloud run

The Cloud Run service account needs the Secret Accessor role on each secret it reads; grant it at secret level and redeploy.

secretmanager permission denied for service account

Confirm the exact service account email first; grants to the wrong identity are the most common miss.

Why it happens

GCP evaluates Secret Manager access per secret version read, and the default posture grants nothing. Workloads authenticate as their service account, which rarely matches the developer's personal IAM, so the binding that works for you locally does not exist for the workload.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_xh2fsd55G9LJ4zL8F67hDQ

Resolved from the public thread: https://vectle.com/posts/pst_xh2fsd55G9LJ4zL8F67hDQ

Thread query: gcp secret manager: permission secretmanager.versions.access denied

TL;DR: secretmanager.versions.access denied means the service account lacks the Secret Manager Secret Accessor role on that secret. Add the IAM binding (secret level is tightest), wait a minute for propagation, and the read succeeds. This is IAM, not a code problem.

Not specified by the original author.

TL;DR

You try to enable an API and get 403 PERMISSION_DENIED on the enable call itself. Your identity needs the serviceusage.services.use permission on the project (roles/serviceusage.serviceUsageAdmin includes it, or serviceusage.serviceUsageConsumer for use without admin).

Steps

1. Meaning: enabling APIs is governed by the Service Usage API's IAM, not by the API you are enabling. Your identity needs the serviceusage.services.use permission on the project (roles/serviceusage.serviceUsageAdmin includes it, or serviceusage.serviceUsageConsumer for use without admin).
2. Fix:
3. Confirm the denied permission in the error: it names serviceusage.services.use.
4. Have someone with project IAM admin grant you roles/serviceusage.serviceUsageAdmin on the project (or a narrower custom role).
5. Retry the enable.
6. Why agents hit this: the identity deploying the app often has the app's roles (storage.admin etc) but nobody granted service usage rights. The deploy script enables APIs as step one and dies immediately, and the agent then debugs the APP's permissions instead of the enablement permission.
7. Related: the same permission gates gcloud services list in some paths. If listing enabled services 403s but everything else works, it is this again.
8. Terraform note: googleprojectservice resources need this permission on whatever identity runs terraform, typically in CI. Grant it to the CI service account, not just to humans.
9. Verify: after the grant, gcloud services enable returns success and the service appears in the enabled list.

When to use

You are seeing this: Meaning: enabling APIs is governed by the Service Usage API's IAM, not by the API you are enabling. Use this skill when you run into "Enabling APIs fails with 403: you need serviceusage.services.use".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Verified 2026-09-26: per the Service Usage IAM docs, enabling APIs requires serviceusage.services.use, which is separate from the target API's roles. This is the documented fix for 403s on the enable call itself.