Production deployment approval policy

The control gap

A coding agent may prepare a deployment automatically while release authority remains an explicit human decision.

Deployment approval needs a stable artifact identity. Bind the request to the image digest, package checksum, environment, service, and release change set. A human approving a friendly release name should not unknowingly authorize a different artifact rebuilt after review. Endram can include these immutable selectors in both the policy input and the resulting receipt.

Separate preparation from release. Agents may run tests, assemble notes, create a deployment plan, and stage an artifact automatically. The production transition remains held until a release manager reviews the exact target and evidence. Expiry should be short because infrastructure state and incident conditions change quickly.

Build the policy input from the delivery system rather than agent prose. Useful attributes include protected environment, artifact digest, source commit, test result identifiers, change window, rollback artifact, and service owner. Require the deployment adapter to compare those bound values immediately before it calls the provider.

Model emergency release authority separately from the routine path. A break-glass rule can demand an incident identifier, a narrower reviewer group, and a second notification without weakening ordinary deployment controls. Log the exceptional rule and reason explicitly so emergency use is reviewable after the incident.

A successful authorization is not a successful rollout. Complete the execution record with the deployment provider response, resulting version, target region, and final status. Failed or partial rollouts should close the one-use grant and create a new review request before retrying a materially different artifact.

What good looks like

A narrow policy that can be tested in shadow mode, reviewed with owners, and promoted to enforcement with measurable impact.

• Match the concrete action "deploy" rather than every operation exposed by the tool.
• Scope the target to the production environment and the production environment.
• Require a request-bound approval that expires and cannot be reused.
• Record denied attempts as well as approved executions.

A production workflow

1. Copy the template and replace example identities and resource selectors.
2. Run it in shadow mode against representative requests.
3. Review false positives, missing resource attributes, and approver routing.
4. Enable enforcement for one agent and expand only after reviewing the decision log.

A policy you can test

Production deployment approval policy is a concrete starting point, not a claim that one generic rule fits every environment. Replace example identities and selectors, validate the request shape, and begin in shadow mode.

name: production-deploy-approval
match:
  action: deploy
  environment: production
decision: require_approval
approval:
  reviewers: ["release-managers"]
  expires_in: 10m

Endram keeps the policy version with every decision. A later change creates new evidence instead of rewriting why an earlier request was permitted.

Evidence to require

• Every attempted deploy, including denied requests.
• The exact the production environment selector evaluated by policy.
• The requesting agent, delegated user, reviewer, and timestamps.
• Policy version, matched rule, decision reason, and execution result.

Buyer checklist

• Does the selector cover only the intended production resources?
• Who owns the approval queue outside business hours?
• What is the acceptable approval expiry?
• Which emergency identity may bypass the rule, and how is that use audited?