authorization-matrix-designer

Design explicit authorization matrices with deny-by-default rules for multi-tenant software.

2|Updated Jul 6, 2026
One-click install
npx skills add https://github.com/nguyenpv1980-wq/Project-Aegis --skill authorization-matrix-designer
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: authorization-matrix-designer
Source: https://github.com/nguyenpv1980-wq/Project-Aegis/tree/main/.claude/skills/authorization-matrix-designer
Command: npx skills add https://github.com/nguyenpv1980-wq/Project-Aegis --skill authorization-matrix-designer

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill solves the problem of inconsistent, ad hoc authorization logic by turning access control into an explicit roles, permissions, and resource matrix with clear deny-by-default rules. It helps teams prevent cross-tenant leaks, IDOR issues, and privilege creep before implementation.

Core Features & Use Cases

  • Role and permission design: Define who can do what across tenant roles, platform roles, service accounts, and brokered support access.
  • Object-level authorization rules: Specify membership, ownership, and grant-based checks for every tenant-owned resource.
  • Enforcement-point mapping: Document where authorization is enforced across UI, API, services, background jobs, integrations, and admin consoles.
  • Negative-test planning: Create denial tests for escalation, revocation, cross-tenant access, and expired impersonation.
  • Migration safety: Plan additive role changes with shadow dual-checks and rollback paths.
  • Use case: A SaaS team is adding billing admin access and support impersonation, and uses this Skill to define the exact permissions, scope limits, audit expectations, and forbidden actions.

Quick Start

Use the authorization matrix designer skill to define a deny-by-default access model for my multi-tenant app, including roles, permissions, object-level rules, enforcement points, brokered support access, and negative tests.

Frequently Asked Questions about authorization-matrix-designer

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design a deny-by-default authorization matrix for a multi-tenant application?

A deny-by-default authorization matrix explicitly defines roles, permissions, and object-level resource rules across tenants to prevent cross-tenant leaks and IDOR issues before implementation. It maps enforcement points across UI, API, services, jobs, and integrations.

What's the best way to prevent IDOR and cross-tenant leaks when adding sensitive capabilities?

Preventing IDOR and cross-tenant leaks requires an explicit authorization matrix with object-level checks for membership, ownership, and grants. It maps enforcement across all layers and creates negative tests for escalation, revocation, and expired impersonation.

How do I map enforcement points for access control across UI, API, and background jobs?

Mapping enforcement points involves documenting where authorization is checked across UI, API, services, background jobs, integrations, and admin consoles. This ensures consistent permission validation and eliminates ad hoc access control logic.

How do I design brokered support access and impersonation in multi-tenant software?

Designing brokered support access involves defining exact permissions, scope limits, audit expectations, and forbidden actions for impersonation. The authorization matrix specifies negative tests for expired impersonation and cross-tenant access denial.

Can I use this approach to safely migrate roles without breaking existing permissions?

Yes, safe role migration uses additive changes with shadow dual-checks and rollback paths. The authorization matrix ensures new permissions are layered explicitly over existing rules, preventing privilege creep during sensitive capability additions.

What negative tests are needed for a multi-tenant permission matrix?

Negative tests for a permission matrix cover escalation attempts, revocation scenarios, cross-tenant access, and expired impersonation. These denial tests verify that deny-by-default rules and object-level authorization hold under edge cases.