Skip to content
Gateway Guardian

Suite development project-membership configuration

This example creates the minimal project-scoped configuration required to associate Viper traffic with the suite development project 1a8d1fdc-3161-423f-8548-b96d6f493661.

The configuration contains only the mandatory builtin.project_membership bootstrap entry. It accepts unexpired, unrevoked ProjectMembershipV1 credentials issued by the suite development Integrity Service issuer and requires the automation-agent role.

Prerequisites

Section titled “Prerequisites”
  • The suite development Gateway runs with project context enabled.
  • The project reference and membership evidence already exist in Control Plane.
  • Control Plane has a publisher signer configured whose key ID and public key match a trust root shared with Gateway. The configuration workflow intentionally sends unsigned desired state and relies on Control Plane to sign the immutable configuration manifest server-side.
  • GUARDIAN_CONTROL_PLANE_TOKEN contains a bearer token authorized to manage the project configuration. Do not commit or paste this token into either manifest.

Validate and plan as a project administrator

Section titled “Validate and plan as a project administrator”

From this directory:

Terminal window
guardian-plugin \
  --manifest guardian.plugin.toml \
  --configuration-manifest guardian.config.toml \
  configuration validate


guardian-plugin \
  --manifest guardian.plugin.toml \
  --configuration-manifest guardian.config.toml \
  configuration plan

The project workflow resolves the existing active builtin.project_membership definition through a project-authorized endpoint. Review the plan before applying it.

Do not run guardian-plugin publish with a Governance Studio organization or project administrator token. publish manages Guardian’s global plugin definition catalog and intentionally requires the separate Guardian platform administrator role. If validation reports that the builtin definition is missing or inactive, a Guardian platform administrator must publish it once:

Terminal window
guardian-plugin --manifest guardian.plugin.toml publish

After that global bootstrap, organization/project administrators can validate, plan, apply, inspect, and roll back this project configuration without global plugin catalog permissions.

Apply and verify

Section titled “Apply and verify”
Terminal window
guardian-plugin \
  --manifest guardian.plugin.toml \
  --configuration-manifest guardian.config.toml \
  configuration apply


guardian-plugin \
  --manifest guardian.plugin.toml \
  --configuration-manifest guardian.config.toml \
  configuration show

After activation, start a fresh viper claude session and make a request. The Gateway audit record should show the project URN, membership_established=true, membership_validation_status=valid, and bootstrap_outcome=allowed.

If creation fails with manifest_signature and signer_key_id are required, the Control Plane deployment has public plugin trust configured but is missing its publisher signer key ID and private seed-file mount. Fix that deployment prerequisite before retrying; the CLI does not place private signing material in project manifests.

If the policy needs to be removed, inspect history and roll back deliberately:

Terminal window
guardian-plugin \
  --manifest guardian.plugin.toml \
  --configuration-manifest guardian.config.toml \
  configuration history --limit 10


guardian-plugin \
  --manifest guardian.plugin.toml \
  --configuration-manifest guardian.config.toml \
  configuration rollback