Your coding agent changed what your AI agent can do.
Agents Shipgate tells you whether it can merge.

agents-shipgate is an open-source CLI and GitHub Action that verifies AI-generated agent capability changes and returns a deterministic merge verdict. The display name is Agents Shipgate; the package, CLI, repo, and action name are agents-shipgate.

Run it when a PR changes agent tools, MCP exports, OpenAPI specs, prompts, permissions, approval policies, confirmation policies, CI gates, or shipgate.yaml. Existing opted-in repos can run it on every PR.

The wire signal is still release_decision.decision. Public verdict labels are mergeable, human_review_required, insufficient_evidence, and blocked.

Agents Shipgate checks declared tools, schemas, scopes, approval policies, side effects, idempotency evidence, prompt/policy surfaces, trust-root files, baselines, and suppressions. It asks whether the capability change has enough release evidence to merge.

Evals validate behavior on inputs you wrote. Agents Shipgate validates the static release artifact — manifest, tool schemas, scopes, and policies — without running the model. Use both.

Observability records what happened at runtime, and guardrails enforce access at runtime. Agents Shipgate runs earlier: it turns declared tool surfaces into static release-review evidence before promotion.

No. The verifier is static by default: no agent execution, no user-code import by default, no tool calls, no LLM calls, no MCP server connections, no verifier network calls by default, and no verifier telemetry by default.

It supports MCP exports, OpenAPI 3.x specs, OpenAI Agents SDK Python entrypoints, Anthropic Messages API artifacts, Google ADK Python and YAML config, LangChain/LangGraph, CrewAI, OpenAI API artifacts, Codex repo config (.codex/config.toml, hooks.json), Codex plugin packages, and n8n workflow artifacts.

The PR verifier writes agents-shipgate-reports/verifier.json, report.json, and pr-comment.md. SARIF remains available through the GitHub Action or output format configuration.

This site advertises the published v0.14.0 release. Install from PyPI with pipx install agents-shipgate and pin GitHub Actions to ThreeMoonsLab/agents-shipgate@v0.14.0.

Add ThreeMoonsLab/agents-shipgate@v0.14.0 to a pull-request workflow with fetch-depth: 0, diff_base: target, pr_comment: "true", and ci_mode: advisory.

No. Agents Shipgate is not a safety certification, runtime gateway, or behavioral eval. It produces deterministic findings from tool definitions, schemas, scopes, and declared policies so release owners have evidence to review.

Read release_decision.decision from report.json or the same block projected into verifier.json. Values are passed, blocked, review_required, and insufficient_evidence.

They may install the workflow, add ignored local report directories, run verify, summarize artifacts, and apply high-confidence mechanical patches. They must not assert approval, confirmation, idempotency, broad-scope safety, prohibited-action enforcement, or runtime-trace proof without human review.

A release gate is a deterministic CI check that runs on every pull request and fails the build when the agent's release artifact contains unsafe state. For AI agents specifically, the release gate inspects the manifest, tool surface declarations, scopes, and policies — not the model itself or runtime behavior. Agents Shipgate fits this slot.

shipgate.yaml is a checked-in YAML file that declares an agent's release context: tool sources (MCP, OpenAPI, SDK), permissions, approval and idempotency policies, risk overrides, and CI settings. Agents Shipgate reads it as the single source of truth for what should be reviewed at release time. The minimal valid manifest requires version, project, agent, and environment blocks plus at least one entry under tool_sources.

A Tool-Use Readiness Report is the deterministic output of an agents-shipgate scan. It contains a release decision with passed, blocked, review_required, and insufficient_evidence, a finding list with severities and recommended remediation, and seven dimensions of evidence coverage. Written as Markdown for human review, JSON for tools and coding agents, and SARIF for GitHub code scanning.

Blast radius is the seventh dimension of tool-use readiness. It asks: if a tool fires unexpectedly, how bounded is the damage? Evidence includes a declared owner so the right team gets paged, an enumerated list of prohibited actions in agent.prohibited_actions, and resource-scope bounds (per-tenant, per-customer, per-resource-prefix). High-risk tools without these bounds get blast-radius findings.

Unit tests verify specific behaviors on inputs the team wrote — the model returns the right tool call on this input, a helper processes this fixture correctly. Agents Shipgate verifies the static release artifact: which tools are exposed, what schemas they accept, what policies gate them. Unit tests cannot catch a write tool shipping without an approval policy; the release gate cannot catch a behavior regression on a curated test. Use both at different stages of CI.

Yes. Agents Shipgate supports OpenAI Agents SDK, Anthropic Messages API, Google ADK (Python and YAML), LangChain/LangGraph, CrewAI, MCP exports, OpenAPI 3.x specs, OpenAI API artifacts, Codex plugins, and n8n workflows. Static AST extraction means no code import or execution. The seven dimensions of tool-use readiness apply regardless of framework — adapters normalize each framework's tool declarations into the same review surface.

Add the GitHub Action to your pull-request workflow in advisory mode. It runs on every PR, scans the manifest plus tool sources, and posts findings as a PR comment without failing the build. Triage and baseline existing findings, then switch to strict mode (fail_on: critical,high) to block net-new gaps. Typical CI order: dependency install, release-readiness scan, unit tests, eval suite, deploy. See the full CI/CD tutorial.

Use advisory mode when first adopting Agents Shipgate or when you have a backlog of findings to triage — the scan runs and reports but never fails the build. Switch to strict mode after you have saved a baseline (agents-shipgate baseline save) and reviewed the existing findings. Strict mode fails only on net-new findings above critical or high severity. The adoption path is: advisory, then review and baseline, then strict plus baseline.

It is the protocol beneath the verdict: eight contracts — trigger, capability change, merge verdict, repair, forbidden action, human authority, trust root, and attestation — each mapped to the artifact that implements it. release_decision.decision is the only gate; every agent-facing field is a deterministic projection of it. A coding agent reads agent-handoff.json first (gate.merge_verdict, then controller); verifier.json.agent_controller is the authoritative substrate for whether it may continue, must repair, or must stop for a human. The named contract and the agent_controller projection are in the published v0.14.0 release. See the contract map.

agents-shipgate attest derives a deterministic, local attestation from verifier.json and report.json: the base/head SHAs, the merge verdict, the capability delta, the declared human-acknowledgement state, a policy-snapshot hash, and content hashes of every verify artifact. It is content-addressed, does not gate, and leaves a durable record of what shipped under which verdict. Output: attestation.json. It is in the published v0.14.0 release, alongside registry ingest/registry query for a local capability-release ledger.

Yes. The Codex plugin is generally available. Run codex plugin marketplace add ThreeMoonsLab/agents-shipgate, then invoke $agents-shipgate in a thread to run verify, init, and report-reading workflows. The plugin supplies the Codex workflows; install or upgrade the CLI with pipx install agents-shipgate in the environment where Codex runs commands.

shipgate check --agent codex|claude-code|cursor --workspace . --format codex-boundary-json is the canonical one-command path for a coding agent. It emits one stdout JSON object with schema_version: "shipgate.codex_boundary_result/v1"; the agent switches on decision, completion_allowed, must_stop, first_next_action, human_review, repair, and policy (which includes policy_snapshot_sha256). The former agent_result_v1 contract and its --format agent-json flag were removed in v0.14.0. The optional MCP server mode exposes the same verdict as a read-only shipgate.check tool that accepts caller-provided diff text.

Run agents-shipgate init --workspace . --write --claude-code once. It writes the CLAUDE.md managed block, the auto-discoverable .claude/skills/agents-shipgate/ skill, a verify alias in Makefile or package.json scripts, and Claude Code hooks that run a cheap trigger check after edits and the full verifier at Stop. Inside Claude Code, agent mode auto-enables (the harness exports CLAUDECODE=1), so a zero-flag agents-shipgate verify prints the full verifier artifact as JSON on stdout. CI stays authoritative; the hooks are the local feedback loop.

agents-shipgate audit --host --save-baseline records the current coding-agent host grants — MCP servers, Claude Code permission rules and hooks, workflow scopes, Codex config presence — as an acknowledged baseline. audit --host --drift then deterministically diffs current grants against it, naming authority-broadening shapes such as a new or changed MCP server, a wildcard allow added, a deny or ask rule removed, or a workflow write scope gained. Advisory by default; --fail-on-drift exits 20 for scheduled CI gates. It catches authority changes that land outside PR review, where diff-time checks cannot see them.