AutoCore Authorization and Ownership
Explains layered guards, dealer scope, resource ownership, and service-level checks.
A visible control is never the authorization boundary. AutoCore combines authentication, role rank, fine-grained permission checks, dealer membership, ownership, state, and configuration checks.
Release candidate source
This article reflects the audited AutoCore source revision 7a504f6e430c16d4fcb03ebdea3cc3fb7816df60 and immutable release-candidate tag v1.0.0-rc.1 at 9edfb109f44cc80385784c694b96392cfc04e70f. Configuration and external provider behavior remain deployment-dependent.
Source boundary
| Control | Source-verified behavior |
|---|---|
| Roles | Global roles are user, moderator, admin, and super_admin; dealer roles are owner, manager, and staff. |
| Permissions | The source contains 156 canonical permission keys; required permissions are evaluated by the API guard. |
| Ownership | Listing, media, dealer, and user operations apply resource-level checks after route authorization. |
| State | Expected timestamps, lifecycle transitions, and feature flags prevent stale or unsupported mutations. |
| Super admin | Super-admin privilege is protected by grant/revoke and last-admin safeguards. |
Operational controls
Use the smallest verified control for the task. Keep provider, host, legal, and operator responsibilities separate from application behavior. When a control is not implemented or not verified, leave it disabled or mark it as a limitation.
Verification
Verify the route, relevant API or configuration state, negative path, audit/evidence result, and public effect before closing the task. Record unknown or configuration-dependent behavior as a limitation.