For AI agents: the complete documentation index is available at https://payhon.github.io/AppKernia/en-US/llms.txt, the full documentation bundle is available at https://payhon.github.io/AppKernia/en-US/llms-full.txt, and this page is available as Markdown at https://payhon.github.io/AppKernia/en-US/concepts/permissions-tenancy.md.
AppKernia

Authorization and multi-tenancy

AppKernia separates visibility from authority:

  • sys.menus describes Admin navigation.
  • iam.permissions.code, such as iam.user.read, is a backend authorization fact.
  • A hidden button improves UX but never replaces API authorization.
  • tenant_id comes from a verified session context, never from an untrusted body or query.

Menus and buttons can prevent an invalid action early, but authority starts with the session, audience, and tenant context and must end in backend permission checks and SQL data scope.

Roles use all, tenant, department, department_tree, self, or custom data scopes. Repositories translate effective scope into SQL conditions; filtering a full dataset in Go or the client is prohibited.

With multiple roles, the application computes effective scope from the current tenant, role validity, and organization relationship before a repository builds parameterized SQL. A tenant switch clears protected client cache so data from the previous tenant cannot be reused accidentally.

ClientRoute prefixAudience
Mobile/api/v1ak-mobile
Admin/admin-api/v1ak-admin

Even for the same user, Admin tokens cannot act as Mobile sessions and vice versa.