Who has access, who decides, who consulted what.

In the console if we host your Kastel, or if you host it yourself on Kastel Enterprise: the “Who decides” tab of a department, on My Kastel.

On the command line if you host Kastel yourself on the free plan, which has no web console: kastel aor show, kastel read-audit.

What this page describes is the same capability on both sides. What changes is the surface.

Every person in your company has a scope: the departments and documents they are allowed to read. That scope is the only thing that decides what gets served to them, and it applies the same way everywhere - in the console, in answers, and through connected AIs.

Here is the consequence that matters most: an AI plugged into your Kastel never sees more than the person it works on behalf of. You do not set an AI's permissions; you set a person's, and the AI inherits them.

Scopes are edited department by department. Before anything is applied, your Kastel shows you the impact: which pages would become visible, which would be hidden, and for whom. Then you apply, or you do not. Every applied change is dated, attributed to its author, and reversible with one button.

Every department has a head. They arbitrate in their department, and approval requests concerning it route to them. With no head named, requests escalate to leadership: the executive sees everything, all the time.

Alongside the head, you can write approval rules: a category of action that must always go through a human, described in your own words (“discounts above 15%”, “any reply sent to a client”). These rules apply to everyone, humans and AIs. An AI may ask for one more approval if it is unsure; it can never remove one. The rule commands, not the model.

What these rules cannot do is stated just as plainly: Kastel holds them wherever Kastel is the executor. When the action runs inside the connected AI's own tools - sending an email, making a payment - your AI tool executes it and Kastel never sees it.

The matrix above says what is written down. Your Kastel can also say something else: who actually wrote and maintained the pages on a subject. The two do not always match, and the gap is worth seeing - it is often the first thing an executive discovers about their own organisation.

This view sits under the declared rules, in a department's “Who decides” tab. It renders both registers without merging them, and computes no score: these are counts, not an evaluation. From a connected AI, the same answer comes from simply asking the question.

• A failed read is never an empty list. “This list could not be loaded” and “nobody has left a trace” are two different sentences, and your Kastel does not confuse them.
• An incomplete list says so before it renders, and still shows what it has.
• Pages held back by your policy are counted separately and named, never silently dropped from a total.
• Everything is derived from the pages you can consult. Someone whose work falls outside your scope does not appear.

Two notions look alike and do not replace each other. The role - owner, administrator, member, auditor - says what you may administer: add someone, change a setting, decide an erasure. The scope says what you may read. An administrator does not thereby get access to all content; a member with no administrative role may well hold the broadest scope in the company.

A few actions are reserved for owners and administrators because they commit the whole company, not because they read more: switching on or off what runs by itself, deciding an erasure, launching an operation that spends your AI keys.

Knowing who has access is one thing; knowing who has consulted is another, and it is the one your auditor will ask for. Your Kastel keeps that journal, on your own instance, and passes it to nobody.

It keeps two layers, and they do not say the same thing:

• Counters aggregated per day, sealed into your instance's audit chain: which actor consulted which entity or department, how many times, on a given day. No page text, no paths in the clear. That is the layer you can put in front of an auditor, and it is never pruned.
• A local per-person record: which page, which day, how many times, and what kind of consultation - the page opened, a weekly-check question consulted, or a page cited in an answer. That record stays on your instance, is kept for thirty days by default, and the retention is a setting - including zero, if your company would rather record nothing per person.

The wording matters: these counters say what was consulted under the caller's own rights. It is an honest superset of what was actually served to a model, and the unit is the page per call - a seven-section page never counts as seven consultations. This is not a timestamped view-by-view log, and your Kastel does not claim to keep one.