Accounts and access

This section is for the people who administer Kuumba for an organisation. Everything above it is written for the people using it.

Accounts

Access is managed centrally. A person can sign in only once their account has been created and given access — there is no self-service sign-up, and a user cannot grant themselves anything.

That means two things in practice:

• Starting someone is an administrative act, not an invitation they accept.
• Stopping someone is immediate and complete. Revoke the account and every session, chat and connector belonging to it stops working.

What you control

• Which models are available, and which is the default.
• Which capabilities exist at all: web search, memory, artifacts, file upload, sharing, temporary chats.
• Which apps can be connected, and whether users connect them themselves.
• Who can build and share bots beyond their own account.

Turning a capability off is not retroactive

Disabling a capability stops future use. It does not remove what people already produced with it — shared links already created, for instance, keep working until they are revoked.

Reviewing access

Review three things on a schedule rather than on an incident:

1. Accounts — leavers, and people whose role has changed.
2. Connected apps — every connector is a standing grant to a real mailbox or drive.
3. Shared links — they are public to anyone holding the URL.