Run a GitHub Actions agentic workflow, then check leaks

Boundary behavior is the test

You are deciding whether a coding agent can run in GitHub Actions on real work. The agent can be competent and still leak a secret if the boundary is sloppy. The useful test is whether the compiled artifact, the permissions, and the failure path stay inside the boundary you declared, even when the agent is only drafting a triage note or summarizing an issue.

GitHub Agentic Workflows reached general availability on October 28, 2026. The GA release added Actions Runner Controller, Docker-in-Docker, additional engine and model-routing options, spending forecasts, and extra isolation choices. Treat the new options as extra knobs, not extra trust. Those options widen the surface, so the preflight below keeps the surface small enough to inspect.

Five checks keep the surface small

Run these before the workflow touches real work. Each step should take a minute if the setup is honest.

• Pin the compiled artifact. The gh-aw compiler verifies the workflow source and writes a lockfile with a .lock.yml extension. Commit that file, and make the workflow run from it. If the runner can pull a newer source file, the artifact you reviewed is not the artifact that ran.
• Confirm the agent job is read-only. By default, GitHub Agentic Workflows agents operate read-only and run in a sandboxed container protected by the Agent Workflow Firewall. Set the agent job to read-only and verify it still runs in that default sandbox. A write scope on the agent job is a red flag unless you can name the exact output it needs.
• Scope each output job. Give each output job only the permission it needs to write its artifact. If a job can update a branch, a package, or touch a secret, ask what it would do if the agent was wrong.
• Feed malformed and prompt-injection inputs. Run the workflow against a malformed issue body and an issue that tells the agent to ignore its instructions. The pass is a bounded failure: no write, no escalation, no secret in the log.
• Pin a reviewed version. Check the installed gh-aw version and confirm it is current and reviewed. Versions 0.83.3 through 0.85.3 of the GitHub Agentic Workflows source repository were retired after a security vulnerability. A pinned old version is a leak you can schedule.

The list is short because the failure modes are short. If the artifact is mutable, the permission is broad, or the input path is untested, the workflow is not ready for real work.

A one-off run is not enough

Do not run the checks once and call the workflow safe. Put the test inputs in a fixture directory, name the expected failure before the run, and make the pipeline fail when the agent writes outside the expected output path. A one-off manual run is a conversation. A repeatable check is a test.

For a triage workflow, the expected write is usually narrow: a label, a comment, or a handoff. That makes the permission check easier, because the output job should only need the minimum scope to produce that artifact. If the agent can do more than the workflow needs, the extra capability is a future incident with a better interface.

Keep the preflight close to the workflow definition. Rerun the checks after an artifact change, a version change, or a new output permission. If a change lands without a rerun, keep the workflow out of real work.

License and availability are part of the boundary

GitHub Agentic Workflows is available on github.com to GitHub Free, Team, and Enterprise users. The same preflight applies whether you are testing in a small repo or running it across an organization. Do not skip it because the environment feels disposable.

If the workflow uses the default GitHub Copilot CLI engine, a Copilot license is required. Put that in the same preflight as permissions, because a missing access path is a failure mode too. The agent should fail visibly, not silently fall back to something you did not review.