Prompt OIDC users to migrate trust policies

[dannymidnight]

Why

An action can successfully mint a Buildkite OIDC token while the target service still trusts GitHub's issuer and claims. Today the job produces no migration guidance at mint time, so a green build can hide the requirement to update that trust policy.

Closes PB-3066

This covers the OIDC slice of PB-2951. PB-2717 concerns GitHub issuer parity; this PR documents Buildkite-native issuer behavior and does not claim to resolve it.

What

After the first authorized token request successfully mints and protects a token, publish one trusted job warning:

Buildkite issued this job an OIDC token with issuer https://agent.buildkite.com, not GitHub's https://token.actions.githubusercontent.com. Update the target service's OIDC trust policy from GitHub's issuer and claims to Buildkite's issuer and claims. See https://buildkite.com/docs/pipelines/security/oidc.

Additional token requests do not duplicate the warning. Unauthorized or failed mint attempts do not claim that a token was issued; existing HTTP status handling and token secrecy are unchanged. The compatibility guide distinguishes Agent mint denial from a later downstream trust-policy rejection.

Preview

GitHub Actions warnings

Buildkite issued this job an OIDC token with issuer https://agent.buildkite.com, not GitHub's https://token.actions.githubusercontent.com. Update the target service's OIDC trust policy from GitHub's issuer and claims to Buildkite's issuer and claims. See https://buildkite.com/docs/pipelines/security/oidc.

General

[buildsworth-bk-app]

No inline findings. This changes behavior in the OIDC token issuance path, so it needs human review.

Want to dig deeper?

Paste this into your agent to explore the findings from this review's Buildkite build:

Download the buildsworth logs from build 20463, then answer my questions about the findings.

Install the reading-buildsworth-logs skill to run this.

About buildsworth

Model: gpt-5.6-sol with xhigh thinking.

How to request a review: Comment @buildsworth-bk review on the PR, or request buildsworth-bk as a reviewer.

Risk labels (how buildsworth classifies risk) — buildsworth classifies risk itself from the diff. Unless repository policy already allows L2 approval, grant it by mentioning @buildsworth-bk (see approval ceiling and L2 approval grant):

• L1 — Low risk (dep bumps, docs/copy, lockfiles, small presentational fixes). buildsworth may approve by default.
• L2 — Standard risk (new UI, additive API fields, refactors). Approved only when repository policy or a verified grant allows it; otherwise comment-only.
• L3 — High risk (auth, migrations, payments, secrets, perf-critical paths). Human review always required.