Decionis Govern

One verdict before a workflow step runs — a deploy, a migration, an infrastructure change, an agent's action — with a signed Decision Dossier of it.

- uses: decionis/govern@v2
  with:
    api-key: ${{ secrets.DECIONIS_API_KEY }}
    tenant-id: ${{ vars.DECIONIS_TENANT_ID }}
    action: production-deploy
    environment: production
    run: ./scripts/deploy.sh # runs only on an ALLOW whose grant this step claimed

The step becomes an execution intent, Decionis decides on exactly that intent, the command runs only on an ALLOW whose single-use grant the step claimed first, and what happened is finalized into a signed Decision Dossier. BLOCK ends the step with the command never started; ESCALATE can hold it while Decionis orchestrates a person's approval; mode: shadow starts the command at once and records the verdict beside it, never failing a build. Nothing is decided locally: a Decionis that cannot be reached is a refusal, and the command does not run.

Where the gate lives

This repository is the Marketplace address. The gate itself — one Go binary for GitHub Actions, GitLab CI, Jenkins and any other runner, speaking the Decionis execution contract the AgentSafe runtime speaks — lives in decionis/agent-safe-pipeline under govern/, with its tests, its releases and its page, docs/govern.md. action.yml here carries the listing's metadata and delegates every input and output to that action at a pinned commit, which downloads the release binary its commit names and verifies it before running.

• Every input, output, exit code and runner surface: the gate's README.
• The recipes in examples/ are copies of the gate's: a deploy, terraform apply on the plan's blast radius, a release held for the release manager, shadow comments on every pull request, agent-authored pull requests, Dependabot auto-merge.
• Starting a repository: install the binary and run govern init, which writes a shadow-mode workflow and a DECIONIS_POLICY.md and touches nothing else.

v1

uses: decionis/govern@v1 is the earlier node20 action, which spoke the evaluate-decision API with org-id and workflow-key inputs and evaluated a rules block locally. It stays where its tags point (v1.9.3) and is not developed further; v2 speaks the execution contract, has no local policy engine, and takes tenant-id in place of org-id and workflow-key. Keys and workspaces are the same.

Built by Decionis · Apache-2.0