Permission Drift Audit

Verify that permissions remain correct as objects evolve through their lifecycle. Permissions are not static: they change when teams change, projects are duplicated, visibility is toggled, users are removed, and URLs are shared. This audit catches the class of bugs where access controls were correct at creation but have drifted out of alignment with intent.

## Key Points

1. User A is the owner of Project X with Assets, Scenes, and Settings.
2. Add User B as a collaborator on Project X.
3. Verify User B can access: Project X, its Assets, its Scenes, its Settings.
4. Remove User B as collaborator.
5. Immediately test User B's access to each resource.
- [ ] User B cannot access Project X (403 or 404).
- [ ] User B cannot access any Asset in Project X.
- [ ] User B cannot access any Scene in Project X.
- [ ] User B cannot access Project X Settings.
- [ ] User B cannot access Project X via direct URL.
- [ ] User B cannot access Project X via API with known IDs.
- [ ] User B does not see Project X in any listing (projects, search, recent).

## Quick Example

```
[ ] Duplication creates new ACL records (deep copy)
[ ] ACL entries reference the new project ID (not old)
[ ] No shared foreign keys between original and copy ACLs
[ ] Duplication includes sub-resource ACLs (scenes, assets)
```

```
[ ] Permission cache TTL is short (< 5 minutes) or invalidated on change
[ ] OR permissions are checked live on every request (no cache)
[ ] Role change triggers cache invalidation for affected user
[ ] JWT tokens do NOT embed permissions (or have short TTL)
    If permissions are in JWT: role change requires token refresh
```