Are Build Secrets Visible to the Runner Platform?

Answer

No. GitHub stores your secrets and delivers the ones a workflow references into the job environment on the runner, and the runner platform documents that it does not access or store them. The sentence a reviewer should record comes from the WarpBuild runner security documentation: WarpBuild does not access or store any build secrets, and secrets are stored in your source code repository and are only accessible to your runner environment.

The second half of the question is the one worth spending time on. Inside a running job the secret is readable by every process that job starts, on any runner, because that is how GitHub Actions delivers a secret to a build step (GitHub documentation on using secrets, checked on 2026-08-13). A review therefore has two separate questions: what the platform holds outside your job, and what code inside your job can reach.

WarpBuild provides Linux x64, Linux ARM64, macOS, and Windows runners, and every label in that catalog gets the handling in the table above.

Detail

What the platform documents

Three statements on the runner security page carry the whole vendor side of the answer, and each is short enough to paste into a questionnaire.

• Compute isolation. Each runner runs in its own virtual machine. The virtual machines are created on demand and destroyed after each build, and they are not reused.
• Storage protection. Each runner has its own encrypted storage volume, created on demand and destroyed after each build. When caching is enabled, the cache is encrypted and stored in a location that is only accessible to your runner.
• Secrets. WarpBuild does not access or store any build secrets. Secrets are stored in your source code repository and are only accessible to your runner environment.

The attestation behind those statements is SOC 2 Type 2 with three Trust Services Criteria: Security, Availability, and Confidentiality. Request the report and the supporting security documentation at trust.warpbuild.com. The security review checklist lists the five questions reviewers ask in the order they ask them.

The threat boundary a job actually has

GitHub exposes a secret only when a workflow names it through the secrets context, in an env block or a with input. Once named, the value becomes an environment variable or a process argument on the runner, and four consequences follow from that.

1. Scope is set by where you write the env block. A secret declared at job level sits in the environment of every step in that job. Declared on a single step, it reaches that step alone.
2. Third party actions share the machine. An action running in the same job reads the same environment and the same filesystem as your build script. Pinning each action to a full length commit SHA is what stops a moved tag from changing the code that runs next to your credential.
3. Log masking is a literal string match. GitHub redacts the exact value when it appears in a log. A step that base64 encodes the value, splits it, or embeds it in structured output can print something the mask does not catch, which is why GitHub advises against storing structured data as a secret (GitHub documentation on using secrets, checked on 2026-08-13).
4. Fork pull requests are excluded. GitHub withholds repository secrets from a workflow triggered by a pull request from a fork, so an untrusted contribution runs with only the job's own read scoped token available to it (GitHub documentation on using secrets, checked on 2026-08-13).

None of that is specific to a runner vendor. What the runner model changes is the exposure window after the job: on a machine that is destroyed after each build, whatever a step wrote to disk goes with the volume, so there is no host left holding this morning's credential file when an unrelated job runs this afternoon.

Hardening one: exchange an identity token instead of storing a key

The strongest version of this answer removes the stored secret. A job with the id-token: write grant asks GitHub for a signed identity token, hands it to the cloud provider, and gets back credentials that expire on their own.

name: deploy
on:
  push:
    branches: [main]

permissions: {}

jobs:
  deploy:
    runs-on: warp-ubuntu-latest-x64-4x
    environment: production
    permissions:
      contents: read
      id-token: write
    steps:
      - uses: actions/checkout@v5
        with:
          persist-credentials: false

      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::111122223333:role/github-actions-deploy
          aws-region: us-east-1

      - run: aws s3 sync ./dist s3://example-artifacts/site/ --delete

permissions: {} at the top of the file sets every scope to none for any job that stays silent, and the deploy job restates the two grants it needs. The AWS role's trust policy pins the sub claim to repo:example-org/example-repo:ref:refs/heads/main, so a push to any other branch produces a different subject and the exchange fails at the cloud provider rather than in the workflow file (GitHub documentation on security hardening with OpenID Connect, checked on 2026-08-13). The credential step is aws-actions/configure-aws-credentials, a public repository you can read before you pin it. OIDC token exchange covers the claims and the trust policy in full.

persist-credentials: false is worth keeping in the same job. It stops the checkout action from writing a token into the local git config, so a build script cannot read it back out of .git/config.

Hardening two: scope what is left to an environment and a step

Some credentials have no token exchange available, such as a package registry token. Those belong in an environment secret rather than a repository secret, and in a step level env block rather than a job level one.

jobs:
  publish:
    runs-on: warp-ubuntu-latest-x64-2x
    environment: production
    steps:
      - uses: actions/checkout@v5

      - name: Build the package
        run: npm ci && npm run build

      - name: Publish
        env:
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
        run: npm publish

An environment secret resolves only for a job that declares that environment, and the environment can require reviewers or restrict which branches may deploy to it (GitHub documentation on managing environments, checked on 2026-08-13). Only the publish step carries the token, so a compromised dependency pulled in during npm ci runs in an environment that leaves it out. Managing secrets in GitHub Actions workflows covers the three secret scopes and when each one fits.

On BYOC the boundary sits inside your account

Teams whose policy puts the machine itself under their own control run BYOC. Each job runs on a distinct, freshly provisioned instance that is terminated when the job completes, and the permissions available to that instance are exactly what you provide through security groups and IAM instance profiles. WarpBuild does not inject additional permissions into runner workloads (BYOC security hardening).

Two settings on that page apply directly to credential exposure. Attach a least privilege instance profile per runner, scoped to the one registry or bucket that workload touches, so a leaked job never reaches more than its own resources. Set IMDSv2 to required on the runner, which blocks the request shape an SSRF uses to read instance credentials out of the metadata service.

Related Questions

Can WarpBuild read the secrets our workflows use?

No. The runner security documentation states that WarpBuild does not access or store any build secrets, and that secrets are stored in your source code repository and are only accessible to your runner environment. That environment is a virtual machine created on demand for one job and destroyed after the build, along with its encrypted storage volume. The security review checklist points at the documentation page behind each statement, so a reviewer reads the source rather than a summary.

What can read a secret while the job is running?

Every process the job starts. A secret referenced in a job level env block sits in the environment of every step, including third party actions, so a compromised action in the same job reaches the same value (GitHub documentation on using secrets). Scope each secret to the one step that needs it, pin actions to a full length commit SHA, and prefer a short lived credential from an OIDC token exchange over a stored key. Managing secrets in GitHub Actions workflows works through the scoping rules step by step.

Does the answer change on BYOC runners?

The boundary moves into your own cloud account. Each job runs on a freshly provisioned instance that is terminated when the job finishes, and the permissions it carries are the ones you attach through your own security groups and IAM instance profiles, since WarpBuild does not inject additional permissions into runner workloads (BYOC security hardening). Require IMDSv2 and attach a least privilege instance profile per runner, and the evidence a reviewer wants comes out of your own cloud audit log. The security review checklist covers both deployment shapes side by side.