A username is readable but not a durable audit key
A fictional museum uses GitHub Actions to validate captions before publication. A run log currently stores only GITHUB_ACTOR, the username of the person or app that initiated the workflow. Usernames can be changed, and a release reviewer may mistakenly read a later name as proof of who performed the original action. GitHub also supplies GITHUB_ACTOR_ID, the numeric account ID for the person or app that triggered the initial workflow run. This makes a useful identity reference for an internal audit ledger. It does not, by itself, show that anyone approved the captions or that the triggering account had authority to publish.
Distinguish initial actor, run event and rerun initiator
The variables reference defines GITHUB_ACTOR_ID for the account that triggered the initial workflow run, not a generic current approver. Other variables such as GITHUB_ACTOR, GITHUB_TRIGGERING_ACTOR, GITHUB_EVENT_NAME and GITHUB_RUN_ATTEMPT describe related but different context. A rerun can be initiated by a different account while the original actor identity remains relevant to permissions. Preserve these fields with clear labels in the audit record. Do not interpret the triggering actor as the person who signed off editorial text. The existing GitHub review and protection process should be the source of approval evidence, not a name copied from environment variables.
Record a minimal provenance row for each CI attempt
An effective row can contain a repository ID, workflow run ID, attempt number, event name, actor ID, actor login for display, workflow revision and checked commit. Some of these identifiers describe the repository or automation, not the reviewed document itself. Add a caption inventory checksum or approved artifact reference to relate the run to actual content. Avoid dumping full webhook payloads into a public report; those may contain text, email addresses or operational details not needed for release transparency. Store the structured ledger where authorized reviewers can inspect it. A numeric actor ID identifies an account, but context determines what action it performed.
Read the environment variable without executing it
Within a trusted shell step, read GITHUB_ACTOR_ID as data and write it to a structured output record, using appropriate quoting and escaping. Do not concatenate the value into executable shell code. Although GitHub provides the default variable, another untrusted workflow input could be mixed into the same logging command. Prefer strict field names and serializer libraries when producing JSON rather than hand-building text with shell interpolation. Keep the record small and make the local audit processor validate field types. A missing or malformed actor ID should block a provenance claim, not prompt the system to guess a value from the username.
Use numeric IDs to reconcile account renames
Imagine the same maintainer contributes captions under one login in spring and a different login later that year. A ledger keyed only on the visible username can misleadingly appear to show two independent people. Keeping the numeric account ID allows an internal system to correlate entries attributed to the same GitHub account, subject to your identity governance and retention rules. Do not assume the identifier represents a human being rather than a bot or service account. It also should not be used as a secret, a password or a blanket permission token. Display the current name only when it is needed for a reviewer.
Compare identity proof with editorial approval
In the unsafe path, a release checklist sees an actor login and marks captions “approved.” In the controlled path, the ledger stores the initial actor ID and event, then separately checks pull request reviews, protected branch rules, the tested commit and the release artifact. The latter is more defensible because triggering a workflow is not the same as approving the content. The diagrams are conceptual; they do not depict real account history or a tested organizational configuration. Treat the actor ID as a pointer for investigation, not a certificate that caption quality or accessibility has been validated.
Avoid privilege assumptions on reruns and forks
When workflows can be rerun, record the attempt as a new execution while preserving the original run identity. GitHub documentation distinguishes original and triggering actor fields; permissions of reruns do not simply become the privileges of the user who clicked rerun. Apply least-privilege permissions to jobs and keep untrusted pull request code away from release secrets. Check event type and protected branch conditions independently. A numeric actor ID does not authorize deployment or prove that the actor accepted a policy. All release gates must use authoritative GitHub protections and the organization’s review records rather than identity variables alone.
Test the ledger with synthetic review histories
Create a fixture set with two runs from the same fictional account under different display names, one run from an app, and a rerun initiated by another fictional reviewer. Ensure the normalized ledger does not merge distinct accounts simply because names match, and does not create two accounts because a login string changed. Test handling of absent fields and malformed report inputs. Confirm that a changed run attempt does not overwrite a previous artifact in your evidence storage. This is a tabletop or controlled CI test; the article does not claim access to anyone’s real GitHub audit data.
Release the evidence, not private identity details
For a public report, summarize the check outcome, tested commit, tool version and approval status without unnecessarily exposing personal identities. Keep actor IDs in a restricted audit store according to the organization’s retention policy. If a reviewer asks who approved a caption, link to the appropriate review record rather than answering from the workflow trigger field. The final sign-off should require source caption review, passing tests, a trusted workflow revision and explicit release authorization. GITHUB_ACTOR_ID strengthens traceability when used correctly; it is not a substitute for any one of those controls.
How We Research
For this guide we reviewed official, named primary sources on November 10, 2026: GitHub Actions variables reference; GitHub Actions contexts reference. We cross-checked parameter names, response structures and documented limits against the described use case, then designed a hypothetical, non-sensitive museum workflow. The diagrams explain possible paths rather than represent live tests, screenshots, measured performance or a verified compliance review. Pricing and service behavior can change; readers should confirm the current reference, test with fixtures and obtain organizational approval before any production change.
Frequently Asked Questions
It is the numeric account ID of the person or app that triggered the initial workflow run, as defined in GitHub’s variables reference.
No. GITHUB_ACTOR is a username; GITHUB_ACTOR_ID is the associated account ID. Record both only where needed for an authorized audit.
No. It identifies the initial workflow trigger account. Review approvals must come from GitHub review records and branch protection checks.
Preserve the original actor identity, run and attempt identifiers, triggering actor context and tested commit without overwriting older evidence.
Usually not unless there is a specific justified need. Prefer a public summary and keep detailed identities in a restricted audit ledger.