Tech USP: The assistant gets no door of its own into your data. It uses the one that already exists, with the asking user’s roles, the access rules you already have, and one audit record per executed tool call.
Buyer’s view: A review asks what happens when someone talks the AI into something. With Kumiko: nothing the human at the screen was not allowed to do anyway. Everything that did happen is in the audit trail.
The problem: “please ignore your instructions”
Plenty of AI assistants secure themselves in the system prompt: “never delete data”, “ask before making changes”. That is a request to a language model, not a boundary. Rephrase the prompt and you rephrase the rule with it, and the assistant still holds whatever technical access it was given at setup time: usually a service account with wide rights, because it has to work for every user.
How Kumiko solves it
The catalog belongs to the caller, not to the model
The tool catalog is rebuilt per request: from the registry the server already composed, filtered by the calling user’s roles, then filtered again by that user’s permission rules and the tenant’s mode. A handler this user may not call does not appear in their catalog. The model does not know it exists, so it cannot propose it.
Visibility is fail-closed on top of that: a handler without a description stays invisible no matter which roles the caller has. A new feature does not slip into the catalog because somebody forgot to lock it down.
Dispatch runs as the real user, not as a service account
Every tool call takes the same query and write paths a click in the UI would take, with the caller’s identity, never a system user. Access rules, validation, hooks and projections all run as usual. There is no second, more privileged route into the data that would have to be secured separately.
The way back is covered too: after a successful write the agent reads the record back through the ordinary detail query, so field-level read rules apply before the model sees anything. The raw write result never goes back to the model.
Approval per action: four answers instead of one switch
In the default mode a proposed write is not yet a write. It becomes a card:
| Answer | What happens |
|---|---|
| Run | The handler dispatches once, as the calling user |
| Check in the form | The app’s own edit screen opens pre-filled; saving or cancelling reports back to the card. Nothing is written in between |
| Always | Stores a standing rule for this handler so the next call skips the card. Refused for handlers that declared risk: "high", and the edit add-on has to be mounted for the rule to be stored |
| Drop | Nothing runs, the conversation continues |
The settings inside the chat layer show the user what they have granted, delete a single rule, or reset all of them. Rules exist at user and tenant scope, never beats everything, and the default without any rule is ask. A tenant can therefore write its policy up front instead of waiting for someone to answer the first card.
The tenant sets the ceiling, the client can only lower it
| Mode | What the agent may do |
|---|---|
read-only |
Query handlers only. No write ever reaches a card |
approval |
Reads, plus writes as proposals a human answers. The default |
edit |
A write with a standing rule and a risk below high dispatches without a card. Everything else still asks |
edit is not a config value you can simply type: the option only exists when the feature is mounted for it and the paid edit add-on is in the registry. Miss either one and boot fails rather than silently running in the weaker mode. In the other direction the server clamps: the client may narrow the mode for a conversation, never widen it.
Every executed tool call is audited
An executed tool call lands as its own audit record alongside the audit entry of the handler it invoked. “What did the assistant do here?” is answerable after the fact, with time, user and handler.
The conversation turns themselves are declared personal data and keyed to their author. A GDPR anonymize crypto-shreds them rather than leaving old prompts readable; export and erasure requests are served like any other user-owned data.
What it is not
- Not an autonomous agent: A turn only ever starts from a person typing or speaking in the chat layer. No scheduler, job or webhook starts one, and nothing runs while nobody is looking
- No undo: An executed tool call is an ordinary write with ordinary consequences. Reversing it means the same handlers a human would use. This is why
risk: "high"can never be answered with “Always” - No memory across conversations: The model sees the turns of the conversation it is in, and nothing else. It does not learn your tenant’s habits between sessions
- No substitute for role design: The catalog is only as narrow as the roles you handed out. Give every user admin and you give the assistant admin