Admin panel

The admin panel is the interface through which Kisuno is administered: accounts, roles, groups, connectors, models, usage and logs. This page gives the overview; the individual areas are described in the following chapters. It is aimed at the person who looks after the instance.

Access

The panel is reachable at an address of its own that belongs to your installation. You sign in with your administrator account. Whoever has the administrator role gets in, nobody else. If an account is blocked or its role withdrawn, that takes effect here as well.

Recommended: protect administrator access further

The stricter requirements apply to administrator accounts. Two measures belong in every production setup:

• Enable two-factor sign-in for every administrator account.
• Restrict access to known networks, for example to your VPN or an IP allowlist. The panel is used by few people in day to day work, so restricting it costs nothing.

Put both on your acceptance checklist and verify them actively once the instance is set up.

What you do there

The interface is divided into four areas:

Area	What for
Analysis	Key usage figures and the logs
Administration	Users, roles, groups, access to connectors and agents
Finance	Usage per person, budgets and billing receipts
System	Configuration, audit log and the settings of the instance

For every person two detail views can be opened: their usage in detail, and an overview of what that person may do and why. The second one is the first tool to reach for when somebody reports that they cannot see a connector or a model.

Two basic principles

Saving is explicit. The panel works with a working copy and only writes when you save. As long as changes are open, the interface points this out.

There are no plain text secrets. Access keys are only stored as a reference, never displayed in plain text and mentioned in logs by name only. Connection tests run server side; the key does not leave the server, not even in error messages.

Order for a new admin

When you take over a fresh instance, this order makes sense, because the steps build on one another:

1. Restrict registration to the email domains of your company.
2. Set a monthly budget, at first without hard enforcement, so you can see for a month where you actually land.
3. Create groups; they are the basis for access and models.
4. Define per group which models are visible.
5. Connect the connectors and grant access to them deliberately.
6. Invite your team.
7. Define the retention period to match your deletion policy.

Setup documents

The step by step instructions for setting up your instance are part of the delivery and are handed over to you together with the installation.

Further in this chapter

Users, groups and rolesInvite and create accounts, assign permissions, block and delete.

Models and model cardsDefine cards and control their visibility per role and group.

Usage, budgets and billingFrom tokens to euros, budget, monthly limit, receipts.

Logs and auditUsage log and change history.

Data protection and retentionRetention, disclosure, telemetry and what leaves the instance.