Shipping an agentic application on GCP with evidence gates

Sanitized use case

A conversational product with a protected build boundary#

Consider a production conversational application with a public web surface, a model-backed API, external tools and private research material in the same development repository. The first deployment risk is not the model—it is accidentally packaging what should never be public.

The build context therefore starts from deny-by-default rules and an exact reviewed manifest. The container receives only runtime files; research, reports, scripts, credentials and paid content remain outside.

Delivery workflow

Five evidence boundaries from commit to traffic#

Copyable release record

Make the decision portable across build, revision, and incident#

A compact record connects what was built, what was tested, who decided, and where traffic can return. Store references and verdicts rather than copying sensitive prompts or responses into a release log.

The fields below are a minimum working contract, not a vendor requirement. Add product-specific invariants and retention rules without turning the record into an unreviewable data dump.

steps:
  - name: gcr.io/cloud-builders/docker
    args: [build, -t, "${_IMAGE_URI}", .]
  - name: gcr.io/cloud-builders/docker
    args: [push, "${_IMAGE_URI}"]
  - name: gcr.io/google.com/cloudsdktool/cloud-sdk:slim
    entrypoint: gcloud
    args:
      - run
      - deploy
      - "${_SERVICE}"
      - --image
      - "${_IMAGE_URI}"
      - --region
      - "${_REGION}"
      - --no-traffic
      - --tag
      - candidate
      - --quiet
options:
  logging: CLOUD_LOGGING_ONLY

#!/usr/bin/env bash
set -euo pipefail

: "${SERVICE:?set SERVICE}"
: "${REGION:?set REGION}"
: "${PROJECT:?set PROJECT}"
: "${ACCOUNT:?set ACCOUNT}"
: "${CANDIDATE_URL:?set CANDIDATE_URL}"
: "${CANDIDATE_REVISION:?set CANDIDATE_REVISION}"
: "${PREVIOUS_REVISION:?set PREVIOUS_REVISION}"

rollback() {
  gcloud run services update-traffic "$SERVICE" \
    --region "$REGION" \
    --project "$PROJECT" \
    --account "$ACCOUNT" \
    --to-revisions "$PREVIOUS_REVISION=100" \
    --quiet
}
trap rollback ERR

curl --fail --silent --show-error "$CANDIDATE_URL/health"
curl --fail --silent --show-error "$CANDIDATE_URL/critical-journey"

gcloud run services update-traffic "$SERVICE" \
  --region "$REGION" \
  --project "$PROJECT" \
  --account "$ACCOUNT" \
  --to-revisions "$CANDIDATE_REVISION=100" \
  --quiet

trap - ERR

{
  "artifact": "image@sha256:<digest>",
  "candidate_revision": "service-00042-abc",
  "previous_revision": "service-00041-xyz",
  "evidence_uri": "<immutable-evidence-reference>",
  "verdict": "PROMOTE",
  "rollback_target": "service-00041-xyz"
}

Identity and secrets

Keep credentials out of source and build output#

Use dedicated service identities with the minimum roles required for build, registry and runtime. Store secrets in Secret Manager and bind them at runtime; do not bake values into the image or print them in build logs.

Separate human deploy authority from runtime identity. An application that can call a model does not need permission to modify its own infrastructure.

No-traffic readiness

Test the revision you are about to promote#

A successful deploy proves that Cloud Run accepted a revision, not that the product works. Probe health, public routes, authentication boundaries, model/tool dependencies, analytics and critical journeys against the candidate revision.

For an agentic system, include at least one deterministic journey and one evaluated open-ended journey. Store the revision and artifact identifiers beside the verdict.

Traffic and rollback

Make promotion reversible#

Cloud Run revisions are immutable and support traffic migration. This enables testing a tagged revision, gradual rollout, and routing traffic back to a known-good revision.

Define the rollback signal before promotion: error rate, latency, policy violation, failed business journey, or evidence pipeline failure. If observability is broken, HOLD is safer than a blind rollout.

Operational checklist

Before migrating traffic#

• ✓Build context matches an exact reviewed manifest.
• ✓Dependencies and base image are pinned and audited.
• ✓No secret or protected content enters the artifact.
• ✓Tests, evals, security and localization gates pass.
• ✓Image digest is tied to the commit and used for deployment.
• ✓Candidate revision serves no traffic during readiness checks.
• ✓Critical routes and agent journeys pass against that revision.
• ✓Service account roles follow least privilege.
• ✓Secrets are runtime-bound and absent from logs.
• ✓Known-good revision and rollback command are recorded.
• ✓Traffic migration has an owner and stop signal.
• ✓Post-promotion smoke is ready for the public hostname.