DocsSign inInstall Kastel
Context governance

Sharing your context with an AI is not the same as governing it.

A sharing preference sets what an AI can read right now. It is a setting, and a setting has no memory. Context governance records every access decision: who made it, who approved it, when it changed. The first has to be taken on trust. The second can be proven to an auditor, a customer or a regulator.

Published July 31, 2026

Your company’s knowledge has no owner

Your company’s knowledge is scattered across the drive, the inboxes, the CRM and people’s heads. Nobody owns it, and it goes stale over time. An AI plugged into that mess gets things wrong with confidence, which is worse than no AI at all.

There is a third weakness, and it is the one nobody sees: nothing traces who is allowed to see what. Every tool offers its checkboxes, but a ticked box says nothing about who decided, since when, or why. The day someone asks you to account for it, there is nothing to show.

A sharing preference is a setting

Everyone in this category offers you the same thing: you tick which tools and which files an AI may read. That is useful, and you do need it.

But a setting only describes what is allowed right now. It does not say what was allowed last month, who decided it, or who signed off on it. When you change it, the previous state is gone. Nobody can contradict a setting, and that is exactly why nobody can prove one.

Provable governance is a recorded decision

Kastel is a context layer: the structured memory of your company, holding its organisation, its processes, its responsibilities and the history of its decisions. Kastel is not an AI. It is what the AIs you plug in come to read, and what the product does comes down to three mechanisms.

01

One standard socket, not one integration per tool

AIs connect to your Kastel over MCP, a standardised power socket for AI: a universal port through which an AI tool reaches a company’s context. Any compatible AI plugs in, reads what it is allowed to see, and gets to work. Swapping AIs is unplugging one appliance and plugging in another on a standard wall socket: nothing to move out.

02

Read access attached to responsibility

In Kastel, the right to read is not a checkbox per tool. It is attached to each person’s responsibility within the organisation: who decides what, who is allowed to see what. An AI working for someone reads only what that person is allowed to read, and when the person changes roles, the scope follows. You decide what each AI is allowed to see, and the rule that decides it is written down, not ticked.

03

Approved changes, a sealed audit chain

A change to the context never takes effect silently: it goes through a review flow where a human approves the exact effect, not a vague intent. And every decision is written to a sealed audit chain: each entry is linked to the one before it, so tampering with the history afterwards breaks the seal and shows up at verification. You verify the history instead of trusting it. This is the core of our security posture.

A third party’s question, and what each approach can answer

The difference between the two approaches shows up the day an outsider asks a question. Test every line yourself: on a sharing setting, go looking for the history; on Kastel, install the free core and ask for it.

The question askedA sharing settingA governed decision
What is this AI allowed to read today?Yes: the list of boxes ticked at this moment.Yes: the scope attached to each person’s responsibility.
What was it allowed to read three months ago?No. Changing a setting overwrites the previous state.Yes: the history of access decisions is kept, decision by decision.
Who granted this access, and who approved it?No. A ticked box carries neither an author nor an approval.Yes: every change is a recorded decision, with its author and its approver.
Can you prove it, without anyone having to take your word for it?Hardly: at best a per-tool admin log that shows who clicked, never the decision or its approval.Yes: the audit chain is sealed and verifiable; the external anchoring that proves it to a third party belongs to the Enterprise plan.

The day someone asks you to account for it

An auditor, a major customer or a regulator always ends up asking the same question: what was this AI allowed to consult, and who decided that? On that day, a setting has no answer, and a sealed chain does.

The three objections we hear

Almost nobody starts from nothing. These are the three most common starting points, and what each one does and does not hold.

You don’t have to take our word for it

Everything this page describes can be checked without talking to us. Install the free core on your own infrastructure, plug in your own AI keys, and watch what the audit chain records when you change an access rule. Export everything whenever you want: your context stays in the fortress, and it goes with you if you leave.

Kastel is not exempt from its own rule: full export at any time, free self-hosting for life. You can check every one of these claims yourself.

What is free, and what is not

You never pay for governance in Kastel. Responsibility-based scopes, human approval of changes and the sealed local audit are part of the free core, self-hosted, with no size limit. That core is operated through the command line and MCP: the web console comes with managed hosting or with the Enterprise plan.

What belongs to the Enterprise plan is the organisation-scale audit file: consolidated audit across deployments, external anchoring of the audit chain, signed attestations and the AI Act compliance package. Installing the free core gets you governance; the enterprise audit file you can hand to an auditor is what you pay for.

Is there an auditor across the table?

If your next compliance review raises the AI question, let’s talk about what your organisation must be able to prove, and how Kastel records it.

Talk to a human