agentic-job

Agent security is just CI security

A coding agent working on an issue is the same kind of risk as a build script from a pull request or a dependency's install hook: code you did not write, steered by text you did not write, on a machine that holds your tokens. agentic-job gives all three the same defence.

A sandboxed agent

The agent runs as an ordinary unprivileged user on a runner that has lost sudo and the container daemon, in a job that holds no secret but a run token, and no token that can write to the forge. The sandbox

Checked safe outputs, applied elsewhere

The agent can only leave a file of requests. A second job checks them on a clean machine and a third applies them; no job with a write token runs anything the agent wrote. Safe outputs

secure-host for any job

One step takes sudo and the container daemon away from every later step of a job, then probes that it did and fails the job if not. It needs no agent. Securing the CI host

Bounded tokens

The agent's forge token is read only and expires with the job. The model key stays with a credential broker on another machine, which hands each run a token good for that run alone. Which tokens reach what

Try it in a workflow

Any job can harden its runner with one step, as in the README; pin COMMIT to a commit you have read. Everything that needs root goes before it.

jobs:
  build:
    runs-on: ubuntu-26.04
    steps:
      - run: sudo apt-get install -y libfoo-dev   # root: before the step
      - uses: actions/checkout@v7
      - uses: cgwalters-forge/actions/secure-host@COMMIT
      - run: make check                           # runner's user, no sudo

To run an agent, example.yml is a whole caller of the reusable workflow to copy, with the scripted agent, which needs no model.

Compared with GitHub Agentic Workflows

For most people gh-aw is the right choice today: it has far more output types and triggers, and memory across runs. agentic-job checks and applies gh-aw's safe outputs with gh-aw's own pinned code, but runs the agent as an unprivileged user on a hardened runner rather than in a container, so the work can use containers, /dev/kvm and user namespaces, and you write ordinary workflow YAML with no compiler. The comparison lists the differences item by item.

Read more

• Quickstart: a first run with the scripted agent, no model needed.
• Running it on GitHub: the reusable workflow, its jobs and tokens.
• Inference through a proxy: reaching a model without holding its key.