Governance: who may do what, and what it costs

Why an AI platform needs its own permission management

An AI platform needs its own permission management because a chat window without rules passes every question on to every connected system. Once the AI is connected to a company system, the question is no longer whether someone may chat, but which records the AI may read on that person’s behalf.

A ban only displaces usage, it does not end it

Anyone without an approved route takes the next best one. A ban shifts usage into private accounts with public providers, where neither contract nor log nor right to erasure applies. Company data then ends up in a service that nobody in your organisation administers and whose processing you cannot document.

The countermeasure that works is an approved route that is better than the private one. But it has to make four things controllable, otherwise you are merely shifting the risk inwards:

• Which people may use the platform at all, and through which sign-in.
• Which connected systems and which individual tools are open to a person.
• What actually happened, verifiable and exportable.
• What operation costs, itemised and cappable, before the invoice arrives.

These four control points are exactly the areas of the Kisuno admin panel: user management, access rules, audit and consumption.

Where users, roles and groups come from

You maintain users, roles and groups in the admin panel or take them from Entra ID. A role bundles functional permissions, that is, what someone may do in the interface. A group bundles people for access and budget rules. The two can be combined independently.

Local users and connection to Entra ID

Without an identity provider, Kisuno works with local accounts: invitation by link, with the invited person setting their own password. Sign-in via Entra ID or another OIDC provider is supported by the platform and set up for your instance. Once it is in place, everyone signs in via OIDC, the account is created on first sign-in, and the group and role claims from the sign-in token are mapped onto your groups in Kisuno.

Revocation therefore happens at the front door: anyone deactivated in Entra ID can no longer get in and thereby loses all access, including to the connected systems. Automatic provisioning and deprovisioning of accounts via SCIM is planned, but not available today.

What a role defines, and what a group defines

A role governs functional permissions in the platform, for example whether someone may build agents, use web search or open the admin panel. A group governs which data and tools someone reaches and which budget their consumption is charged to.

Invitation, assignment, deactivation

An invitation goes out by email or link and can already carry the target group with it. Membership is applied as soon as the invited person has completed registration. That way nobody starts in a permission-less limbo, and you do not have to add anything after each registration.

There are two ways to end access. Blocking keeps the account but refuses sign-in. Deleting removes the account, conversations and search index entries; a data export for the person concerned is possible beforehand, so that both access requests and erasure requests are served.

Permissions down to tool level

Tool calls run through the MCP gateway, a component between the chat and the connected system. For the requesting person, the gateway checks whether the server and the specific tool are allowed, records the decision and forwards the call only if it is approved. Blocked tools do not appear in the user’s tool list; after a permission change this takes effect with a short delay. The actual barrier is the check on every single call.

Systems are connected via MCP, the open standard for tool access by AI models. The gateway sits in front of it so that approval is decided centrally per person, role and group instead of being scattered across the connected system. Which systems can be connected and which ones are prepared is described on the Integrations page; permissions without tools are moot.

The example: reading invoices yes, reading payroll no

A connected ERP does not offer the AI a single door, but many individual tools: search invoices, read customer data, read payroll data, write records. The Accounting group is granted the invoice tools, while the payroll tools remain reserved for HR. Same server, different tools, decided separately.

Beneath that lies a second boundary. If Kisuno signs in to your ERP with the identity of the respective person, that system’s own access rules remain decisive: anyone who may only see certain records there sees no more through the AI either. If the connection runs through a shared service account, the gateway is the only enforcement point, and the tool selection then has to be cut correspondingly tight.

Permissions inside a tool, that is on individual fields or rows, are not enforced by Kisuno itself. That is the job of the connected system’s permission management. A tool with a broad range of functions should therefore either not be released at all or only to a group that is allowed to see the data anyway.

The rule chain: user before role before group before default

Permissions are evaluated in a fixed order: individual user, then role, then group, then the server default. The first matching rule decides, and no further search follows. Every decision is therefore explainable, and a one-off approval needs no special role. The fact that permissions apply per individual tool is the distinguishing feature in the comparison with other platforms.

What happens when no rule applies

If no user, role or group rule applies, the default of the respective server decides. Set this default to deny immediately after connecting a system and then release individual groups deliberately. That way a freshly connected system cannot accidentally let anyone see more than intended.

If the permission check itself fails, for example because the rule database is unreachable, the gateway denies the call instead of letting it through. A malfunction therefore leads to an error message in the chat, not to open access. A read-only switch per server that blocks all writing tools at once is planned.

Audit: every access traceable

Every tool call through the gateway is recorded with time, person, target system, tool and decision, including denied ones. In addition, the platform keeps a continuously chained log of admin actions, sign-ins and permission changes. Both logs reside in your own instance and can be exported as CSV.

What is logged

• Tool calls to connected systems, with the decision taken, allowed or denied.
• Sign-ins to the platform and to the admin panel.
• Changes to roles, groups, permissions and access rules.
• Changes to the configuration of the instance.
• Creating, inviting, blocking and deleting accounts.

The audit log is a record of access, not a transcript of conversations. It answers who called which tool on which system and when. The conversations themselves are stored separately in your instance’s database and are subject to the configured retention period.

How long it is kept and where it can be exported

The logs stay in your instance, in your database. When you self-host, they never leave your infrastructure. The export is CSV, filtered by period and person, and can therefore be handed straight to an audit, to the legal department or to an audit tool.

The log of admin actions is chained: every entry carries a checksum over the preceding one, and a built-in check reports when the chain no longer adds up. Removing individual entries after the fact is thus noticed. For conversations the retention period is configurable; expired content is removed together with its search index.

Making costs visible and capping them

Consumption is recorded per person, group, model and day and reported both in tokens and in euros. A shared monthly budget caps the total for the whole organisation; an optional monthly limit per person caps individual accounts. Once a budget is used up, a soft block takes effect.

Consumption per person, group and model

The admin panel shows consumption in euros, broken down by person, by model and by day, along with the individual requests including model and timestamp. Amounts and breakdowns are visible to administrators; end users only get a note in the chat when the budget is exhausted. This takes cost pressure out of everyday work while keeping the figures visible where they belong.

Prices are stored per model so that the evaluation is not based on an approximation. This matters more than it sounds: for the same conversation, a frugal model and a very large one differ by a multiple in cost. A curated model selection is therefore part of cost control, not just a question of usability.

A shared monthly budget instead of individual limits

The monthly budget applies to the organisation as a whole, not per head. The reason is practical: consumption is never distributed evenly. Heavy users would get stuck on a rigid individual limit while other people’s allowances expire unused. A shared pot balances that out without anyone having to readjust limits.

For outliers there is also an optional monthly limit per person. It is switched off until you set it and is enforced strictly in the same reconciliation run as the overall budget. Typical use: a single account that sends automated requests should not drain the shared pot on its own.

A soft block instead of a silent overrun

Once the budget is used up, the soft block takes effect: the next request is refused, with a note in the chat instead of silently continuing to bill. A response already in progress is still completed. The admin can raise the budget at any time, after which operation resumes immediately. Without such an increase, no additional charge arises.

The reconciliation between recorded consumption and budget runs every minute, and the advance estimate of a request does not know its exact length. A single response can therefore still run slightly over the limit. This is a soft block that prevents runaway costs, not a second-by-second advance reservation.

Approving agents instead of banning them

Agents and skills are released in a curated way, neither allowed across the board nor banned across the board. Ordinary accounts use the agents assigned to them and never see the agent builder. A privileged role creates and shares agents, and the admin releases skills per person.

The reason lies in the permissions: an agent comes with a fixed set of instructions and a set of tools. If everyone could build and share their own agents, a second, uncontrolled distribution channel would appear alongside your rule chain. The gateway’s permission check would still apply to every call, but the overview of who works with what would be lost.

In practice this results in a few well-maintained agents per group instead of many half-finished ones: one for drafting quotes, one for evaluations from the ERP, one for internal knowledge search.

Frequently asked questions