Mint Ephemeral Tokens

I'd like to:

Stop relying on callers passing GH_AW_GITHUB_TOKEN via job outputs
Today consumers do:

GH_AW_GITHUB_TOKEN: ${{ needs.mint-gh-aw-github-token.outputs.token }}

Masked installation tokens often do not survive as job outputs into the next job / nested workflow_call secrets: map. The product fix is not “smarter callers”, it is minting (or otherwise supplying the token) inside the lock workflow, without crossing that boundary.
Mint inside every job that actually uses GH_AW_GITHUB_TOKEN
The generated lock workflows (e.g. gh-aw-issue-triage.lock.yml) use secrets.GH_AW_GITHUB_TOKEN in several jobs, not only the agent container job—for example activation, agent, safe_outputs, conclusion, etc. (anything that passes github-token: or env derived from that secret).

So the pending work is roughly:

For each such job: add permissions: id-token: write (minimum on that job), a first step elastic/oblt-actions/github/create-token@v1 (with the right token-policy / catalog story your org uses), and wire later steps to steps..outputs.token (or job env built from that step) instead of secrets.GH_AW_GITHUB_TOKEN when no caller secret was provided—or always prefer mint for Elastic if that is the policy.
Re-run make compile so *.lock.yml matches the edited *.md / fragments (lock files are generated; do not hand-edit as the long-term source of truth).
Importing a fragment only into runtime-setup.md is not enough by itself: that path mainly affects the agent job’s setup steps; it does not automatically fix activation / safe_outputs / conclusion unless the gh-aw pipeline applies the same bootstrap there or the compiler gains a first-class “ephemeral GitHub token step” hook for all token-consuming jobs.
Contract / docs
Decide whether GH_AW_GITHUB_TOKEN stays as an optional override (PAT or pre-minted token) or becomes deprecated for Elastic ingress once in-workflow minting is the default.
Update gh-agent-workflows/*/README.md (and any consumer docs) so they say callers should omit GH_AW_GITHUB_TOKEN when OIDC + create-token is used inside the lock workflow.
Same idea for other lock workflows that need ephemeral mutations
Any other gh-aw-*.md that documents GH_AW_GITHUB_TOKEN for “labels/comments must re-trigger workflows” needs the same in-workflow mint pattern (or an explicit decision that those flows only use GITHUB_TOKEN and accept no re-triggers).

3 related issues

Issue Fixer can use Ephemeral Token #1025 — Tracks enabling ephemeral-token support for the issue-fixer workflow, which is directly relevant to this issue’s token-minting capability area.
Issue Triage can use Ephemeral Token #1024 — Covers ephemeral-token support for issue-triage, with implementation context that may transfer to this issue.
Dependency Reviewer use Ephemeral Token #1010 — Covers ephemeral-token support for dependency-reviewer, which may provide prior design and rollout decisions useful for this issue.

Note

🔒 Integrity filter blocked 6 items

The following items were blocked because they don't meet the GitHub integrity level.

#1067 issue_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
#1067 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
#1024 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
#1010 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
#140 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
#1025 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

What is this? | From workflow: Trigger Duplicate Issue Detector

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

tl;dr: the repo currently does not mint ephemeral GitHub tokens for issue triage; it only accepts externally provided tokens (or falls back to GITHUB_TOKEN), so implementing a mint step is a valid and actionable improvement.

Recommendation: add an optional token-mint path (GitHub App installation token) in the trigger layer, then pass the minted token into reusable workflows via GH_AW_GITHUB_TOKEN/GH_AW_GITHUB_MCP_SERVER_TOKEN, while preserving current secret-based override behavior.

Findings

Issue-triage consumes tokens from secrets/fallbacks, not mint outputs
- .github/workflows/gh-aw-issue-triage.lock.yml:695-697 (GH_AW_GITHUB_MCP_SERVER_TOKEN || GH_AW_GITHUB_TOKEN || GITHUB_TOKEN for GitHub script auth)
- .github/workflows/gh-aw-issue-triage.lock.yml:912 (MCP server token comes from same fallback chain)
- .github/workflows/gh-aw-issue-triage.lock.yml:1246, 1262, 1276, 1290, 1320, 1633 (safe-output/github-script handlers use GH_AW_GITHUB_TOKEN || GITHUB_TOKEN)
Public contract/docs describe passing an ephemeral token, not minting one
- .github/workflows/trigger-issue-triage.yml:27-33 (optional commented GH_AW_GITHUB_TOKEN pass-through)
- gh-agent-workflows/issue-triage/README.md:38-40 (optional ephemeral token example/description)
- gh-agent-workflows/issue-triage/example.yml:23-29 (commented secret pass-through)
- docs/workflows/gh-agent-workflows/issue-triage.md:37, 71-75 (same pattern in published docs)
Repo-wide setup emphasizes PAT provisioning, not runtime token minting
- docs/index.md:11-15 (Copilot PAT setup)
- docs/workflows/gh-agent-workflows.md:132-139 (required COPILOT_GITHUB_TOKEN guidance)
- scripts/quick-setup.sh:215-224, 248 (interactive PAT capture and secret set)
Constraint during triage
- I could not read issue Mint Ephemeral Tokens #1067 body/comments due MCP integrity filtering in this run, so this recommendation is based on the issue title + code/docs evidence.

Verification

I ran targeted searches to verify whether minting primitives are present in source workflows and how issue-triage handles token wiring:

$ grep -RInE "create-github-app-token|ACTIONS_ID_TOKEN_REQUEST_URL|installation[_-]token|app[_-]id|private[_-]key|\bjwt\b" .github/workflows gh-agent-workflows docs --exclude='*.lock.yml'
# (no matches)

$ grep -RIn "id-token:\s*write" .github/workflows --exclude='*.lock.yml' | head -n 40
.github/workflows/mkdocs.yml:15:  id-token: write

$ grep -nE "GH_AW_GITHUB_TOKEN|GITHUB_MCP_SERVER_TOKEN|github-token:" \
  .github/workflows/gh-aw-issue-triage.md \
  .github/workflows/gh-aw-issue-triage.lock.yml \
  gh-agent-workflows/issue-triage/README.md \
  gh-agent-workflows/issue-triage/example.yml \
  docs/workflows/gh-agent-workflows/issue-triage.md
# confirms fallback-chain consumption and optional secret pass-through

Detailed Action Plan

Add optional minting inputs/secrets for trigger workflows (GitHub App credentials), starting with gh-agent-workflows/issue-triage/example.yml and compiled .github/workflows/trigger-issue-triage.yml.
Add a pre-step in trigger workflow to mint installation token (for example via actions/create-github-app-token) and export outputs.
Pass minted token into reusable workflow call as GH_AW_GITHUB_TOKEN (and optionally GH_AW_GITHUB_MCP_SERVER_TOKEN if you want separate MCP token control).
Keep current precedence: explicit provided token > minted token > GITHUB_TOKEN, and document this precedence clearly.
Update docs to include both modes (provided token vs auto-minted token):
- gh-agent-workflows/issue-triage/README.md
- docs/workflows/gh-agent-workflows/issue-triage.md
- central docs if needed (docs/workflows/gh-agent-workflows.md).
Regenerate lock workflows from source (make compile) so .github/workflows/gh-aw-issue-triage.lock.yml stays in sync.

Related Items

Type	Link	Relevance
PR	#1026	Added `GH_AW_GITHUB_TOKEN` to issue-triage contract/docs; pass-through support exists but no minting path
PR	#1027	Similar token-contract work in issue-fixer (same architectural direction)
PR	#1030	Recent issue-triage workflow evolution (labels/safe outputs), useful for implementation pattern
File	`.github/workflows/gh-aw-issue-triage.lock.yml`	Current runtime token source/fallback behavior
File	`.github/workflows/trigger-issue-triage.yml`	Caller-facing secret wiring point for introducing mint step
File	`gh-agent-workflows/issue-triage/README.md`	User-facing contract that should document minted-token mode

Note

🔒 Integrity filter blocked 10 items

The following items were blocked because they don't meet the GitHub integrity level.

#1067 issue_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
#1067 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
#1025 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
#1010 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
#1024 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
#140 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
#700 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
#699 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
Mint Ephemeral Tokens #1067 issue_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
Mint Ephemeral Tokens #1067 list_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

What is this? | From workflow: Trigger Issue Triage

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

/ai I'd like to explore the option about minting the token in a fragment since ephemeral token as secrets can't be shared to another jobs and therefore neither to the reusable agentic workflows. So I don't want to mint the token in the trigger but in the gh-aw-* job or in the gh-aw-fragments

Minting the GitHub API token inside the reusable gh-aw-* workflow is a good direction, and it avoids the cross-job secret handoff problem.

Today, the token is expected from the caller and then consumed inside the compiled workflow:

Caller passes secrets into reusable job (gh-agent-workflows/mention-in-issue/example.yml#L18-L20, trigger-mention-in-issue.yml#L24-L27).
Runtime uses secrets.GH_AW_GITHUB_MCP_SERVER_TOKEN || secrets.GH_AW_GITHUB_TOKEN || secrets.GITHUB_TOKEN for GitHub MCP/auth (.github/workflows/gh-aw-mention-in-issue.lock.yml#L667-L670, #L935, #L1058).
Docs already frame GH_AW_GITHUB_TOKEN as optional ephemeral/app token (gh-agent-workflows/issue-triage/README.md#L38-L40, docs/workflows/gh-agent-workflows/issue-triage.md#L36-L38).

A practical design is:

Add optional workflow_call inputs/secrets for App auth (for example GH_AW_APP_ID, GH_AW_APP_PRIVATE_KEY, optionally GH_AW_APP_INSTALLATION_ID).
In gh-aw-* (or a shared gh-aw-fragments/* auth fragment), mint the installation token at runtime (e.g. with actions/create-github-app-token) in the same job that starts MCP/safe-outputs.
Feed that minted token into the existing fallback chain (prefer minted token, then explicit GH_AW_GITHUB_MCP_SERVER_TOKEN/GH_AW_GITHUB_TOKEN, then GITHUB_TOKEN).

That keeps token minting local to the called workflow execution and removes the need to pass an already-minted ephemeral token between jobs/workflows.

One important boundary: this only addresses GH_AW_GITHUB_TOKEN/MCP GitHub API auth. COPILOT_GITHUB_TOKEN is a different auth path for the Copilot engine and still needs to be provided as required by workflow_call today (.github/workflows/gh-aw-mention-in-issue.md#L57-L60).

Note

🔒 Integrity filter blocked 2 items

The following items were blocked because they don't meet the GitHub integrity level.

Mint Ephemeral Tokens #1067 issue_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
#1067 issue_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

What is this? | From workflow: Trigger Mention in Issue

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

Navigation Menu

Repository navigation

Mint Ephemeral Tokens #1067

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Mint Ephemeral Tokens #1067

Description

Activity

github-actions commented on May 4, 2026

github-actions commented on May 4, 2026

fr4nc1sc0-r4m0n commented on May 4, 2026

github-actions commented on May 4, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions