Fix: Stop PRB Door B auditor over-reaching on scope-exclusive policies (#2511) - #845
Fix: Stop PRB Door B auditor over-reaching on scope-exclusive policies (#2511)#845anatolykoyfman wants to merge 1 commit into
Conversation
…s (#2511)
The Door B (user-role-focal, deny-only) auditor was rejecting a correct
empty-prohibition proposal to exhaustion when the scenario policy is
scope-exclusive about a DIFFERENT role ("Only developers may read source"):
it demanded a focal-role deny that does not belong to this pass, burned the
retry budget, and raised PolicyRulesBuilderError -> HTTP 422. That complement
deny is the scope-focal pass's job, so an absent Door B prohibition is correct.
Fix is auditor-only: a MISSING-PROHIBITION guardrail in _AUDITOR_SYSTEM tells
the auditor not to reject a proposal for a missing focal deny when the
restriction names a different entity (rule 4). The shared proposer/auditor
rules are reverted to baseline (byte-identical) — carrying this reassurance in
the shared rules regressed the proposer's legitimate description-driven denies.
- prompts.py: auditor-only guardrail; _PROPOSER_SYSTEM/_SAFETY/_MAPPING_RULES/
_DENY_RULES unchanged from baseline (grant behaviour untouched)
- test_graph_live_llm.py: slice 7 now asserts the real requirement — no 422,
no ALLOW, denies subset of {source-read, source-write}; a duplicate source
deny is a harmless echo of the scope-focal pass, not the defect
- CONTEXT.md: scope-exclusivity / role-exclusivity glossary entries
Verified: -m llm PRB suite 7/7 (slice 7 green 3/3 across mode-mixing).
Assisted-By: Claude (Anthropic AI) <noreply@anthropic.com>
Signed-off-by: Anatoly Koyfman <anatoly@il.ibm.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe auditor prompt now permits empty Door B prohibition lists when restrictions target another entity. Documentation defines scope- and role-exclusivity. A live-LLM test verifies that unrelated roles do not receive scope-exclusive denies. ChangesDoor B scope-exclusivity handling
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This localized fix prevents valid scope-exclusive policies from failing with a 422 while preserving existing deny-only and conflict safeguards; no actionable merge-blocking risk remains beyond normal checks and review. Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Full details: Linked Issues checkExplanation The prompt change addresses issue Full details: Out of Scope Changes checkExplanation The changes are within scope. They modify the Door B auditor prompt, add the issue-specific regression test, and document the scope-exclusivity and role-exclusivity distinction needed to explain the fix. Full details: Docstring CoverageExplanation Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 2 functions across 2 files. (1 skipped: 1 unsupported.)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
Fixes rossoctl/rossoctl#2511 — the PRB (Policy Rules Builder) Door B auditor over-reached on scope-exclusive policies, rejecting a correct empty deny proposal to exhaustion and returning HTTP 422.
When a scope-exclusive policy named a different role (e.g. "Only developers may read source") while onboarding a non-grantee focal role (rossoctl-admin), Door B (
build_role_denies, focal = user role, DENY-only) demanded a focal-role deny that does not belong to this pass. The complement deny is the scope-focal pass's job (rules 4 & 6), not Door B's. The proposer was always correct; only the auditor over-reached, burning the retry budget →PolicyRulesBuilderError→ 422.The fix (auditor-only)
A
MISSING-PROHIBITIONguardrail in_AUDITOR_SYSTEMtells the auditor not to reject a proposal for a missing focal deny when the restriction names a different entity (rule 4). An absent focal prohibition is a defect only when the scenario policy is exclusive/restrictive about the focal entity itself (rule 6) or explicitly prohibits it (rule 5).The shared proposer/auditor rules are byte-identical to baseline —
_PROPOSER_SYSTEM,_SAFETY,_MAPPING_RULES,_DENY_RULESunchanged. An earlier attempt that carried the reassurance in the shared rule-4 text regressed the proposer's legitimate description-driven denies; moving it to the auditor alone fixes both. The change can therefore only make Door B denies more conservative — grant behavior cannot change.Files (3)
aiac/src/aiac/agent/policy_rules_builder/prompts.py—_AUDITOR_SYSTEMguardrail onlyaiac/test/agent/policy_rules_builder/test_graph_live_llm.py— slice 7 repro relaxed to the real requirementaiac/CONTEXT.md— scope-exclusivity / role-exclusivity glossary entriesVerification
-m llm(real LLM, no cluster): full PRB live-LLM suite 7/7. Slice 7 reprotest_door_b_no_overreach_on_scope_exclusivitygreen 3/3 across model variance (no raise / no ALLOW / denies ⊆ {source-read, source-write}). Slice 6 exclusivity safety net (Testers may access only issues→ DENY source-read/write) intact. Slice 4 description-driven-deny regression guard green.Notes
main), so this branches off currentmainand applies as a single clean commit.#2511is tracked onrossoctl/rossoctl, not this repo — hence the explicit cross-repo reference above.Assisted-By: Claude (Anthropic AI) noreply@anthropic.com
Summary by CodeRabbit
Bug Fixes
Documentation