Model Deployment Gate

Model release pipelines and registries, where a customer's reviewer later asks which model versions were approved for production and on what policy.

The release decision

PERMITTED or DENIED for the tool call that promotes a model, with the tool name, an arguments hash and the SHA-256 of the policy's canonical JSON.

The reason

Why the policy refused it, for example a tool the policy does not allow. In 3.6.0 through 3.6.2 a path-constraint denial names the offending path, and a denied-pattern denial names the matched pattern.

The order

Each receipt hash-links to the one before it, and a signed checkpoint binds the set.

Routing

Make the promote step a tools/call that passes aga-proxy. Nothing in the published packages hooks a CI/CD pipeline or a model registry.

Digests

If the decision should depend on a model or SBOM digest, your tool passes it as an argument. aga-proxy's rules are tool allowlists, rate limits, and path and substring checks (known issue 10 on /security says what they check), not digest comparison.

Blocking

In-path, aga-proxy does not forward a call it denies. Whether the pipeline has another route to production is a property of your deployment.

The policy

aga-proxy's default profile, permissive, denies nothing on policy grounds; policy denial needs --profile standard or restrictive, or a --policy file in allowlist or denylist mode. The built-in profiles name example tools, so rules for your own tools need a custom --policy.

• Which release decisions passed the gateway, signed and in order, as the verifier parses them: a field name repeated in the file still verifies, because the verifiers read the last copy (known issue 5 on /security)
• Checkable offline by an auditor, against a key you gave them in advance
• Not that every release went through the gateway, or that a permitted release ran
• Nothing about model weights, training data or human approvals