Enterprise Policies, Allowed Actions, Runner Governance, and Auditability: Diagnostics, Failure Modes, and Production Practices

1. Diagnostic contract: preserve denial evidence before changing policy

A policy failure is often an intentional safety signal. The first response should be to preserve the run ID/attempt, workflow SHA, denial message, relevant policy snapshot and runner eligibility—not to broaden settings until the workflow turns green. Governance diagnostics must answer whether the workflow is wrong, the policy is wrong, the exception is missing, or the requested operation belongs on a different trust boundary.

Use the same causal order throughout this lesson: event/ref/SHA → selected workflow revision → effective policy and permissions → job graph → runner eligibility → action/runtime → artifact/deployment/external state → audit/exception evidence.

2. Evidence-first diagnostic sequence

1. Preserve the original run ID, attempt number, source SHA, workflow file and first denial/log evidence.
2. Confirm which enterprise, organization and repository policy layers apply and record their effective values.
3. Confirm the action/reusable-workflow reference, token permission request, event/fork trust, runner group and environment/rules state.
4. Inspect the job graph and queue. A job that never becomes eligible is different from a runner that starts and fails.
5. Confirm runner group, labels, runner image and any private network/trust assumptions.
6. Inspect the failing action or shell step only after policy and runner eligibility are understood.
7. Inspect artifacts, deployments and external targets before retrying any side effect.
8. Check audit/exception evidence for recent policy changes or expired waivers.
9. Apply the least destructive correction and rerun the smallest equivalent scope.

3. Failure mode: policy is so broad that it grants any Marketplace action

Suppose an organization believes “verified creators only” is equivalent to a curated supply-chain policy. A new workflow uses a verified Marketplace action with broad permissions and a mutable tag. The platform permits it, so there is no denial to alert the team. This is a governance false negative: policy eligibility is broader than the organization’s intended trust boundary.

# Intentionally weak policy outcome — do not use as a production pattern.
permissions: write-all
steps:
  - uses: verified-vendor/publish-action@v3

Repair by separating trust signals: select reviewed external repositories/patterns, require full action SHAs, establish least-privilege workflow templates and review external release diffs. Do not assume publisher verification evaluates the action’s permissions or code.

4. Failure mode: exception has no expiry

A migration waiver that never expires turns temporary risk into permanent policy debt. The observable failure is not a red workflow; it is stale governance state. Diagnose by querying the exception registry for missing or past expires_at, confirming whether the dependency is still used, and checking audit evidence for extensions.

{
  "exception_id": "EX-0042",
  "control": "actions.allowlist",
  "scope": "all repositories",
  "reason": "migration"
  // BUG: no owner, no exact dependency, no expiry, no removal condition
}

Least-destructive repair: narrow the resource scope, identify the risk owner, add a near-term expiry and compensating controls, then create the paved-road replacement. Do not silently rewrite history; retain the original weak exception as evidence and issue a superseding record.

5. Failure mode: a public repository can reach a privileged runner

This is a machine-boundary incident, not a YAML style problem. A public fork may submit code that executes under the pull-request workflow. If that workflow can reach a self-hosted or network-privileged runner, the attacker-controlled code may interact with local files, caches, network resources or credentials available to the machine.

Preserve the runner-group configuration, eligible repositories/workflows, queued/running job evidence and runner diagnostics. Then remove public-repository eligibility or route untrusted validation to GitHub-hosted runners. If the runner may have executed hostile code, follow the runner compromise process; merely moving the runner to another group does not prove the machine is clean.

6. Failure mode: repository YAML tries to override an enterprise deny

A team sees an error saying an action is not allowed and edits the workflow to add broader permissions, different runner labels or another environment. None of those changes address the controlling action policy. The job may remain blocked before execution because the executable dependency itself is ineligible.

The correct path is to identify the effective enterprise/organization action policy, determine whether the dependency should be reviewed and allowed, or replace it with an approved action/local implementation. Repository YAML cannot legitimately weaken the upstream deny. Preserve the original denial because it proves enforcement worked.

7. Failure mode: audit logs exist but are not retained/exported

Assume a policy changed four months ago and an incident review needs the exact administrator and old value. If the organization relied only on a short interactive window or failed to export relevant events, the missing evidence cannot be recreated from a green workflow run. A run records execution; it does not necessarily encode who changed the organization’s policy.

Repair prospectively: define required audit event categories, external retention where appropriate, access controls, integrity checks, deduplication for at-least-once streams and monitoring that detects a stopped export. The evidence gap itself belongs in the incident record.

8. Failure mode: policy blocks teams without a versioned paved road

A strict allowlist may be technically correct but operationally harmful if teams lack an approved way to build, test, publish or deploy. Symptoms include exception growth, duplicated shell scripts, long lead time and pressure to loosen global policy. The root cause is a platform-product gap, not necessarily developer resistance.

Measure denied workflows by use case, time-to-resolution, exception recurrence and platform adoption. Build versioned reusable workflows/actions that satisfy common needs with least privilege and immutable dependencies. This connects Chapter 34 back to Chapter 29: governance is sustainable when the control plane and golden path evolve together.

9. Intentionally broken example: diagnose the controlling layer

The following workflow is deliberately noncompliant. Assume the enterprise policy allows only approved actions, requires full action SHAs, defaults tokens to restricted mode, and the prod-deploy runner group permits only payments/.github/workflows/deploy.yml.

name: broken-release
on: pull_request
permissions: write-all
jobs:
  deploy:
    runs-on:
      group: prod-deploy
    steps:
      - uses: vendor/release-action@v2
      - run: echo "deploy"

Interpret it layer by layer. The mutable external action can be denied by action policy before execution. The runner group can deny this workflow path even if the action were allowed. The broad token request violates the platform standard and is especially inappropriate for untrusted PR code. The event itself is wrong for a privileged deployment. Fixing only the action SHA would leave several independent trust failures.

10. Recovery and rerun discipline

After a policy correction, do not blindly rerun every failed workflow. First verify whether any job reached a runner or external target. If the workflow was rejected before execution, a rerun after policy repair is usually lower risk. If some jobs ran before a later policy/runner/deployment failure, inspect artifacts and external side effects before repeating them.

Preserve the first run/attempt and policy snapshot. A second run under a changed policy is not equivalent evidence; it proves the new state. Your incident record should show the transition: original policy → denial or unsafe eligibility → authorized correction → new policy digest → successful verification.

11. Lesson summary

Governance failures can be too strict, too loose, incorrectly scoped or unauditable. Diagnose them at the layer that owns the state: executable dependency policy, token/fork settings, runner groups, rules/environment, platform paved road or audit retention. The checkpoint lab now asks you to write one coherent standard and prove that it accepts and rejects workflows for the right reasons.

Knowledge check

Official references and version notes

• Enforcing policies for GitHub Actions in your enterprise — Current enterprise policy options, selected-action rules and full-SHA enforcement.
• Managing GitHub Actions settings for a repository — Repository-level action policy, token defaults and fork settings, including inheritance limits.
• Managing access to self-hosted runners using groups — Runner-group organization/repository/workflow access and public-repository warnings.
• Reviewing the audit log for your organization — Audit-log search/export/API boundaries and retention guidance.
• Secure use reference — Least privilege, untrusted input, third-party action and runner security guidance.
• Compromised runners — Current risk model for runner compromise and untrusted workflow code.