fix(controlplane): restrict organization updates to admins of the target org (CP-N1)

[migmartri]

OrganizationService.Update took the organization to modify from the request body, while the authorization middleware evaluated the caller's role against the organization selected in the request headers. Because the two were never compared, a user who was an admin or owner of one organization could change the security settings of any other organization they held a membership in — even as a plain viewer.

The settings reachable this way are organization-wide security controls: policy violation blocking, the allowed hostnames the policy engine fetches Rego from, blocking attestations on released versions, runner environment variable capture, and the stale API token threshold.

Two changes close it:

• The service layer pins the update to the currently selected organization and rejects a request body naming a different one.
• The biz layer authorizes against the membership held in the organization being updated and requires an admin or owner role there. This also closes the same-organization case, where any member could previously change these settings.

AI assistance: this change was produced with Claude Code.

🤖 Posted by Maximus bot (Claude Code) on behalf of @migmartri

[chainloop-platform]

AI Session Checks — 🟡 60% · ✅ 0 failing

Avg score	Sessions	Failing policies	Attribution	Files	Lines	Total Duration
🟡 60%	1	✅ 0	100% AI / 0% Human	5	+186 / -4	1h17m9s

🟡 60% — 100% AI — ✅ All policies passing

Aug 2, 2026 21:11 UTC · 1h17m9s · $13.31 · 379 in / 116.5k out · claude-code 2.1.220 (claude-opus-5)

View session details ↗

Change Summary

• Pins organization updates to the current context org at the service layer.
• Requires admin or owner membership in the target organization before updating settings.
• Adds service and integration regressions that reproduce the exploit and verify the guard.
• Removes the brief CLI-side mismatch check after the user rejected that extra layer.

AI Session Overall Score

🟡 60% — Well-tested fix, but setup was thin and a late scope detour needed correction.

AI Session Analysis Breakdown

🟢 92% · solution-quality

🟢 AI fixed both service and biz authorization layers. · High Impact

🟢 88% · alignment

🟢 AI re-verified CP-N1 against upstream before editing. · High Impact

🟢 86% · user-trust-signal

No notes.

🟡 74% · verification

🟢 AI added regression tests first and reproduced the exploit. · High Impact

🟠 The session stayed user-attended, but no explicit user confirmation followed the final PR iteration. · Medium Severity

💡 When users stay engaged, end with a specific request for final behavior confirmation.

🟡 68% · scope-discipline

🟠 AI opened the PR with an extra CLI-side check before the user narrowed scope. · Medium Severity

💡 When a safeguard is optional, ask before extending the fix into another layer.

🔴 35% · context-and-planning

🔴 A one-line opener launched a multi-file security fix, and no shared plan ever appeared. · High Severity

💡 For multi-layer security work, write a short shared plan before editing or opening a PR.

---

File Attribution

████████████████████ 100% AI / 0% Human

Status	Attribution	File	Lines
modified	ai	app/controlplane/pkg/biz/organization_integration_test.go	+89 / -1
created	ai	app/controlplane/internal/service/organization_test.go	+72 / -0
modified	ai	app/controlplane/internal/service/organization.go	+14 / -1
modified	ai	app/controlplane/pkg/biz/organization.go	+8 / -0
modified	ai	app/controlplane/pkg/biz/apitoken_stale_revoker_integration_test.go	+3 / -2

---

Policies (4)

Status	Policy	Material	Messages
✅ Passed	ai-config-ai-agents-allowed	ai-coding-session-61088e	-
✅ Passed	ai-config-no-dangerous-commands	ai-coding-session-61088e	-
✅ Passed	ai-config-no-secrets	ai-coding-session-61088e	-
✅ Passed	ai-config-mcp-servers-allowed	ai-coding-session-61088e	-

---

Powered by Chainloop and Chainloop Trace

[cubic-dev-ai]

All reported issues were addressed across 6 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>