Authority is part of the diff

Agent repositories spread authority across several files. An OpenAPI document can add a write endpoint. An MCP export can broaden scope. A prompt can drop confirmation. A workflow can grant a stronger token. Each edit may look routine, especially when a coding agent created the patch and the reviewer is checking whether it works.

Shipgate reads a shipgate.yaml manifest and declared local sources. Its adapters cover MCP exports, OpenAPI 3.x, OpenAI Agents SDK, Anthropic Messages API artifacts, Google ADK, LangChain and LangGraph, CrewAI, n8n and Conductor workflows, OpenAI API artifacts, Codex repository configuration, and Codex plugin packages. Framework adapters parse static files and Python AST. They do not import the framework or execute user modules.

It writes Markdown and JSON reports, a pull-request comment, capability locks and diffs, plus SARIF for code-scanning systems. One field remains authoritative for release gating: report.json.release_decision.decision.

{
  "decision": "review_required"
}

The four decisions are passed, review_required, insufficient_evidence, and blocked. Other summaries are projections or reviewer context. With one authoritative field, downstream automation does not have to reconcile several status views before deciding whether a change may ship.

Missing visibility should not become approval

A tool factory may assemble actions at runtime from configuration, plugins, or remote data. Static analysis cannot reliably enumerate that surface. Shipgate returns insufficient_evidence and routes the change to a person instead of treating missing visibility as approval.

That restraint costs attention. A noisy gate is soon ignored. The repository's published real-history baseline reports that both pull requests labeled must_block went to human review rather than blocked, leaving blocked_recall at 0.0. Four of 14 safe pull requests were also escalated, a 0.286 benign escalation rate. The maintainers say much of that came from cold-start, whole-repository measurement on large projects.

Those numbers limit what can be concluded. Shipgate is beta. A passed result means the declared static surface contained no active blocker or review signal. It does not mean the runtime is safe, the manifest is complete, or the behavior has been tested.

The boundary resembles the one discussed in AgentJail. Runtime controls constrain a call when it happens. Behavioral evals test whether an agent chooses suitable actions in sampled scenarios. A merge-time scanner checks whether a patch changed the authority the team meant to grant. None answers the other two questions.

The agent cannot approve its own authority

The coding agent adding a tool may also be able to edit the manifest, workflow, baseline, or policy that reviews it. If it can weaken the gate and approve the weaker configuration in the same workspace, deterministic output offers little protection.

Shipgate classifies weakened CI and manifest policy as trust-root changes requiring human review. Its contract lets a coding agent prepare and publish the change for review, but denies self-approval of authority-bearing gaps. An optional signed-authorization path keeps the private key, human authentication, and signing operation outside Shipgate and the evaluated workspace. The documentation also notes that content-addressed receipts detect changed bytes but do not authenticate provenance supplied by the agent.

The operational consequence is simple: the agent must not be able to rewrite the gate's inputs, policy, and enforcement path, then cite the resulting deterministic verdict as independent review.

Begin with an advisory result

The project documentation recommends starting with the pinned ThreeMoonsLab/[email protected] GitHub Action in advisory mode. Teams should review the baseline and expected failures before enforcing stricter policy. The Action never fetches, so checkout needs fetch-depth: 0 to compare a pull request with its base.

agents-shipgate verify \
  --workspace . \
  --config shipgate.yaml \
  --base origin/main \
  --head HEAD \
  --ci-mode advisory \
  --format json

A team can then fail only on blocked, require can_merge_without_human == true, or fail when evidence is insufficient. Blocking only explicit critical findings preserves flow but allows unresolved review states. Requiring a clean verdict is safer and noisier. Failing on missing evidence suits high-authority agents, though it may be impractical while a team is still inventorying tools.

The PyPI package page states the limit plainly: undeclared or statically undiscoverable tools are not scanned. A successful run over an incomplete manifest remains incomplete.

Before enforcing the verdict, reviewers should compare the generated capability lock with the inventory they expect. Check whether every production-facing tool source is declared, whether broad wildcard scopes have a narrower alternative, and whether write actions name their approval and idempotency controls. Then make the CI response explicit. A finding routed to human review should identify the person or team with authority to accept it, rather than become a label that waits indefinitely on the pull request.

Keep the report and capability diff with the release record. If a later incident involves a tool that Shipgate never saw, the archived inputs distinguish a scanner miss from an incomplete manifest. That distinction will not undo the incident, but it tells the team whether to improve extraction, inventory, or both.

Our NIST AI cybersecurity guide review argued that "Not addressed" can be more honest than a fabricated control claim. insufficient_evidence applies the same discipline to a pull request. It records exactly why the reviewer should stop, without pretending static analysis saw the runtime.