Architecture · inspect by default
/arch-tenancy
Evaluate tenant isolation across authentication, storage, queries, and jobs
Use for system-wide tenant isolation; backend-permissions handles individual application checks and security-authz probes a concrete bypass.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select arch-tenancy from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv arch-tenancy, /just-vibe arch-tenancy and /jv:arch-tenancy in Claude. See shortcut setup and context examples.
/just-vibe:arch-tenancy Audit organization isolation across caches, jobs, APIs, and exports./just-vibe:arch-tenancy Review multi-organization users and background exports./just-vibe:arch-tenancy Inspect tenancy without authorized test identities; use source and synthetic fixtures only.What the agent does
- Map tenant ownership of each resource type, including shared resources and membership changes.
- Follow tenant identity through API, database role, cache key, queue payload, file storage and support/admin paths, and identify missing isolation checks.
Inputs
- tenant model, resource types, membership rules, and access boundaries.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Tenant identity propagation across APIs, storage, caches, jobs, exports, and support operations.
- Writes
- No source changes in inspect/plan. Save only requested planning artifacts. A separately requested repair uses the relevant implementation workflow.
- Mode
- Inspect; tenant model, resource types, membership rules, and access boundaries.
- Prerequisites
- Readable source, infrastructure/configuration definitions, and any supplied system documentation. Runtime telemetry is optional evidence, never assumed available. Architecture proposals remain plans until implementation is requested.
Expected output
- Resource ownership and propagation matrix with concrete bypass candidates, and proposed negative tests or migration design.
How the work is checked
- Background jobs preserve tenant identity; multi-organization users cannot access an unselected unauthorized organization.
When to stop or clarify
- Do not use real cross-tenant data for probing. Policy ambiguity must be resolved before implementing access changes.
Handling missing context
- Infer
- Trace current entry points, data owners, deployment units and documented constraints before proposing boundaries.
- Assume
- Prefer extending an existing owner while scale or organizational evidence is absent; mark capacity estimates as assumptions.
- Ask
- Ask for an unresolved consistency, compatibility or ownership requirement only if it changes the design; missing telemetry limits capacity claims, not source mapping.
Technical guidance
- Evidence
- Trace authenticated tenant identity through queries, caches, queues, search, object storage and support access.
- Method
- Define subject/action/resource/tenant checks at each boundary; derive identity from trusted context rather than a request body alone.
- Pitfall
- An isolated HTTP route can still enqueue a job or populate a shared cache without tenant scope.
- Check
- Run two synthetic tenants with overlapping resource IDs through direct, cached, exported and asynchronous paths.
Situational decisions
When an identity belongs to several organizations: Separate membership from selected-tenant authorization at each effect boundary.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.