For discussion : solution direction for automatic user attribution for Copilot coding agent sessions in reusable workflows

Summary

I would like to discuss a mechanism for engine: copilot (gh-aw) workflows to attribute Copilot coding agent premium requests to the user who triggered the workflow — without requiring a user-specific COPILOT_GITHUB_TOKEN PAT to be stored as a repository secret.

One possible approach I've explored is leveraging the OIDC actor / actor_id claims already present in the GitHub Actions runtime. I describe this in detail below as a starting point for discussion, while recognising that GitHub may have better approaches to solve this problem. This solution would also require changes beyond gh-aw, but it feels like this is the right repo to start the discussion from.

Context: platform-orchestrated coding agent sessions

An internal developer platform that provides standardised coding agent workflows to application teams across the organisation. The platform is hosted in a central repository and exposes reusable workflows that consumer teams invoke via workflow_call with secrets: inherit.

The flow:

1. A developer posts a slash command on an issue in their team's repository.
2. A thin caller workflow in the consumer repo triggers a reusable workflow in the platform repo via workflow_call.
3. The reusable workflow runs an engine: copilot (gh-aw) coding agent session — the agent reads the issue, writes code, and creates a pull request.
4. The developer reviews and merges.

Multiple teams across the organisation use the same platform workflows.

The problem: cost attribution for platform-orchestrated sessions

When a developer uses Copilot directly — assigning @copilot to an issue, using Copilot Chat, or accepting completions — premium requests are automatically attributed to that developer. No configuration is needed.

Platform-orchestrated sessions break this model. The engine: copilot runtime authenticates the coding agent session using COPILOT_GITHUB_TOKEN, a secret that must be present in the repository where the workflow executes. This token is a user-specific PAT — premium requests are attributed to whoever owns the token, not to the developer who triggered the run.

In a reusable workflow (workflow_call) scenario:

• If the consumer repo provides the token via secrets: inherit, the session bills to one team member whose PAT is stored as the secret — not the triggering user.
• If the platform repo provides the token, all sessions across all teams bill to a single platform account.

Neither option provides accurate per-user attribution.

How the current authentication chain works

The chain from a gh-aw workflow to a billed Copilot session involves three distinct systems:

gh-aw (compiler + runtime)  →  Copilot CLI  →  GitHub Copilot API (backend)

The billing decision — who pays — is made at the last layer (Copilot API backend), based on token ownership. Every layer upstream simply passes the token through. This means any solution will require changes across multiple layers of this chain.

Current workaround (functional but not ideal)

Our current approach requires each consumer team to store a COPILOT_GITHUB_TOKEN in their repository secrets. This is a user-specific fine-grained PAT with the Copilot Requests permission, passed to the platform workflow via secrets: inherit.

# Consumer repo: .github/workflows/platform-caller.yml
name: Platform Agent
on:
  issue_comment:
    types: [created]

jobs:
  agent:
    if: contains(github.event.comment.body, '/run-agent')
    uses: org/platform-repo/.github/workflows/agent.lock.yml@main
    secrets: inherit

Why this is not ideal

None of these concerns exist for normal @copilot usage, where GitHub attributes sessions to the triggering user automatically.

What we're aiming for

A way for engine: copilot sessions to automatically attribute premium requests to the user who triggered the workflow, without requiring that user's PAT to be stored as a repository secret. The desired end state:

• Per-user attribution — identical to how native @copilot usage is billed today.
• Zero secret management — no PATs, no service accounts, no rotation.
• No consumer repo configuration — beyond the caller workflow file itself.

We don't prescribe a specific implementation. GitHub may have approaches we haven't considered. Below we sketch one possible solution based on OIDC as a starting point for discussion.

One possible approach: OIDC-based user attribution

The insight

The GitHub Actions OIDC provider (token.actions.githubusercontent.com) already issues tokens that contain the triggering user's identity:

{
  "actor": "octocat",
  "actor_id": "583231",
  "repository": "org/consumer-repo",
  "repository_id": "123456789",
  "job_workflow_ref": "org/platform-repo/.github/workflows/agent.lock.yml@refs/heads/main",
  ...
}

The actor and actor_id claims identify the developer who triggered the workflow — the person who posted the slash command. This information is already available to the GitHub Actions runtime at the point where the engine: copilot session is initiated.

How this could work

Allow the engine: copilot runtime to attribute the coding agent session's premium requests to the user identified by actor / actor_id, instead of requiring a user-specific COPILOT_GITHUB_TOKEN.

Conceptually, the flow could look like:

sequenceDiagram
    participant Dev as Developer (actor)
    participant Consumer as Consumer Repo
    participant Platform as Platform Workflow (workflow_call)
    participant Runtime as engine: copilot runtime
    participant OIDC as GitHub OIDC Provider
    participant CLI as Copilot CLI
    participant API as Copilot API Backend

    Dev->>Consumer: Posts slash command on issue
    Consumer->>Platform: workflow_call (secrets: inherit)
    Platform->>Runtime: engine: copilot step begins
    Runtime->>OIDC: Request OIDC token (id-token: write)
    OIDC-->>Runtime: JWT with actor=octocat, actor_id=583231
    Runtime->>CLI: Invoke with OIDC token (no COPILOT_GITHUB_TOKEN)
    CLI->>API: Initiate coding session (present OIDC token as user attestation)
    API->>API: Verify: actor has Copilot license? Verify: actor has premium request capacity?
    API-->>CLI: Session authorised, attributed to octocat
    CLI-->>Runtime: Session complete
    Runtime->>Consumer: Creates PR (attributed to octocat)

What this approach would touch

Based on our understanding of the authentication chain, this approach would require changes at multiple layers. The GitHub Actions OIDC provider already emits the required claims — no changes needed there.

What would NOT need to change

• Consumer repos: No secrets, no PATs, no service accounts. The triggering user's identity is carried by the OIDC token automatically.
• Platform workflows: No changes to workflow logic. The engine: copilot frontmatter remains the same.
• User consent model: The user already consented to the workflow running by posting the slash command. The OIDC token is an attestation of who they are, not a delegation of credentials.

Security considerations for the OIDC approach

Why this matters at scale

Alternatives we considered (and why they don't work)

Next steps

We'd welcome a conversation to validate this problem statement and explore feasible solutions — whether OIDC-based or otherwise. We are happy to participate in a preview programme and provide feedback from our production platform.

Impact

We believe the use case of centralised agent platforms calling engine: copilot via workflow_call will become increasingly common as organisations adopt agentic workflows. Solving the attribution problem now prevents every platform team from independently building workarounds around PAT management and token rotation.

This feature would make cost attribution for platform-orchestrated Copilot sessions identical to native @copilot usage — per-user, automatic, and zero-configuration.