just-vibeBackend · plan by default
/backend-permissions
Define and test authorization for roles, resources, and ownership
Use for application action/resource policy; security-authz audits suspected bypasses, db-access covers database roles and row policies, and arch-tenancy covers propagation across the whole system.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select backend-permissions from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv backend-permissions, /just-vibe backend-permissions and /jv:backend-permissions in Claude. See shortcut setup and context examples.
/just-vibe:backend-permissions Define read/update/export access rules for organization-owned invoices./just-vibe:backend-permissions Add permission checks for direct-ID access and background exports./just-vibe:backend-permissions Audit source without real tenant accounts; use synthetic identities and state assumptions.What the agent does
- Build subject/action/resource/tenant cases as an access matrix, and locate the server-side enforcement boundaries.
- Inspect alternate read, write and export paths and ownership transfers, and implement consistent checks when requested.
- Test cross-user, cross-tenant and indirect access with positive and negative cases.
Inputs
- roles, actions, ownership, tenant rules, and exceptions.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Server-side resource authorization across all relevant entry points.
- Writes
- Inspect/plan: inspect or propose; save requested artifacts only. Apply: edit the requested local implementation and perform relevant bounded checks while preserving unrelated work. Live data changes, remote actions and paid jobs require their resolved target and existing session authorization.
- Mode
- Plan for policy definition; apply for explicit implementation. Requires roles, actions, ownership, tenant rules, and exceptions.
- Prerequisites
- Service source, data/interface contracts, framework/runtime versions, and test environment. Default apply operations target local code and isolated tests; live infrastructure/data mutations require their own requested scope.
Expected output
- Access matrix, enforcement locations, enforcement changes if authorized, and positive/negative isolation checks.
How the work is checked
- Owners can perform intended actions; direct-ID requests cannot bypass tenant restrictions.
When to stop or clarify
- Ambiguous policy blocks that decision, not unrelated analysis. Never rely solely on hidden UI buttons as enforcement.
Handling missing context
- Infer
- Trace service callers, request contracts, authorization, transactions, retries and existing test infrastructure.
- Assume
- Use the existing persistence and framework; isolate local tests from live services.
- Ask
- Resolve ambiguous durability, duplication or consistency requirements before encoding them; absent production access does not prevent local implementation.
Technical guidance
- Evidence
- Build a subject/action/resource/tenant matrix from the product policy and locate all entry points.
- Method
- Enforce authorization using trusted identity and server-owned resource scope, including workers, downloads and bulk operations.
- Pitfall
- A hidden button or unguessable identifier does not enforce permission; an admin in one tenant is not automatically a global admin.
- Check
- Use two isolated users/tenants and verify denied requests leave no side effects while valid owner/admin requests still work.
Situational decisions
When policy is ambiguous for one role/resource combination: Isolate that decision while continuing checks for unambiguous denials and allowed paths.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.