GitHub Actions is a high-leverage place to let agents propose changes, run tests, and open pull requests, but it is also a privileged execution surface where a mis-scoped token or unsafe workflow can turn into repo write access, secret exposure, or supply-chain drift. For enterprise agent security, you want permissioned execution: policy-as-code that constrains what an agent may do in Actions, independent of what it says in a prompt.
Claw EA runs OpenClaw as the baseline agent runtime and uses Claw Bureau primitives to make Actions runs auditable and bounded: a WPC that defines allowed operations, a CST that carries the intended scope and can be policy-hash pinned, plus gateway receipts and a proof bundle so you can verify what model calls happened and under what constraints. GitHub Actions connectivity is implementable via official API with enterprise buildout controls, not a native connector.
Step-by-step runbook
This runbook assumes you want an agent to interact with GitHub Actions without giving it a standing “repo admin” capability. The goal is to keep authorization machine-enforced, then make every run reviewable after the fact.
-
Define the Work Policy Contract. Create a WPC that enumerates allowed repositories, allowed workflow files (or workflow names), and what “write” means (for example, only open PRs, never push directly to default branch). Store the signed, hash-addressed WPC in the WPC registry, then plan to fetch and verify it at execution time.
-
Choose the minimal GitHub auth footprint. Decide whether your enterprise buildout will use a GitHub App, OAuth, or a service account pattern, and map it to least-privilege repository permissions. If your agent can trigger workflows, keep write and admin actions behind WPC approval gates and explicit least-privilege auth scopes.
-
Issue a job-scoped CST. At the start of an agent job, request a CST from clawscope with a short TTL and a scope hash that matches the WPC intent. If you need stronger coupling, enable optional policy hash pinning so the CST is only valid for the specific WPC hash your workflow expects.
-
Route model calls through clawproxy. For any model-assisted step (triage, code review, test failure summarization), route the model traffic through clawproxy so gateway receipts are emitted. This makes model usage verifiable and prevents “invisible” model calls outside the approved execution path.
-
Execute Actions operations via official API. Use the GitHub REST API to dispatch workflows, check run status, and fetch logs and artifacts, but only for targets allowed by the WPC. Treat every “write” operation (dispatch, approve, rerun, cancel, or create PR) as a policy decision, not a prompt decision.
-
Generate a proof bundle. At the end of the job, emit a proof bundle that binds together the CST scope hash, the WPC hash, gateway receipts, and job metadata (repo, workflow, commit, runner identity as observed). Store the proof bundle for audit, and optionally publish a Trust Pulse for easy viewing.
Threat model
GitHub Actions is powerful because it can run arbitrary steps in a runner and it often has access to secrets and repo permissions. When an agent is involved, you should assume it will eventually encounter prompt injection, malicious PR content, or ambiguous instructions that cause overreach unless the execution layer is permissioned.
| Threat | What happens | Control |
|---|---|---|
| Workflow modification to gain privileges | An agent edits a workflow to add extra permissions, exfiltrate secrets, or run unreviewed scripts, then triggers it. | WPC restricts which workflow files may be changed and forbids direct pushes; “write” paths require WPC approval gates. Use short-lived CST and pin it to the WPC hash so a different policy cannot be swapped in mid-run. |
| Secret leakage through logs or artifacts | Actions logs or uploaded artifacts capture tokens, environment variables, or private code, then get copied into issues or external systems. | Keep Actions permissions minimal and avoid giving the agent raw secrets when possible; treat logs as sensitive and restrict who can read them. Use proof bundles for audit rather than copying full logs into chat transcripts. |
| Token overreach (repo-wide write when only PR is needed) | A single token can write to many repos or bypass review by pushing directly to protected branches. | Use least-privilege GitHub permissions and restrict targets in WPC to a repo allowlist; bind the CST to the job and WPC so replay across repos is blocked by marketplace anti-replay binding (job-scoped CST binding). |
| Supply-chain compromise through unpinned actions | A workflow uses a third-party action by a moving tag, and a compromised update runs under your permissions. | Enforce an internal policy that actions are pinned to commit SHAs and reviewed; have the WPC require pinned references for any workflow the agent may trigger or modify. |
| Prompt-only controls get bypassed | The agent “agrees” to constraints but still takes a dangerous path when it encounters a tricky failure mode or conflicting instruction. | Permission the execution layer with WPC and CST so the system rejects disallowed API calls even if the prompt tries to override. Use OpenClaw tool policy and sandboxing to reduce local blast radius for any auxiliary tooling. |
Policy-as-code example
This example shows the shape of a WPC you might use to constrain GitHub Actions usage for an agent that is allowed to run CI and open PRs, but not push to default branches or manage secrets. Treat it as a compact “deny by default” artifact that your enterprise buildout enforces around GitHub API calls.
{
"wpc_version": "1",
"policy_name": "github-actions-permissioned-agent-ci",
"targets": {
"github": {
"org_allowlist": ["acme"],
"repo_allowlist": ["acme/payment-api", "acme/webapp"],
"workflow_allowlist": [".github/workflows/ci.yml", ".github/workflows/test.yml"]
}
},
"actions": {
"workflow_dispatch": { "allowed": true },
"rerun_failed_jobs": { "allowed": true },
"cancel_run": { "allowed": true },
"create_pull_request": { "allowed": true },
"push_to_default_branch": { "allowed": false },
"edit_workflow_files": {
"allowed": true,
"requires_review": true,
"require_pinned_actions": true
},
"secrets_read_or_write": { "allowed": false }
},
"auth": {
"require_least_privilege_scopes": true,
"max_token_ttl_seconds": 900
},
"attestation": {
"require_gateway_receipts_for_model_calls": true,
"emit_proof_bundle": true
}
}
Operationally: your GitHub Actions integration code checks this WPC before calling the GitHub API, and the job CST is minted to match the intent. If the agent tries to dispatch an unlisted workflow or touch a disallowed repo, the call is denied even if the prompt is persuasive.
What proof do you get?
For model-assisted CI runs, clawproxy emits gateway receipts for model calls, including what was requested and the signed receipt metadata needed for verification. Those receipts are bundled with job context into a proof bundle, which you can keep with the run artifacts or hand to an audit pipeline.
The proof bundle is designed to answer concrete questions: which WPC hash governed the run, which CST scope hash was used, and which model calls occurred under clawproxy. If you publish it, a Trust Pulse can store the artifact for later viewing and comparison across runs.
Rollback posture
Rollbacks should assume two things: agents will sometimes make undesirable changes, and long-lived credentials are a liability. Your response plan should be able to stop new actions quickly, then produce evidence for what happened without relying on a human remembering the timeline.
| Action | Safe rollback | Evidence |
|---|---|---|
| Suspected agent overreach in GitHub | Disable the enterprise buildout path that issues CST for GitHub Actions jobs, then revoke or expire job CST quickly via clawscope. Freeze agent write capabilities by updating the WPC to deny write operations and requiring review. | Proof bundle showing WPC hash, CST scope hash, and gateway receipts for model calls involved in the run. |
| Bad workflow change merged | Revert the workflow file change in a PR, and temporarily block any agent from editing workflows by updating WPC. Review GitHub Actions permission settings and pin third-party actions to SHAs. | Git history plus proof bundle linking the agent job to the commit and the policy used at the time. |
| Secret suspected exposed in logs | Rotate the secret, invalidate any derived tokens, and restrict log access while you investigate. Update WPC to block steps that output environment dumps and require redaction discipline in the workflow. | Proof bundle for the job, plus GitHub run logs retained under your normal controls (do not copy them into chat). |
| Need to validate what the model saw | Reconstruct the model call sequence from gateway receipts rather than relying on the agent transcript. If necessary, rerun the job with a stricter WPC and compare outputs. | Gateway receipts (from clawproxy) and the proof bundle integrity checks. |
If you need network egress allowlists or automatic cost budget enforcement, those are optional or can be implemented, but you should not depend on them as your primary guardrail. Start with permissioned execution via WPC plus short-lived CST, then add infrastructure controls as your deployment matures.
FAQ
Is this a native GitHub Actions connector in Claw EA today?
No. GitHub Actions can be connected via official API with enterprise buildout controls, and you should treat it as an integration project with explicit security review rather than a toggle.
Why is prompt-only safety not enough for GitHub Actions?
Prompts can be ignored, misunderstood, or overridden by content in PRs, logs, or issues. Policy-as-code makes the execution layer reject disallowed API calls even if the agent attempts them.
What is the minimum set of Claw Bureau primitives I should use?
Use a WPC to define allowed Actions operations and targets, a CST to enforce job-scoped access with a scope hash (optionally pinned to the WPC hash), and clawproxy gateway receipts so model calls are provable. Wrap the whole run into a proof bundle for audit and verification.
How does anti-replay work for an Actions-triggering agent?
Use marketplace anti-replay binding (job-scoped CST binding) so a CST minted for one job cannot be reused for another job or target. Pair that with WPC allowlists so even a valid token cannot be used outside the intended repo or workflow set.
Can I run the agent locally and still do this securely?
You can, but assume local shell and filesystem access increase risk. Use OpenClaw sandboxing and tool policy to constrain local tools, and keep GitHub permissions and CST TTLs tight so local compromise does not become persistent repo compromise.