Summary

debugTool.ts's four "dual-scope" actions (recent-executions, execution-detail, tool-call-detail, and health-report's per-user branch) were built with a two-tier access model: self, or a literal Cedar staff account (resolveCallerIsStaff, checked via email.endsWith('@cedarcopilot.com')). That meant an org admin/owner could not view a teammate's own execution/conversation/health data, even within their own organization, unless they also happened to be a Cedar employee. Confirmed live: a real org admin got "Not authorized to view run <runId>." trying to view a teammate's execution-detail in their own org.

• Replaces the bespoke resolveCallerIsStaff + === callerUserId comparisons in all four actions with a single call to the canonical authorize() (services/auth/authorize.ts), whose DEFAULT_POLICY already declares 'subagent_execution:user': 'SELF_OR_ORG_ADMIN' and has the Cedar-staff bypass built in internally , matching the reference call shape resolveAgentForAdmin already uses for test-run's own targetUserId gate.
• execution-detail/tool-call-detail keep their fixed, generic "Not authorized to view ..." denial message (not authorize()'s own reason), preserving the existing "don't reveal whether a run/tool-call exists" property , authorize()'s denial text names the target user id, which would otherwise leak the record's owner.
• Updates the file's top-of-file design comment, which described the old two-tier model as current, to document the new self / org-admin / Cedar-staff model and explain the two intentional exceptions below.

What was deliberately left alone

• diagnose-conversation , NOT migrated. Its callerCanAccessConversation() → assertConversationOrgAccess() check already allows any member of the caller's own org to diagnose any conversation belonging to that org , broader than conversation:user's SELF_OR_ORG_ADMIN policy, not narrower. Routing it through authorize() would tighten existing behavior (a plain member could no longer diagnose a teammate's conversation), which is a separate product question, not this bug. Flagged in the file's own comment rather than silently changed.
• health-report's org-wide (orgId) branch , unchanged, still Cedar-staff-only. It's a distinct, more sensitive capability (every user in an org at once) with no matching DEFAULT_POLICY row; subagent_execution:org already exists but gates a different action (a real org-level agent send, not a health-data read).
• create-monitor , untouched, Cedar-staff-only by design, no self-scoped variant.

Tests

Added to apps/server/src/mastra/tools/debug/__tests__/debugTool.test.ts (mocking authorize() as a boundary, matching test-run-subagent.test.ts's convention , the org-admin/plain-member/cross-org policy semantics themselves are already exhaustively covered generically, for every DEFAULT_POLICY row including subagent_execution:user, by services/auth/__tests__/authorize.test.ts):

• Org admin/owner viewing a teammate's execution/tool-call/health-report in the same org → allowed (the exact case that was broken).
• Plain (non-admin) member of the same org → still refused.
• Cross-org access by a non-staff admin → still refused.
• Cedar staff → still allowed.
• Self-access and "run/tool-call doesn't exist" cases → unchanged.

pnpm --filter @zero/server exec vitest run src/mastra/tools/debug/__tests__/debugTool.test.ts → 59/59 passing. pnpm --filter @zero/server run types → clean.

Test plan

• pnpm --filter @zero/server exec vitest run src/mastra/tools/debug/__tests__/debugTool.test.ts (59 passed)
• pnpm --filter @zero/server exec vitest run src/services/auth/__tests__/authorize.test.ts src/services/playbook/__tests__/test-run-subagent.test.ts (350 passed, no regressions)
• pnpm --filter @zero/server run types (clean)
• eslint on both changed files (clean; one pre-existing unused-var lint error in the