A published Agent's behavior can change after approval, silently — and a locked role pin makes it unavoidable

[philmerrell]

Found while assessing the Agent Marketplace after phase 8. Three individually-reasonable v1 non-goals compose into a governance hole that none of them was evaluated against.

The composition

Decision	Where
No re-review on edit — "the listing is reviewed, not every subsequent change"	D2 / Non-goals
No agent versioning or changelogs — "a published Agent is a live pointer; updates are immediate"	Non-goals
Admins can lock a role-seeded pin so members cannot remove it	D9 / phase 6

update_agent_endpoint passes instructions straight through to update_assistant and never touches listing state (backend/src/apis/app_api/agent_designer/routes.py:413). So:

An admin locks an Agent into every member of a role's sidebar → the author then rewrites its instructions → the new behavior is live immediately, for everyone, with no re-review, no version history, no notification to the admin who locked it, and nothing in the reports queue.

Verified live on dev that a locked role pin overrides a user's own dismissal — the tombstone loses to the lock, by design. So the affected user cannot opt out either.

Why this wasn't caught

Each non-goal was decided before locked pins existed. D2's "no re-review on edit" is entirely defensible for an Agent someone chose to pin. It reads differently when an admin pinned it for them and removed the opt-out. Phase 6 added the lock without revisiting D2.

Not asking for versioning

The Non-goals list is probably right that v1 shouldn't build changelogs. Cheaper options that close most of the gap:

1. Notify or re-queue on edit, but only for Agents that are published AND locked somewhere. Narrow blast radius — most edits stay frictionless.
2. Surface a "changed since approval" marker on the admin Listings row, using updatedAt vs the listing's approval timestamp. Pure read, no new state.
3. Record the approved instructions hash at approval and show a diff-available indicator. One field.
4. Decide explicitly that this is acceptable and write it into the spec as a named risk, so the next person doesn't rediscover it.

Option 2 is probably the best value — it needs no new writes and gives the curator a reason to look.

Related

• Locked-pin ceiling is a separate unresolved question that makes this worse the more locks exist.
• Spec: docs/specs/agent-marketplace.md D2, D9, Non-goals.

🤖 Generated with Claude Code

[philmerrell]

Related: #748 (locked-pin ceiling) — the more locked pins exist, the wider this exposure gets, so the two are worth deciding together.

[philmerrell]

Shipped in #757, merged to develop as 20f5cd1. Approval now records a SHA-256 of the instructions it approved, and the admin Listings table marks any published listing whose instructions no longer match.

Resolved as option 2 + option 3 combined, because neither was sufficient alone:

• The timestamp comparison alone fires on an admin's own D13 presentation edit (which bumps updatedAt without touching reviewedAt) — a governance marker that cries wolf gets learned-ignored.
• The hash alone would be blind on every listing approved before it shipped, which is exactly the already-published, possibly-locked back catalogue this issue is about.

So the marker reports two distinct claims: instructions (measured, hash mismatch) and edited (inferred, timestamp only, legacy listings only), styled and worded so they never read alike.

Also closed a leak found on the way: the baseline is a hash of the instructions, so it now rides the same viewer gate that already drops instructions below editor.

Options 1 (notify/re-queue on edit) and 3's diff view remain unbuilt — as does #748, which makes this worse the more locked pins exist. The issue notes those two are worth deciding together.

Closed by hand: Fixes #744 does not fire on a merge to develop.