Bind deployment approval to accountable owners

Learning objective

Assign governance control owners and require auditable approval gates for FM deployments.

Core idea

An approval gate must answer three questions: who owns the risk, what exact release they approve, and which deployment path cannot proceed without that decision. A committee name on a document answers none of these by itself. For a foundation model (FM) workload, the release includes the model selection, prompt, retrieval configuration, safety policy, and application behavior that reviewers assessed.

Use AWS CodePipeline manual approval actions to stop a release at an enforceable boundary. Give named approver roles permission to decide, and retain the evidence behind their decision. For custom model artifacts, SageMaker AI Model Registry approval status is another relevant mechanism, but a registry status and an application release approval cover different objects. See 1.2.7 for artifact registration and 3.3.2 for model-card documentation.

How it works

Assign decision rights before choosing a gate

Define a control owner who maintains each policy, an evidence producer who runs its tests, an approver who accepts or rejects the release, and an operator who executes remediation. One person can hold multiple responsibilities where your organization permits it; separation is an organizational rule you must implement rather than infer from an AWS feature name.

For example, a privacy owner defines acceptable disclosure and logging behavior. A safety owner defines prohibited outcomes and the evaluation set. A product owner defines acceptable task quality and escalation. The deployment operator owns the technical release path. Assign a backup and a response deadline to each approval responsibility so absence does not become implicit consent.

Translate those responsibilities into access. CodePipeline documents codepipeline:PutApprovalResult as the permission that submits approval decisions, with resource-level scope to the approval action ARN. Scope a reviewer to the relevant pipeline, stage, and action instead of giving broad pipeline administration merely to approve a release. Restrict codepipeline:UpdatePipeline, which permits changes to pipeline structure, to the deployment-operator role rather than approvers; otherwise an approver can remove the gate they approve.

Stop the release on a specific execution

Place the manual approval action after evidence generation and before production deployment. CodePipeline stops execution when the action is reached. An authorized approval resumes execution; rejection causes failure. If nobody approves or rejects within seven days, the action fails and the pipeline does not continue.

The approval action can publish a notification to an Amazon SNS topic in the same Region as the pipeline. It can also include a review URL and comments. Use the URL to expose the release evidence package, not a mutable dashboard whose contents no longer represent the reviewed candidate. An SNS message requests attention; it is not the approval decision.

PutApprovalResult identifies the pipelineName, stageName, actionName, and token, and carries result.status and result.summary. Valid decisions are Approved and Rejected. The API returns approvedAt. The token identifies a unique approval request and validates that it remains open. For a pipeline in PARALLEL execution mode, AWS directs you to use the externalExecutionId from ListActionExecutions as that token.

The manual approval action holds the execution until an approver’s decision, or seven days without one, settles it.

This mechanism ties a decision to an approval request. Your release design must also bind the request to unchanged artifacts. Record the candidate’s version identifiers, evidence locations, and acceptance thresholds before requesting approval. If the prompt, model route, guardrail version, or corpus changes afterward, treat it as a different candidate and regenerate the affected evidence.

Keep model approval and release approval distinct

For a registered SageMaker AI model version, UpdateModelPackage can set ModelApprovalStatus to PendingManualApproval, Approved, or Rejected. AWS documents workflows in which approval changes initiate CI/CD deployment. That requires an integrated deployment process; changing a status is not a universal deployment barrier for every resource or caller.

A Bedrock application that changes a managed model identifier still needs governance even when it has no custom model package to register. Gate its application configuration release in CodePipeline. Conversely, approving a custom model package does not approve a later prompt or retrieval change automatically. See 2.3.9 for the compatible release package and 1.2.8 for promotion and rollback.

Retain the decision and its basis

CloudTrail captures CodePipeline API calls, including console and programmatic activity. Use a trail for ongoing delivery of these events to Amazon S3. The event records who made the request, when, and request details; preserve the evaluation report and human rationale separately so an auditor can understand why approval was warranted.

Build an evidence chain from the approval request to the decision, release artifact, deployment result, and post-deployment verification. A successful approval API call proves that a response was submitted. It does not prove that every required owner reviewed the evidence or that the deployed candidate matched it. Those are explicit checks in your governance design, with the broader forensic distinctions covered in 3.3.4.

Key distinctions and trade-offs

Control owner versus approver: The owner defines and maintains the control. The approver accepts a particular release against it. Naming an owner without an enforceable decision right leaves the deployment path unchanged.

Automated test versus human acceptance: A test can prove that measured thresholds pass. A reviewer can accept documented residual risk. Neither should silently substitute for the other when your policy requires both.

Registry status versus pipeline gate: Model Registry describes approval of a registered model version. CodePipeline stops a release execution. Choose the mechanism for the object being governed, and connect them where a custom model and application configuration ship together.

Manual review adds lead time and can become repetitive. Reduce the review burden with a compact evidence package and explicit change classification. Do not reduce it by allowing timeouts to pass or by reusing an approval for changed artifacts. More gates help only if each has a distinct decision, owner, and rejection path.

Architecture / decision scenario

A claims assistant changes its Bedrock model route and prompt while retaining a separately hosted SageMaker classifier. The classifier has an approved Model Registry version, but the safety owner requires another review because the assistant’s responses change.

The pipeline builds a release package containing the route, prompt version, classifier package reference, and evaluation report. Automated checks reject candidates that miss the documented safety or quality thresholds. A CodePipeline manual approval action then stops before production, publishes an SNS notification, and provides a review URL.

The designated approver submits PutApprovalResult with Approved and a rationale referencing that package. CloudTrail supplies the identity and API event; the evidence package supplies the test results and risk rationale. The operator deploys the same candidate and records verification. If privacy review discovers unacceptable response logging, the approver submits Rejected; the team changes the candidate and starts a fresh review rather than editing the approved package in place.

Common exam traps

• Treating an SNS approval notification as authorization to deploy.
• Assuming an unanswered manual approval resumes after seven days.
• Giving a reviewer pipeline administration when only an approval action is needed.
• Assuming ModelApprovalStatus: Approved governs all Bedrock application changes.
• Reusing approval after changing the evaluated prompt or safety configuration.
• Treating an audit event as a substitute for the evaluation evidence and risk rationale.

What to remember

• Assign control maintenance, evidence production, approval, and operation explicitly.
• Bind approval to an unchanged candidate and an enforceable deployment path.
• CodePipeline manual approval stops execution; rejection and timeout fail it.
• Scope codepipeline:PutApprovalResult to the required approval action.
• Preserve the decision, its evidence, and proof of the deployed release together.

Knowledge check

References

• AWS, Add a manual approval action to a stage
• AWS, PutApprovalResult
• AWS, Permissions reference
• AWS, Update the Approval Status of a Model
• AWS, Logging CodePipeline API calls with AWS CloudTrail