Release gates

A release gate is the action boundary applied to the deployment itself. The deploy tool clears only when the evidence a reviewer will ask for is presented with it: an evaluation report, a named approver, an incident-path reference. Missing evidence is refused before anything runs, and the refusal is signed. Every outcome is an ACTION-v1 record, checkable offline against the published key.

This is the gate half of a deployment-readiness control. It does not run your evaluations or judge your approver; it makes the presence of that evidence a condition of the action and leaves a record either way.

The rule

Add a require_args rule to an active policy. The value is a tool pattern, a colon, and the evidence keys the action must carry:

json
{
  "name": "release-gate",
  "rules": [
    { "type": "require_args", "value": "deploy.*:eval_report_sha256,approved_by,incident_path" }
  ]
}

deploy.* matches every tool whose name starts with deploy.; an exact name works too. Keys are checked for presence and non-emptiness in the declared args.

Authorising a deployment

bash
curl -X POST https://api.aqta.ai/v1/actions/authorize \
  -H "Authorization: Bearer $SEAL_API_KEY" -H "Content-Type: application/json" \
  -d '{
    "tool": "deploy.production",
    "agent": "release-bot/1.4",
    "args": {
      "service": "credit-assist",
      "eval_report_sha256": "3b1f…e0a2",
      "approved_by": "model-risk@bank.example",
      "incident_path": "runbook-2026-08#rollback"
    }
  }'

With all three present the response is "outcome": "ALLOWED" and a signed record. Leave one out and the response is "outcome": "BLOCKED" with a reason that names it:

Blocked by policy 'release-gate': tool 'deploy.production' requires 3 evidence field(s)
before it can run and 1 missing: approved_by. Present the evidence in args; this gate
checks that it was presented, not that it is correct.

The refused deployment never ran, and the refusal is evidence: it shows the gate operated.

What the record commits to

args are hashed canonically into args_hash on the signed record and never stored. A reviewer holding the evaluation report and the approval can recompute the hash and confirm this deployment was cleared against exactly that evidence. Verify any record with the reference verifier:

bash
npx aqta-verify-receipt record.json --profile action-1 --key <key from /v1/attestation/public-key>

What it proves, and where it stops

  • It proves the gate ran, what it required, what was presented (by hash), and the outcome, at that moment.
  • It does not prove the evaluation was sound, the approver was entitled to approve, or the deploy that followed matched the declaration. The assertion-provenance table in the ACTION-v1 specification is normative for those boundaries.

Putting it in a pipeline

Call the authorise endpoint from the deploy step and fail the job on BLOCKED. The Seal MCP gateway does the same for an agent: the deploy tool is refused in the agent's own execution path, before the tool is reached.

Last updated: August 2026