Skip to content

AI governance release controls

Status: Current | Last reviewed: 2026-08-31

Compliance-assigned tenants cannot publish an agent or workflow until the exact draft has a complete AI governance evidence chain.

Evidence chain

  1. Inventory records identify the agent or workflow, owner, intended purpose, affected populations, status, impact level, and human oversight. High-impact entries require a nonempty oversight plan. Prohibited, suspended, and retired systems cannot pass.
  2. Risk assessments record revisioned hazards, controls, residual risk, assessor, independent approver, and approval state. Unacceptable residual risk blocks release.
  3. Evaluation runs bind suite key and revision, pass result and rate, metrics, evidence URI and SHA-256, runner identity, provenance, and timestamps to the exact canonical artifact hash.
  4. Release approvals bind rationale, reviewer, decision, expiry, and the same artifact hash. The inventory owner cannot approve. Approval cannot last more than 90 days.
  5. Bedrock stages must use the deployment's exact guardrail ID and a numbered version. Draft guardrails do not pass.
  6. Publish pins the inventory, assessment, evaluation, approval, artifact hash, profile hash, and policy decision to the immutable version. Conversation and workflow-run records copy those pins.

Published-artifact immutability

The protect_published_ai_artifact trigger on agent_versions and workflow_versions enforces two rules on every UPDATE: a published version's config cannot change, and the five ai_* evidence pins cannot change once assigned.

The scope of the first rule is the committed release, and it has two carve-outs, both in 055_publish_release_amend_carveout.sql.

The creating transaction. Publishing is one transaction that first inserts the release row from the draft, then stamps the concrete expansion onto it — capability refs expanded, runtime-profile variants derived, _capability_provenance and _profile_provenance added — because drafts hold refs and stack intent while published rows hold the expansion. That amendment is part of minting the release, so the trigger allows a config change when the row's xmin is the current transaction's id and rejects it from every later one. Enforcing the rule against the creating transaction as well blocked publishing outright: publishAgentVersion rolled back on its own expansion write and the UI reported Failed to publish version / published artifact config is immutable; create and approve a new version with no new version created. Because the expansion write also fires whenever profile derivation changes anything, that affected most agents, not only ones carrying capability: refs.

A declared maintenance session. Eight forward migrations rewrite config on every version, published ones included — rewriting history is what a data migration is for. Each one opens with SET app.schema_migration = 'on', which the trigger honours and no application ever sets (same shape as the app.is_platform_admin RLS bypass, and session-scoped: every caller applies one file per psql session). Without it, migrate-city-db.sh Phase C aborted at 004_migrate_warm_transfer_builtin.sql on any populated database.

A table the trigger does not know how to key by falls back to rejecting. The evidence pins stay immutable inside both carve-outs. Both are exercised by check-publish-invariants.sh in the schema-drift workflow, which also fails a new config-rewriting migration that forgets the marker.

Use GET /api/ai-governance/{subjectType}/{subjectId} to evaluate the current draft. Use POST with register_inventory, record_risk_assessment, record_evaluation, or approve_release to add evidence. Any draft change produces a new SHA-256 and invalidates the old evaluation and release approval.

Operating duties

The API supplies durable technical gates. The AIMS owner still defines AI policy, acceptable use, impact method, data suitability, evaluation design, fairness and accessibility criteria, transparency, human authority, monitoring thresholds, incident taxonomy, supplier review, change classification, internal audit, management review, and improvement actions. Store evaluation content and sensitive workpapers in the approved evidence system, not Git.