One appliance, a whole team.
Kautuka can serve one person or a small team from a single install. The first account is created on first run; everything after that is managed by an administrator, from the interface rather than a directory service you have to wire up.
The first administrator
The first-run page creates the first administrator account, and the password must be at least eight characters. The person who can open first-run becomes the administrator, then continues into onboarding to set up a provider, a model, and an agent.
An administrator is the only account that can manage providers, models, agents, users, organisation settings, and advanced options.
Signing in with Google or Microsoft
Google and Microsoft sign-in are available only when the appliance is configured with the hosted auth broker and that provider’s public client ID. A source checkout keeps the local username and password form instead.
The durable link between a person and their provider account is the provider’s subject identifier. Changing a user’s email address does not move that link. Removing a user’s last remaining sign-in method is rejected, and there is no email password reset.
After the first sign-in, set a local password as a second way in.
Inviting people
Invite someone from Settings → Users using the email address their Google or Microsoft account will verify. A username and secret phrase are only for local sign-in, and an invited account with no secret phrase simply has no local password until that person sets one.
Every later social sign-in must match one active invited user by verified email. This is not Microsoft Entra tenant membership and not a domain allowlist — it is an explicit invitation.
Limiting what people can reach
- Agent access can be limited to selected agents, so a person only sees the ones they should use.
- Deactivation blocks authenticated use without deleting the person’s records.
- Sign-in links can be removed by an administrator for another user, which signs that person out. Removing your own link does not sign you out.
- Self-service lets people change their own profile, password, and channel settings from the profile dialog.
- Channels can also be configured for a user by an administrator, including running a channel test.
Administrator routes are enforced by both the interface and the appliance’s authorisation. A hidden tab is not the security boundary.
Organisation defaults
Settings → Organisation stores an organisation name and industry. These become default persona context, and an individual agent’s persona can override them. Leaving both blank is supported.
Technical details
Setup and session: /api/auth/setup/status, /api/auth/setup, /api/auth/login, /api/auth/refresh, /api/auth/logout, /api/auth/me.
Social sign-in: /api/auth/external/providers, /api/auth/external/start, /api/auth/external/complete, with the browser returning to /login/callback.
Users: /api/settings/users, /api/settings/users/{userId}/..., /api/settings/users/{userId}/external-logins/{provider}. Self-service: /api/settings/me/profile, /api/settings/me/password, /api/settings/me/channels, /api/settings/me/external-logins/{provider}. Organisation: GET/PUT /api/settings/organization.
Verify with a separate non-admin account: confirm it sees only permitted agents, cannot open administrator settings, and can update only its own profile and channels.