How to Fix a Blocked Endpoint in Your Workflow

If your GitHub Actions build fails because Harden-Runner blocked an outbound network call, here's how to resolve it.

Why This Happened

Your workflow has Harden-Runner configured with egress-policy: block and a list of allowed-endpoints. The workflow tried to reach an endpoint (domain + port) that isn't on the allowed list, so Harden-Runner blocked the connection to prevent potential data exfiltration.

This is Harden-Runner working as intended. The fix depends on whether the blocked endpoint is legitimate.

Step 1: Find the Blocked Endpoint

Open the failed workflow run in GitHub. In the job summary, click the Harden-Runner insights link to open the Insights page.

Go to the Network Events tab. Look for events with a Blocked status. Note the destination endpoint (e.g., registry.npmjs.org:443) and which workflow step triggered the call.

Step 2: Determine if It's Legitimate

Ask yourself:

• Does this endpoint belong to a known service? (Package registry, cloud provider, CDN, API)
• Does the step that triggered it logically need this connection? (A dependency installation step calling npm registry is expected; a test step calling an unknown external API is not)
• Did you recently update a dependency or add a new GitHub Action that might introduce new endpoints?

If you can explain the endpoint, it's safe to add it to the allowed list.

Step 3: Add the Endpoint

Open your workflow YAML file and add the endpoint to the allowed-endpoints list:

- uses: step-security/harden-runner@v2
  with:
    egress-policy: block
    allowed-endpoints: >
      github.com:443
      api.github.com:443
      registry.npmjs.org:443
      <your-new-endpoint.com:443>

Commit, push, and re-run the workflow.

Alternatively, if your organization uses Policy Store, ask your security team to add the endpoint there. This avoids modifying the workflow YAML directly.

Step 4: If It Looks Suspicious

If you can't explain why the endpoint is being called:

• Do not add it to the allowed list
• Check if a recent dependency update introduced the call
• Notify your security team
• Consider reverting the most recent dependency changes and re-running the workflow to see if the blocked call disappears

Prevention

When a new dependency or action is added to a workflow, run it in egress-policy: audit mode first to discover any new endpoints before switching to block mode. Check the Recommended Policy tab on the Insights page for an updated endpoint list.