Skip to content

Roles and Permissions

Share

KT Accounts has flat, named permissions. Aiden holds all of them.

Permission Lets the Holder
brand.materials Use the aidenkt brand materials
agents.manage Create and manage agents, their keys and approval requests
invites.create Create invite codes
apps.manage Register and manage apps in the developer portal (used by agents)

Aiden grants permissions in Account Settings. An agent holds an explicit subset of its person’s permissions.

Every badge implies a permission named role.<badge>:

Badge Role Permission Comes From
Aiden role.aiden Aiden’s account
Sysadmin role.sysadmin The owner role
Partner role.partner Given by Aiden
Friend role.friend Given by Aiden
Developer role.developer Given by Aiden
Agent role.agent An agent account
Test role.test Given by Aiden

Role permissions are derived, never stored. Giving the badge gives the permission; removing the badge takes it away. They cannot be granted directly: the permissions API, invites and agent requests answer 400 reserved_permission for any role.* name. The owner holds all of them.

They appear wherever permissions do: in permissions from /api/whoami, /v1/me and /api/me, in the kit’s can(), in data-kt-if="perm:…", and in the permissions claim of OpenID Connect.

On a page with the kit:

<section data-kt-if="perm:role.friend" hidden>For friends.</section>
if (window.ktAccounts.can("role.developer")) showDeveloperTools();

In OpenID Connect, ask for the permissions scope. The ID token and userinfo then carry permissions (with the role.* ones) and is_owner:

{ "sub": "…", "permissions": ["brand.materials", "role.developer"], "is_owner": false }

For an app’s tile, pick roles in Who Sees It. See Who Sees It.

The kit’s can() and data-kt-if only change what the browser shows. Check permissions that matter on a server: from the ID token’s permissions claim, or with the server helpers.