Audit and enforce package release safeguards across AgenTrust

[imran-siddique]

Package publishing needs consistent release controls across AgenTrust. The repository consolidation is complete; this issue tracks the remaining safeguards sweep.

The TRACE cutover provides a verified starting point: reviewed PR #465, successful conformance publisher run, and PyPI 0.6.2. Its conformance-pypi environment currently has no required reviewers or deployment restrictions and allows administrator bypass, copied with explicit approval for cutover. That temporary configuration is not the desired organization-wide baseline.

Initial scope: agent-manifest, cmcp, ca2a, trace-spec (root library and conformance package), trace-registry, weight-custody-manifest, integrations (capture-core and trace-adapters), and agentrust-telemetry. Re-inventory active repositories to include any additional Python, npm, container or other package publishers. Archived source repositories should have no active publishing authority.

Completion criteria:

• Inventory each package, publishing workflow, registry, release trigger and environment; link evidence and record an accountable primary and backup.
• Agree and apply independent environment approval, prevent self-review where supported, restrict deployment refs to the intended release tags, and disable administrator bypass or document a reviewed exception. GitHub's required-reviewer list requires one listed approval, not all listed reviewers.
• Verify two available package owners/operators and exact trusted-publisher repository/workflow/environment bindings. Remove obsolete bindings after replacement verification.
• Require matching package/tag versions, successful tests and wheel/source or equivalent installed-artifact checks before publishing. Scope OIDC permissions to publishing jobs, pin external actions and preserve package-specific governance.
• Separate build-only rehearsal from production publishing. Imran requested production PyPI only; do not require TestPyPI or dispatch production as a dry run.
• Verify the resulting configuration through current settings and workflow evidence; record exceptions, owner and resolution.
• Add a sustainable audit or release checklist so later workflow/environment drift is detected.

No credentials, recovery codes or secret values belong in this issue. A successful release by Imran proves the publisher path works; it does not prove backup-operator coverage.

[dinakarjs]

Post-merge audit and proposed bounded trace-registry follow-up

Post-merge evidence

trace-spec #467, cMCP #722, trace-registry #113, and integrations #276/#277 have merged. All 32 push-triggered workflow runs returned for their exact merge revisions completed successfully:

PR	Merge revision	Successful push runs	Representative evidence
trace-spec #467	03ea1ef97548e93f30ad4ad3d31b374d8bf27d99	7/7	CI, Conformance CI, workflow lint
cMCP #722	5d09f089061b3d510ab1634172a62b80f221f62f	6/6	CI, workflow lint
trace-registry #113	221af17a345fa9dd9fe546260718977e5c539e93	4/4	CI, workflow lint
integrations #277	e61be77731caf752c618ecfa2d7ee56f7e9a990a	8/8	workflow lint, integration validation
integrations #276	3b66dce518c93e8c0fc1d6ddce773eabe406c194	7/7	integration validation

#276 is a marketplace refresh, not a publisher safeguard. Main-branch CI success does not establish an executed publisher rehearsal.

Environment decisions remain separate

Read-only REST environment inspection on October 5 returned no required-reviewer rules, no deployment-ref policy, and can_admins_bypass: true for all five inspected publishing environments:

• trace-spec environments: pypi, conformance-pypi
• cMCP environments: pypi
• trace-registry environments: pypi
• integrations environments: pypi

The conformance cutover exception is already documented in this issue. Could maintainers identify primary/backup reviewers and agree intended release-tag restrictions, self-review prevention where supported, and disabled administrator bypass or reviewed exceptions? The shared integrations environment needs both package tag families. A required-reviewer list requires one listed approval, not all listed reviewers.

Proposed trace-registry implementation scope

At merge revision 221af17a345fa9dd9fe546260718977e5c539e93, publish.yml has the new exact ref/tag/package/runtime-version guard, but the publisher has no release-revision test dependency or installed-artifact check. The build job uses the pypi environment and id-token: write even during build-only execution.

Release-revision validation

• Run required tests and validation against the exact revision being packaged.
• Make artifact building depend on successful validation; failed, cancelled or skipped validation must prevent publication.
• Handle the existing append-only check explicitly: its push/PR base-SHA assumptions must not silently disable validation or produce invalid comparisons on release/manual events.

Installed-artifact verification

• Build wheel and sdist, then install each into a separate clean environment.
• Run checks outside the repository so imports cannot resolve to the source tree.
• Verify packaged/runtime version agreement, CLI availability and a representative successful verification case.
• Include an invalid-evidence case with its expected rejection, so the installed verifier cannot pass by accepting everything.

Publishing isolation

• Keep build-only as the manual default.
• Move the pypi environment and publishing OIDC grant into a separate publishing job.
• Require explicit manual publication and the existing exact ref/tag/package/runtime-version agreement.
• Require successful validation, artifact checks and artifact transfer before publication.

Regression evidence

• Cover valid publication eligibility, branch/unrelated-tag/version-mismatch refusal, and build-only behavior.
• Check that weakening the test dependency, tag guard or publishing condition is detected.
• Preserve pinned actions, existing package checks and production-only publishing.

Could you confirm this scope, the required release-validation subset and a review owner before implementation? This is a proposal, not an ownership claim or newly executed fixture evidence. Environment protections, exact registry trusted-publisher bindings and backup-operator availability remain separate #54 work. No settings were changed, publishing workflows dispatched or packages published; this does not complete the organization-wide audit.

[dinakarjs]

Extended read-only publisher inventory, following the post-merge audit above. These are source observations at pinned revisions, not newly executed release tests or environment-setting verification.

Repository	Pinned evidence	Remaining gap / decision
agent-manifest	publish.yml at 055145f	Manual dispatch has no build-only mode or publish-job condition. Its tag/version check runs only when the ref already matches python-v*, so a branch dispatch can reach publication. Installed wheel/sdist checks and publishing-job OIDC exist, but there is no release-test dependency or environment binding in the publish job. This matches the earlier local patch scope awaiting confirmation/vouching; I have not opened a PR or claimed the registry binding itself is absent.
ca2a	release.yml at 9f74318	Exact tag/version and installed wheel/sdist checks exist, with OIDC scoped to the publishing job. There is no prepublication test dependency. Strict AGT verification runs in governance-release, which depends on publish, so it cannot prevent the PyPI upload if it fails. Please confirm whether that verification is intended as a prepublication gate or postpublication attestation before proposing a move.
weight-custody-manifest	publish.yml at e573b97, release gate, reusable validation	Validation precedes build; source/version and archive scans exist. Manual dispatch publishes to TestPyPI and requires current main, rather than offering build-only rehearsal. That differs from this issue's production-PyPI-only direction. Agree a build-only replacement without dispatching TestPyPI. Reusable validation exercises a separately built installed sdist; it does not install the final dist artifacts transferred by this publisher.

Telemetry's publisher inventory remains unresolved. It is active/public, but searches for gh-action-pypi-publish and publish returned no hits; that is not proof of absent publishing authority. The initial public REST scan hit a rate limit before collecting the additional repositories' environments, so their live protection settings remain unknown.

Suggested prioritization: retain the posted trace-registry scope decision and environment-protection decisions first; confirm agent-manifest scope/vouching, ca2a verification timing, and WCM's build-only transition before further implementation. Exact registry bindings, primary/backup operators, telemetry and broader non-Python publisher coverage still require evidence. No settings were changed, workflows dispatched or packages published.

[dinakarjs]

Telemetry inventory correction: supersedes the unresolved telemetry status in my preceding inventory comment.

A direct Git checkout at 590d6182f6b8ae0938a0546439ed854b92745d64 allowed inspection of all nine workflow files. release.yml publishes two packages from a published GitHub release:

• PyPI: agentrust-telemetry, environment pypi.
• npm: @agentrust-io/telemetry, environment npm.

Existing source controls: release-tag/cross-ecosystem version agreement, Python wheel/sdist installed-schema smoke checks, TypeScript build/tests, derived npm prerelease dist-tags, and OIDC scoped to separate publishing jobs. The separate release-assets job also uses OIDC for artifact attestation. No additional package/container publisher was found in those workflow files; this is not a claim about every external/manual publishing authority.

Two bounded validation gaps remain:

1. The release workflow does not depend on the full Python 3.10–3.13 CI matrix, including schema/compatibility checks, conformance and unittest execution. RELEASING.md asks for successful CI procedurally; that is not a release-revision workflow dependency.
2. npm run check builds/tests the source and performs a pack dry-run, then the workflow creates the final tarball. No install/import/test of that final tarball was found before npm publication.

Live pypi/npm environment protections, exact registry trusted-publisher bindings and primary/backup operator availability remain unverified. The release build's target_commitish == 'main' condition is also a target label, not an independently checked Git ancestry proof; any reviewed-history requirement should be agreed explicitly.

Please include the two validation gaps in the maintainer-prioritized backlog alongside the already proposed trace-registry work. This is source inspection, not new release execution or implementation ownership. No release was dispatched, settings changed or package published.

[imran-siddique]

@dinakarjs rulings on the implementation items, so you can move:

• trace-registry: scope confirmed as written. The validation subset is the existing ci.yml test job. On release and manual events, skip the append-only base-SHA check by name rather than letting it no-op. Start here and request my review.
• agent-manifest: same shape. Build-only is the manual default, the tag/version check runs unconditionally, and publishing depends on the tests.
• ca2a: governance-release is a post-publication attestation attached to the release, and it stays after publish. The gap is the missing test dependency before build, the same fix as trace-spec#467.
• weight-custody-manifest: yes, replace the TestPyPI dispatch with a build-only rehearsal.
• agentrust-telemetry: both gaps are in. The release depends on the CI matrix, and the final npm tarball is installed and tested before publication.

One repository per PR, in that order. Environment protections and the reviewer roster are org settings and sit outside this work.