In the console (hosted plans, or self-hosted Enterprise): Settings, then “My account”, in the list of people in your workspace - “Remove”. Reserved for owners and administrators.
On the command line (free self-host): access is managed with kastel token and identity with kastel identity unlink.
Removing is not erasing
Two requests often arrive together, and they do not have the same answer. “This person has left, cut their access” is handled here, in a minute. “This person is exercising their right to erasure” is another procedure.
A departure never deletes content. What the person wrote, decided and approved remains your company's knowledge. That is the most important point on this page, and it is said up front rather than after the fact.
Cut the access with this page first, then follow the erasure procedure: it says what goes, what stays, and why.
Read the GDPR erasure pageThe gesture, and what it cuts
One gesture, from the list of people in your workspace: select, then confirm. In the same operation it cuts:
- Every AI the person had connected in their name, immediately.
- Their session, on their next action.
- Any sign-in link not yet used, and any export download link in flight.
- Their seat, which becomes available again in your plan.
The removal is recorded as a sealed event on your organisation's audit chain.
An access an AI already holds stays valid until it expires, at most fifteen minutes. It cannot obtain a new one. We say this rather than implying a millisecond cut-off: fifteen minutes is a good answer, and being caught not saying it is not.
Three possible refusals, and what to do
| What your Kastel says | Why | What to do |
|---|---|---|
| This is the last owner | With no owner, nobody manages the subscription, receives a recovery link, or changes the company sign-in | Name another owner first |
| An owner cannot be removed from the console | The console cannot appoint one either: the two go together | Go through your Kastel contact |
| You cannot remove yourself | Prevents accidental lockout | Ask another owner or administrator |
What is not cut - to check
Two kinds of access belong to the company rather than to the person. The removal does not touch them, and that is usually what you want - but you need to know.
- An inherited shared key. Some companies once created a read-only key in nobody's name, to plug in an AI. That kind of access can no longer be created, but if one exists at your company, it keeps working after a departure. It is managed on the “AI access” screen: review it, and cut or rotate at the slightest doubt. The cost is one re-paste for the colleagues still using it; the risk of doing nothing is larger.
- Tool connections (Notion, GitHub, Google, Slack...) the person authorised. They belong to the company and keep working, which stops a departure from breaking your syncs. To cut one deliberately, remove it from the company sources.
Attribution: the name can stay visible
Cutting access opens no door for the person any more. But their name stays attached to their record in your Kastel: they can therefore still appear in an answer to “who decides on this subject?” or “who actually handles it?”.
That is often desirable - the history of who decided what is not rewritten. If you want the name to stop appearing in those answers, the account has to be unlinked from the record: kastel identity unlink followed by the email address, on a Kastel you host; through your Kastel contact if we host it. This gesture deletes nothing: it stops the attribution.
What stays, on purpose
- Approval requests the person opened stay pending. They are company decisions someone still has to make; a departure never deletes them silently.
- Sealed audit events stay. A departure does not rewrite history.
- Export archives already produced stay for as long as their own deadline provides.