Can a Cloud Run Job task authenticate its execution and attempt before its first metadata credential request?

Is there a documented Google Cloud mechanism that allows an external admission service to authenticate a particular Cloud Run Job execution, task and attempt before the task’s application code requests credentials from the metadata server?

We need to associate one single-use admission grant with a verifiable running execution/task/attempt. The admission service would durably consume the grant and atomically reserve the physical-request allowance before permitting the controlled credential request. The proof used for admission cannot depend on the credential whose acquisition is being gated.

  • Does Google expose a signed attestation, independently verifiable token or other supported proof of execution/task/attempt identity at that point? If so, what does it attest, how is it obtained, and how can an external verifier reject substitution or replay? Are execution names, task environment variables or control-plane records merely identifiers rather than authenticated proof of the calling task?
  • Can a supported mechanism enforce this order across duplicate job launches, separate executions, task attempts and restarts? Following a crash or lost acknowledgement, which control-plane records can be read back without reissuing admission authority?
  • What platform, metadata-server or SDK requests may occur before application-controlled admission, and which retries or additional attempts can occur even with task retries configured to zero? Which records can be correlated to actual credential-request attempts?

Please identify the precise official documentation or API contract and separate guarantees provided by Google from application responsibilities (such as atomic grant consumption, budgeting and recovery). If no supported pre-credential proof exists, please identify the missing guarantee. Our recovery rule is to hold uncertain outcomes without restoring spent authority.

References for context: Introduction to service identity · Container runtime contract · REST Resource: projects.locations.jobs.executions · Method: projects.locations.jobs.run · Set maximum retries for jobs.