Усильте агента
Собственная команда издателя. Не эндпоинт PlugMCP.
Host a copy with our keys and logs.
uvx release-gate==0.8.4У Claude Code нет ссылки для установки локальной команды. Скопируйте команду ниже и выполните её в терминале.
RG_MCP_ALLOWED_ROOTS=<value> claude mcp add io.github.vamsisudhakaran1-release-gate -- uvx release-gate==0.8.4Выполните в терминале.
{ "mcpServers": { "io.github.vamsisudhakaran1-release-gate": { "command": "uvx", "args": [ "release-gate==0.8.4" ], "env": { "RG_MCP_ALLOWED_ROOTS": "<value>" } } }}claude_desktop_config.json
Удалённый URL или команда на вашем компьютере? Чем различаются два способа установки
Запустить на PlugMCP
A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.
ЗапускОт издателя
The independent admission controller for AI systems.
Release-Gate combines code-level agent risk, external evaluations, runtime traces, governance evidence, verification results and human approvals into an auditable PROMOTE / HOLD / BLOCK decision, without requiring teams to replace the tools that produced the evidence.
A PROMOTE means the candidate meets the declared release policy, with the evidence and the gaps the decision lists. It is never a statement that a release is safe.
Pre-deploy security auditor for AI agent code — the risks generic SAST misses.
code-level agent risk SARIF from your scanner, or release-gate's own ──┐
external evaluations promptfoo, ProofAgent, red teams, eval harnesses ─┤
runtime traces OpenTelemetry, Langfuse, Arize-Phoenix ───────────┤ one candidate state,
verification results tests, provers, model checkers ───────────────────┼─▶ one claim graph, ─▶ PROMOTE / HOLD / BLOCK
governance evidence governance.yaml, the pinned AIBOM ────────────────┤ one declared policy + the Admission Report
human approvals reviews and approvals of this exact candidate ───┘
Each of these answers a different question. Release-gate reads the others' results as attributed evidence and answers the last one.
It does not re-run, re-grade or replace any of them. A promptfoo result stays promptfoo's, a scanner's finding stays the scanner's, and the Admission Report says which evidence release-gate produced itself and which it read from another tool. Its own agent-code scanner is one producer among them, not the product.
Unknown is never a pass. Every decision states what was not assessed, and evidence about another state of the release does not count for this one. The decision is deterministic from the declared policy and the evidence. Models can be asked to read evidence, and their readings never decide.
flowchart LR
subgraph own["Release-gate's own checks"]
direction TB
o1["AST / taint scan"] ~~~ o2["PR diff"] ~~~ o3["governance"] ~~~ o4["trace validation"] ~~~ o5["loop sim, agent score"]
end
subgraph ext["Your tools"]
direction TB
e1["evals, red teams"] ~~~ e2["traces, SAST"] ~~~ e3["proofs, reviewers"]
end
sem["Semantic verifier<br/>bounded questions<br/>UNKNOWN on any failure"]
case["AssuranceCase<br/>claims, evidence, assumptions,<br/>contradictions, counterexamples,<br/>failed branches, coverage, independence"]
own --> case
ext --> case
sem -. "a reading, never a verdict" .-> case
case --> policy{"declared<br/>policy"} --> out["PROMOTE / HOLD / BLOCK"]
The invariant. Release-Gate may generate evidence, ingest evidence, normalize evidence, compare evidence, semantically interpret bounded evidence, and determine whether evidence satisfies policy. It must never pretend that one model, one scanner, one evaluator, one score, or one successful test establishes universal truth.
Each claim ends in one status, and the declared policy says which statuses admit:
flowchart LR
ev["the evidence<br/>on one claim"] --> claim{"a claim"}
claim -- "a valid counterexample<br/>(outranks any support)" --> c["CONTRADICTED"]
claim -- "a bound proof, or two<br/>independent groups of checks" --> e["ESTABLISHED"]
claim -- "support short of that" --> s["SUPPORTED or<br/>PARTIALLY_SUPPORTED"]
claim -- "only support about<br/>another state" --> u["UNSUPPORTED"]
claim -- "inconclusive or unreadable" --> k["UNKNOWN"]
claim -- "nothing bears on it" --> n["NOT_ASSESSED"]
No score is an input, and copies of one test from one session count once.
ARCHITECTURE maps each box to
its code. tests/test_product_invariant.py executes every clause of the
invariant.
pip install release-gate
release-gate assure your-run.jsonl # no config file, no YAML, no account
That works on an OpenTelemetry trace, a Langfuse export, a promptfoo result, or release-gate's own record format: the shape is detected, not declared. You get a verdict, what a person has to look at, and what would resolve it.
In a pipeline, the release's claims and everything the pipeline produced decide together:
release-gate assure release.jsonl --evidence evidence/ \
--methodology [email protected] --admission
Exit 0 PROMOTE, 10 HOLD, 1 BLOCK. CI templates cover GitHub Actions, GitLab, Jenkins, CircleCI and Azure Pipelines.
Release-gate's own checks are evidence too. The --json of pr, verify,
loop-sim and agent-score is read like any tool's. Here is a release that
promotes on its own, plus one trace that called a tool its governance file
forbids:
# examples/evidence/first-party/verify.json was written by
# release-gate verify governance.yaml --trace trace.json --iteration 2 --cost 0.06 --json
release-gate assure examples/agents/02-release-promoted.jsonl \
--evidence examples/evidence/first-party/verify.json \
--methodology [email protected] --admission
Decision BLOCK
BLOCK under [email protected] and rg-resolution@1: 2 blocking condition(s) established — RG-CONTRA-002 (contradictions, on rg-trace:run-2291); RG-VERIF-002 (claim_status, on rg-trace:run-2291)
The block comes from the failed trace check, not from the verifier's own
ROLLBACK. That verdict is recorded and decides nothing.
Nothing to install first: drop a run into the browser demo
— it runs this same engine, and its three sample runs are the files in
examples/assurance/, byte for byte.
Or run the worked examples. In six tools, one release, one decision, five tools report good news and the decision still holds, for the reason it prints. Five agent runs cover an OpenTelemetry trace, a promptfoo eval, a destructive migration, a research swarm, and one that promotes:
python examples/demo-admission/run_demo.py
cd examples/agents && ./run-all.sh
The product's acceptance test is one more. One enterprise release, end to end admits AI-generated code whose tools move money, over every kind of evidence. It answers each question a release owner asks, and shows that no score, model judgment or test count outvotes the counterexample it contains:
python examples/acceptance/run_acceptance.py
Two million records is not reviewable. A score over two million records is not reviewable either — it is one number standing in for a judgement nobody made.
Release-gate returns a bounded set of things that need a human, derived from which claims the decision actually rests on:
Every figure in that table is measured by the test suite, not written here by hand — a claim that drifts from the implementation fails a test.
Criticality comes from reachability in the claim graph, never from volume — a claim one agent emitted once is exactly as load-bearing as one four hundred agents discussed.
And a shorter list is not a better case. That is a property in code that cannot return anything else, because the one dangerous way to read this table is that a smaller number is a win. It can equally mean detection got worse.
This is the part most tools skip. A pass that doesn't state its own coverage is indistinguishable from a pass that never looked.
WHAT WAS ASSESSED
[ assessed] input_integrity: the input file was hashed by release-gate
[ assessed] record_mapping: 6 of 6 record(s) mapped; 0 skipped
[NOT_ASSESSED] execution_reconstruction: no execution graph was reconstructed
[NOT_ASSESSED] replication: no verification attempt names a target
[NOT_ASSESSED] adversarial_review: no verifier set out to disprove this
NOT_ASSESSED is a first-class answer, kept apart from "we looked and found
nothing" everywhere in the engine. So is UNKNOWN, and so is a refuted check as
against an unresolved one. Collapsing those is how a gap comes to read as a clean
bill of health.
A gate that only says no is a nag. Each item comes with what would close it:
[BLOCK] RG-ACT-001 'execution_reconstruction' is stated as NOT_ASSESSED
→ supply the run's trace or tool-call log
[ADVISORY] RG-PROV-002 all evidence traces to a single producer
→ add evidence from an independently-operated producer
That list is machine-readable (--json), so the next agent run can go and get the
evidence rather than a human re-reading the case to work out what was missing.
Not that a release is safe. Not that a result is guaranteed correct. Not
that the gate is unhackable — twenty attacks run against the engine itself and
one is recorded NOT_DEFENDED with what bounds it instead. Not that a case is
uncontested, that hallucinations are solved, or that an expert has been
replaced: the output is a list of what needs a person.
Each refusal is a property in code that cannot return anything else.
docs/POSITIONING.md names every one with the line that
enforces it.
import release_gate as rg
case = rg.create_case(objective="Deploy generated migration", subject=migration)
case.add_execution(trace) # the steps, or a native trace
case.add_verification(test_result, method="TEST_SUITE", outcome="PASSED",
verifier="ci://pytest", against_subject=True)
decision = case.finalize() # PROMOTE / HOLD / BLOCK, with its coverage attached
print(decision.required_evidence)
The same four calls carry one agent's migration and a ten-thousand-worker research run. Not two products with a shared name — one code path: 346 engine functions are common to both, 87% of everything the single-agent path touches.
Nothing is required to run. A methodology is what turns structure into a verdict — without one, release-gate reports everything structural it can see and holds, because "is this enough?" is a domain question and inventing an answer would be claiming a standard it does not have.
release-gate assure --list-methodologies
release-gate assure run.jsonl --methodology [email protected]
One input, four yardsticks, four answers — each naming what it is missing:
Organisation config (--config) layers your own standards on top and can only
ever tighten. The methodology, the resolution policy (--resolution-policy:
what it takes to establish a claim, what a counterexample does) and the
organisation config together are the declared release policy a PROMOTE is
measured against. Each is digested into the case.
The admission decision above is the product. These produce or carry its evidence, and each is documented in its own place:
git clone https://github.com/VamsiSudhakaran1/release-gate
cd release-gate && pip install -e '.[dev]'
pytest -q
MIT — see LICENSE.
Pre-deploy security auditor for AI agent code — the risks generic SAST misses.
{ "mcpServers": { "io.github.vamsisudhakaran1-release-gate": { "command": "uvx", "args": [ "release-gate==0.8.4" ], "env": { "RG_MCP_ALLOWED_ROOTS": "<value>" } } }}Инструменты
Списка инструментов пока нет. У удалённых серверов он появляется после первой проверки состояния.
FAQ
Скопируйте на этой странице конфигурацию stdio для Cursor, Claude Desktop, Claude Code или VS Code. Она использует установку издателя, а не прокси PlugMCP.
Издатель указывает следующие переменные окружения: RG_MCP_ALLOWED_ROOTS.
Release Gate работает локально через stdio.
Последняя проверка: 2026-11-09. Pre-deploy security auditor for AI agent code — the risks generic SAST misses.