v2 用 tenant-id 取代 v1 的 org-id 和 workflow-key，从 v1 迁移需改配置；action.yml 只是 Marketplace 入口，实际逻辑在 agent-safe-pipeline 仓库的 govern/ 下，运行时会下载并校验 release 二进制；连不上 Decionis 会直接拒绝执行，需保证 runner 能访问服务。
govern
decionisApache-2.0活跃维护在部署、迁移、基础设施变更或 AI Agent 执行动作前，先向 Decionis 获取一次裁决并生成带签名的决策档案，可接入 GitHub Actions、GitLab CI、Jenkins，支持影子或强制模式。
Govern: one Decionis verdict before a workflow step runs — a deploy, a migration, an infrastructure change, an agent's action — with a signed Decision Dossier of it. GitHub Actions, GitLab CI, Jenkins; shadow or enforce; no local policy engine.
v2.0.0发布于 2026-09-21 20:35 UTC247star1fork同步于 2026-11-07 07:32 UTC
- 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 硬件要求按 README 说明
README 未说明
在工作流步骤执行前向 Decionis 取一次裁决，并留下签名的决策档案
在部署、迁移、基础设施变更或 AI Agent 执行动作前，先向 Decionis 获取一次裁决并生成带签名的决策档案，可接入 GitHub Actions、GitLab CI、Jenkins，支持影子或强制模式。
核心能力
- 步骤先声明执行意图，只有拿到一次性授权的 ALLOW 才真正执行命令
- BLOCK 直接终止且命令不启动，ESCALATE 可挂起等待人工审批
- shadow 模式立即执行命令并旁路记录裁决，不会让构建失败
- 无法连上 Decionis 即视为拒绝，不在本地做任何策略判定
- 支持 GitHub Actions、GitLab CI、Jenkins 等任意 runner
容易踩的坑
内容由模型根据 README 生成，可能不完整或不准确，以官方文档为准。看原文 README
- v2.0.0v2.0.0 — Govern, the workflow gate最新正式版2026-09-21 · 2026-09-21 20:35 UTC
Govern v2 — one verdict before a workflow step runs
uses: decionis/govern@v2is now the Marketplace address of Govern, the workflow gate, whose source, tests and releases live in decionis/agent-safe-pipeline undergovern/. This action carries the listing's metadata and delegates every input and output to the gate at a pinned commit, which downloads the release binary its commit names and verifies it before running.- uses: decionis/govern@v2 with: api-key: ${{ secrets.DECIONIS_API_KEY }} tenant-id: ${{ vars.DECIONIS_TENANT_ID }} action: production-deploy run: ./scripts/deploy.sh # runs only on an ALLOW whose grant this step claimedThe step becomes an execution intent, Decionis decides on exactly that intent, the command runs only on an
ALLOWwhose single-use grant the step claimed first, anESCALATEcan hold it while Decionis orchestrates a person's approval, aBLOCKnever starts it, and what happened is finalized into a signed Decision Dossier.mode: shadowstarts the command at once and records the verdict beside it, never failing a build. Nothing is decided locally.Changed from v1: the action speaks the execution contract (
enforce-and-bind, claim, finalize) instead of the evaluate-decision API;tenant-idreplacesorg-idandworkflow-key;commentreplacescomment-pr; there is no local policy engine (policy-enforce,local-eval) and no execution grant handed to the command (request-grant,grant-audience) — the grant never leaves the gate. The same binary gates GitLab CI, Jenkins and any other runner;govern initwrites a repository's starter files. Keys and workspaces are the same.@v1keeps resolving to the earlier action (v1.9.3).- Every input, output and exit code: the gate's README
- What one governed step is: docs/govern.md
- The gate's own release, with the binaries this action downloads: agent-safe-pipeline v0.3.3
- v1.9.32026-08-13 · 2026-08-13 13:10 UTC
查看更新说明
Full Changelog: https://github.com/decionis/govern/compare/v1.9.2...v1.9.3
- v1.9.0v1.9.0 — local policy engine, speculative shadow mode, installer CLI2026-07-05 · 2026-07-05 06:12 UTC
查看更新说明
⚡ Performance
- Local policy engine: the committed ```decionis rules block in DECIONIS_POLICY.md is evaluated in-process in microseconds, faithfully mirroring the platform evaluator. Deterministic allow/block verdicts act immediately; the API call becomes an async notarization off the critical path (signed dossiers, verify URLs, and badges still arrive). New
local-evalinput:auto(default) /strict(fully offline) /off(v1.8 behavior). - Speculative shadow mode:
runcommands start immediately while the verdict resolves in the background — the gate adds ~zero latency. The step's exit code is always the command's; evaluation failures are notices. Shadow can no longer fail a build for any reason, and unconfigured gates (no secrets yet) are inert. - Every run logs a
Decionis timing —line so the speedups are visible.
🔧 Correctness
- API outcome normalization (
APPROVE→allow,REJECT→block,REQUIRE_REVIEW→review) — enforce-moderungating andfail-onnow work against the live API vocabulary. - New outputs:
decision-source(local/api) andverdict-mismatch(local verdict vs notarizing API verdict, with a::warning::). - Example policies and the installer template set explicit rule
priorityand"domain": "*"so committed policies actually fire.
🚀 Onboarding
- install.sh ships in the repo:
curl -fsSL https://decionis.com/govern/install.sh | sh -s -- --pr --injectwrites a shadow workflow + starter policy, injects observe-only (continue-on-error) gate steps into existing workflows, and opens the onboarding PR. - Badge/verify URLs pin the policy revision:
&policy=sha256:<hash>.
✅ Compatibility
All existing inputs/outputs unchanged; repos without a rules block see no decision-flow change. 143 tests, including end-to-end timing proofs against a mock API.
Full diff: https://github.com/decionis/govern/compare/v1.8.8...v1.9.0
- Local policy engine: the committed ```decionis rules block in DECIONIS_POLICY.md is evaluated in-process in microseconds, faithfully mirroring the platform evaluator. Deterministic allow/block verdicts act immediately; the API call becomes an async notarization off the critical path (signed dossiers, verify URLs, and badges still arrive). New
- v1.8.82026-06-02 · 2026-06-02 00:54 UTC
查看更新说明
Decionis Govern Action v1.8.8. Usage:
uses: decionis/govern@v1. See README for inputs. - v1.8.72026-06-02 · 2026-06-02 00:32 UTC
查看更新说明
Decionis Govern Action v1.8.7. Usage:
uses: decionis/govern@v1. See README for inputs.
用户点评
登录用户的真实使用记录，可按版本和硬件筛选共 0 条
还没有人点评。第一个说出真实体验的人最有价值。
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 applyon 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 aDECIONIS_POLICY.mdand 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