arbazkhan971 Activate When
/godmode:rbac, "permissions", "access control"- "roles", "who can access", "authorization model"
- Building features restricting authenticated user actions
Workflow
1. Requirements Discovery
App type: monolith|microservices|multi-tenant SaaS
Complexity:
Simple roles (admin/user/viewer) -> RBAC
Dynamic attributes (time/location) -> ABAC
Resource relationships (owner/member) -> ReBAC
Combination -> Hybrid
# Detect existing auth/authz
grep -rl "role\|permission\|authorize\|can\?" \
--include="*.ts" --include="*.rb" --include="*.py" src/
2. Permission Model Selection
RBAC (Role-Based):
Role hierarchy:
super_admin -> org_admin -> team_admin -> member
Permissions: create|read|update|delete per resource
Role-permission mapping table
IF roles < 10 and stable: pure RBAC is sufficient.
ABAC (Attribute-Based):
Policy: (Subject, Resource, Action, Environment) -> PERMIT|DENY
Subject: user.role, user.department, user.clearance
Resource: resource.owner, resource.classification
Environment: time, IP, MFA status
IF decisions depend on context (time, location): ABAC.
ReBAC (Relationship-Based):
Tuples: user:alice has owner on document:doc1
Inheritance: owner implies editor implies viewer
Tools: OpenFGA, SpiceDB, Ory Keto
IF Google Docs-style sharing model: ReBAC.
3. Role Hierarchy
Strict (tree): each role has one parent
Lattice (DAG): roles can have multiple parents
Scoped: roles apply within scope (org/team/project)
IF > 20 roles: audit for overlap and consolidate. IF unused permissions for 90+ days: flag as excessive.
4. Resource-Based Access
Every resource has:
owner_id (full control)
tenant_id (isolation boundary)
visibility: private|team|organization|public
Evaluation chain:
1. Owner? -> ALLOW
2. Super admin? -> ALLOW (audit logged)
3. Explicit permission? -> Check
4. Role-based? -> Check hierarchy
5. ABAC policy? -> Evaluate
6. Default: DENY
5. Policy Engine
function evaluate(subject, resource, action, context):
denials = findMatchingPolicies(DENY, ...)
IF denials.length > 0: return DENY
allows = findMatchingPolicies(ALLOW, ...)
IF allows.length > 0: return ALLOW
return DENY # default deny
LOG every decision (ALLOW and DENY) with full context.
6. Audit Logging
Every authorization decision logged:
timestamp, subject, resource, action,
decision (allow/deny), policy_id, reason
Storage: append-only or write-once
Retention: minimum 1 year for compliance
IF audit log not append-only: security risk. IF no audit log: MUST implement before launch.
Quality Targets
- Target: <10ms permission check latency
- Target: 0 privilege escalation paths in role hierarchy
- Policy evaluation: <50ms for complex multi-role checks
- Target: 100% of endpoints covered by authorization middleware
Hard Rules
- DEFAULT DENY — no policy match = DENY.
- NEVER check roles in code — check permissions.
- NEVER frontend-only authorization (backend enforces).
- NEVER bypass policy engine (even super_admin).
- NEVER allow escalation via delegation.
- NEVER grant permanent admin (use time-limited).
- ALWAYS log ALLOW and DENY decisions.
TSV Logging
Append .godmode/rbac-decisions.tsv:
timestamp model roles permissions resources audit verdict
Keep/Discard
KEEP if: permission checks pass AND no escalation
AND audit captures allow/deny.
DISCARD if: unauthorized access possible OR
audit broken OR permissions regressed.
Stop Conditions
STOP when FIRST of:
- All resources have permission mappings
- Default deny enforced every endpoint
- Audit logging covers all decisions
Autonomous Operation
On failure: git reset --hard HEAD~1. Never pause.
Error Recovery
| Failure | Action |
|---|---|
| Legitimate request denied | Check audit log, verify hierarchy |
| Escalation possible | Fix policy, test both directions |
| Missing audit entries | Verify middleware, check async flush |