← Back to Bevy · project planning pack

Skill · Version 1.0.0

Review authorization and tenant boundaries

Reviews who may read or change player, guild and game-workspace data. Follows permissions through nested identifiers, downloads and live events instead of trusting hidden interface controls.

authorization-tenant-boundary-review

Agents using this skill

See how it helps

When is it useful?

Use when reviewing an API, job or export that accesses customer data.

What does it help you do?

  • Checks nested identifiers as well as the resource named in the URL.
  • Reviews lists, caches and live channels for cross-workspace exposure.
  • Finds writable privileged fields and unauthorized sensitive response fields.

Try asking this

Review a guild-inventory transfer endpoint. Try a valid guild member, a former member and a request that substitutes an item ID from another guild. Trace database queries and emitted events; rejected transfers must leave both inventories unchanged and reveal no private guild contents.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

Authorization & Tenant Boundary Review

Use this skill during specification and code review to verify that every read, write, list, export, and background operation enforces identity, workspace membership, and action permissions on the server.

Workflow

  1. Check the three-part access control invariant on every entry point:
    • Verify that every new or modified route, RPC handler, or job checks:
      1. Authentication: Who is the caller?
      2. Tenant / Workspace scope: Does the caller belong to the active workspace, and does the target resource belong to that exact same workspace (WHERE id = ? AND workspace_id = ?)?
      3. Action & resource permission: Does the caller's role, ownership, or approval state permit this specific operation on this specific resource state?
  2. Spot Indirect Object Reference (IDOR) and cross-tenant leaks:
    • Check nested IDs in request bodies (projectId, assigneeId, parentId, attachmentId, templateId): never verify only the top-level URL parameter while allowing the body to link or copy a record belonging to another tenant!
    • Check list, search, aggregation, and export queries to ensure every query is scoped by tenant_id / workspace_id.
    • Check cache keys, pub/sub channels, and SSE/WebSocket streams to ensure events for Tenant A are never broadcast to connections held by Tenant B.
  3. Verify field-level and state-dependent restrictions:
    • Confirm that read-only or restricted fields (e.g., role, status, approvedBy, internalNotes, priceOverride) cannot be mass-assigned by standard users on create/update endpoints, and sensitive fields are stripped from unauthorized responses.
    • Route deep policy-engine or cryptographic security questions to the authorization and security specialists.

Included files 1

  • SKILL.md