Generated authorization checks

Authorization & Tenant Properties

Use this skill when verifying multi-tenant isolation, role/attribute/relationship permissions, delegation rules, field-level visibility, or approval gates across generated actors, workspaces, and resources.

Core Security & Isolation Invariants

1. Universal Cross-Tenant Non-Interference:
   • Generate multi-tenant worlds with tenants $T_A \neq T_B$, users with varying memberships (member of $T_A$ only, member of both $T_A$ and $T_B$ with different roles, suspended member), and resources owned by each tenant.
   • Read / Search / Export Isolation: Any query, list, search, autocomplete, or report executed under active context $T_A$ must return zero records or aggregates from $T_B$, even when filter payloads explicitly inject $T_B$'s resource IDs.
   • Write / Mutation Isolation: Executing any create, update, delete, bulk action, or background job in $T_A$ must leave the complete state snapshot of $T_B$ bit-for-bit identical: $\text{State}(T_B){\text{after}} \equiv \text{State}(T_B){\text{before}}$.
2. Authorization Matrix & Monotonic Revocation:
   • For any generated $(actor, action, resource, context)$ tuple where the policy specification denies access, the operation must fail with zero side effects and zero sensitive data leakage.
   • Removing a role, revoking a delegation, or suspending workspace membership must monotonically shrink or preserve the set of permitted actions—never expand it: $\text{Perms}(\text{after_revoke}) \subseteq \text{Perms}(\text{before_revoke})$.
3. Delegation & Escalation Prevention:
   • An actor $A$ cannot grant or delegate a permission $p$ to actor $B$ unless $A$ holds $p$ (and delegation authority) in the same scope, and $B$'s effective delegated access must automatically vanish when $t \ge \text{expires_at}$ or when $A$'s own access is revoked.
4. Field-Level Redaction Invariant:
   • For any actor lacking field-level read permission on sensitive attributes $F_{\text{secret}}$, no API response, GraphQL selection, sort/filter oracle, or export may expose values from $F_{\text{secret}}$.
5. Approval Gate & Segregation of Duties (SoD):
   • For any operation exceeding an approval threshold or requiring four-eyes review:
     • The requester cannot approve their own request ($\text{approver_id} \neq \text{requester_id}$).
     • Mutating the request payload after approval invalidates the approval or is rejected.
     • No state transition to executed is reachable without the required valid approvals.

Checklist

• Does the generator include users who belong to multiple tenants with different roles, plus cross-tenant resource IDs in request payloads?
• Is tenant $T_B$'s state verified to remain completely unchanged after arbitrary operations executed in tenant $T_A$?
• Are delegation expiry, role revocation, and membership suspension tested to confirm immediate loss of access?
• Are self-approval and post-approval payload tampering tested and rejected across all generated approval flows?