Run One Assistant for a Whole Institute or Company, and Hand It Over

T02-L05 · Chat & assistants · Level 5 Operator · 20-minute read, plus 5 hours of doing

Two people left, their access didn't

The group assistant from last spring is now the institute's assistant. It runs on a server IT looks after, 180 people in twelve groups use it, and it answers from a local model and, for some groups, a hosted one. This month two postdocs left. Their university accounts were closed on their last day, but both still had working accounts on the assistant: they had been created with passwords during the pilot, before the university login was connected. One group's bill for the hosted model tripled, and nobody could say why until IT found a student's script calling the assistant with a personal key, 4,000 times a night. And while chasing that, IT noticed the server logs held the full text of every question since June, because someone had turned logging up to debug a problem and never turned it down.

In a company it's a 150-person medical device supplier. The quality team's assistant became the company's assistant in the summer. Now the works council asks what is recorded about each employee, the finance director asks what each department costs, and the only person who knows how any of it works goes on parental leave in eight weeks.

You are at Level 5 Operator. When the assistant stops, or lets the wrong people in, work stops or leaks for everyone. This book shows you how to run it: who gets in and how they get out, what it costs per group, what you record and for how long, what you watch, and who takes over.

After this you can

• Put every person behind the organisation's login, close every other way in, and end a leaver's access with one action you have tested.
• List every account, key and emergency access with an owner and a way to revoke it, in an access audit a colleague can repeat.
• Give each group a monthly budget and see cost per group, without per-person monitoring the works or staff council hasn't agreed to.
• Keep only the records you need to run and audit the service, for a period the data protection officer has signed.
• Watch the service weekly, handle an outage or a leaked key from a runbook, and hand it all to a substitute who has run it without you.

Before you start

• Books: T01-L01 for the four-quadrant method. T02-L04 for what Open WebUI keeps and who can reach it. T11-L04 for the server this book runs: Open WebUI, a model and Caddy, the web server in front, each in its own container (one boxed program), started together by Docker Compose, with backups and updates. T12-L04 for locking the server itself.
• Administrator access to the assistant's server, and a contact in IT who administers the organisation's login system.
• Two test accounts in the login system, one ordinary and one to be "offboarded", and permission to disable one of them.
• The people involved: the service owner (the institute's managing director or the company's IT lead), your data protection officer, the staff council or works council, and a named substitute with five hours over the next month.
• About 5 hours 20 minutes: 20 to read, about 5 hours to do, over a month.

Last verified 23 September 2026. Open WebUI and LiteLLM, the budget gateway here, are free and open source. Without Redis, a small helper database, a deactivated Open WebUI user stays signed in until their login expires: four weeks by default. Details for experts at the end of this book.

The idea in one page

A shared assistant has five things someone must run. Each has a question you should be able to answer on any day.

One action for people. Everyone signs in through the organisation's login, the single sign-on (SSO) that already runs email and the intranet. The organisation's IT disables a leaver there, and that one action must end both a fresh login and a session that's still open in someone's browser. Two settings decide whether it does: how long a login lasts in the assistant, and whether the assistant can cancel a session early.

Every other door, listed. SSO only covers people who sign in through it. Pilot accounts with passwords, personal API keys, a script's key, an emergency admin account: each is a door the SSO action never reaches. The access audit lists them all, each with an owner, a purpose and a way to revoke it. Routine password logins are switched off entirely; one sealed emergency account stays, for when the login system itself is down.

Budgets live in a gateway. A gateway is a small program that sits between the assistant and the models, passes every request on, and counts what each costs. This book uses LiteLLM. It can stop a person or a key at a monthly budget, so a runaway script hits a wall instead of the invoice. Groups see their costs as totals.

Records: references, not content. To run the service you need who signed in when, which model was used, what it cost, and errors. You don't need the text of people's questions in your logs. The chats themselves stay in the assistant, where each person can see and delete their own, for a period the data protection officer sets.

A person, not a folder, is the backup. A runbook with a page per situation, and a substitute who has repeated the access audit and the leaver test while you watched without helping.

Worked example: an access audit, a budget and a handover

Both versions follow the four quadrants from T01-L01. Follow the one closer to your work. The people, numbers and settings are examples written for this book.

Lab: the institute's assistant

Structure it (20 min). Lena, who built the group assistant in T11-L04, now runs the institute's service with Paul from IT. After the two leavers she writes: "Anyone who leaves the institute loses the assistant the moment IT closes their university account. Every other way in has an owner. Each group sees its monthly cost and can't overrun it by surprise. We keep only what the data protection officer has agreed. Paul can run all of it without me."

Understand it (90 min). She starts an access audit, a table with one row per way in. Open WebUI's admin panel lists 196 accounts. IT compares them with the university directory: 23 were created with passwords during the pilot, four of them for people who have left. 173 sign in through the university login. Six people have personal API keys, keys that let a program use the assistant in their name, because the pilot's settings let ordinary users create them. One is the student's script.

Then the leaver test, with a test account IT creates for this purpose. The test user signs in and keeps the browser open. IT disables the account in the university directory. A fresh login fails at once. The open browser keeps working: the next day, and the one after. Lena reads Open WebUI's documentation. A login lasts four weeks unless you shorten it, and without Redis, deactivating a user doesn't end the session they already have.

She checks the logs. Open WebUI's audit log, its record of requests, had been set in June to keep full requests and answers. The staff council has never been told that questions were being kept, and neither has the data protection officer.

This changes the problem. She'd thought of it as "connect SSO properly". SSO was connected; the problem is everything around it. Back to Structure it: "The university login is the only routine way in, and a session can't outlive it by more than a working day. Every key is someone's, with a budget. The logs hold references, not questions."

Choose tools (20 min).

• The university login stays the single way in. Open WebUI takes each person's groups from it at every login, as in T04-L04.
• Redis, a small in-memory database, added as one more container on the server. With it, Open WebUI can cancel a deactivated person's session at once. Logins are shortened to 12 hours as a second line of defence.
• LiteLLM as the gateway, in its own container, with its small Postgres database for the running totals. Open WebUI sends every model request through it and passes on who is asking; LiteLLM records the cost per person and stops anyone at a monthly limit. IT sums the totals by group once a month.
• Uptime Kuma, a free self-hosted monitor, checks every five minutes that the assistant answers and alerts Paul and Lena when it doesn't.
• The alternative for the gateway is to give each group its own model connection with its own provider key and spending limit. That works for three groups; for twelve it becomes twelve keys to look after.

Build it: close the doors (60 min). Lena changes the assistant's settings in the Compose file, the file from T11-L04 that describes the server's containers. The relevant lines:

  open-webui:
    environment:
      ENABLE_SIGNUP: "false"              # nobody creates an account by themselves
      ENABLE_PASSWORD_AUTH: "false"       # only the university login
      JWT_EXPIRES_IN: "12h"               # a login lasts at most 12 hours
      REDIS_URL: "redis://redis:6379/0"   # lets deactivation end a session at once
      ENABLE_FORWARD_USER_INFO_HEADERS: "true"  # tells the gateway who is asking
  redis:
    image: redis:7

The first two lines close the password route. The third limits how long any login lasts. The fourth connects Redis, which runs as its own small container. The last makes Open WebUI tell the gateway which person each request comes from. She restarts the containers on the staging server first, the test copy of the server from T11-L04, repeats the leaver test there, and only then on production.

Two more changes route the models through the gateway. In Open WebUI's admin settings, under Connections, the model connection now points at LiteLLM's address, with a key LiteLLM issued, instead of at the provider. And one line in LiteLLM's configuration, named in Details for experts, tells it to read the person's name from what Open WebUI sends along.

The 23 password accounts are converted to university logins where the person is still at the institute; the four leavers' accounts are deactivated. Personal API keys are switched off for ordinary users: Lena removes the API Keys permission from the default permissions every user gets. The student's script gets a proper key issued by the gateway, with its own monthly limit, owned by his group leader. Keys like this are created in LiteLLM's admin page under Virtual Keys, then Create Key, where the budget is set too.

One password account stays: an emergency admin, for when the university login is down. It only works after an administrator switches password login back on at the server, which needs the server login only Paul and the head of IT have. Its password sits in IT's password manager, every use is recorded and reviewed, and the procedure is tested twice a year.

Build it: the leaver test, again (20 min). The test user signs in and keeps the browser open. IT disables the account in the directory at 14:00. A fresh login fails at once. The open browser still works: Open WebUI doesn't know yet. So IT adds one step to its existing leaver process: a nightly script that asks the directory which accounts were disabled and deactivates the matching Open WebUI accounts through Open WebUI's API, its interface for programs. At 02:00 the job runs; with Redis in place, the open session ends at once. The stated window: access ends at the next nightly run, at most 24 hours; immediately if IT deactivates by hand. That line goes into the access audit.

Build it: budgets (40 min). Each person gets a default monthly limit of €15 on the hosted model, set once in LiteLLM as the default budget for every person without their own. LiteLLM counts in US dollars, so Lena enters the dollar amount closest to €15. The local model has no limit, because it runs on the institute's own hardware. Two groups with heavy literature work get €40 per person by agreement with the managing director. On the first of each month LiteLLM's totals go into a one-page report: cost per group, the three largest items, and any key near its limit. Individual figures stay in LiteLLM, where only Lena and Paul can see them, to enforce limits and nothing else. The staff council agrees to exactly that in writing.

Build it: records (30 min). With the data protection officer, Lena writes a records table:

The audit log level goes back to metadata: who, when and which request, without any text. The six months of logged questions are deleted, with the data protection officer's agreement and a note in her records. The staff council gets the table.

Build it: weekly watch and runbook (30 min). Every Monday a short post goes to the service channel: availability last week from Uptime Kuma, accounts in the assistant not found in the directory (should be zero), keys near their limit, the date of the last restore test (the last time a backup was actually restored, to prove it works), and any Open WebUI or LiteLLM release waiting to be installed. The runbook has a page each for the assistant is down, a model provider is down, a key has leaked, a budget is used up, a monthly update and someone leaves. The leaked-key page is three steps: delete the key on LiteLLM's Virtual Keys page, issue a new one to its owner, check the key's spending for the last week.

Build it: handover. Paul repeats the full access audit from the runbook while Lena watches without helping: counts accounts against the directory, runs the leaver test, checks the emergency account's alert, reads the monthly report. He gets stuck once, on where LiteLLM's admin password is kept, and the runbook gets the line. In November the university's data protection audit asks for "a list of every account with access to the assistant, and how access ends". Paul sends the access audit.

What it taught her: connecting the login took an afternoon. Finding the doors it didn't cover took a week, and each one had been opened for a good reason by someone trying to help.

Company: the company-wide assistant

Structure it. Jonas, the quality lead from T11-L04, runs the assistant for 150 people; it uses an EU model provider through the company's contract. His deputy, Aylin from IT, takes over in eight weeks. "Everyone signs in with their Microsoft account, and switching off that account ends their access within an hour. Each department has a budget. The works council knows exactly what is recorded. Aylin can run it alone."

Understand it. The company's login is Microsoft Entra ID, Microsoft's account system behind Microsoft 365. Entra can also tell connected apps when an account is created, changed or disabled, through a standard called SCIM, and Open WebUI accepts it. His access audit finds 12 password accounts from the pilot, one shared quality-team account used by three people, and the provider key sitting in plain text in a reporting script on a colleague's laptop.

The works council's first question changes the plan. Per-person costs would show who uses the assistant how much, which is information about employees' behaviour, and in Germany introducing that needs the works council's agreement. Back to Structure it: "Departments see department totals. Per-person figures exist only to stop a runaway, and only two named admins see them, for 90 days."

Choose tools. Entra ID for sign-in and groups, with SCIM so that disabling an account in Entra deactivates it in Open WebUI straight away and ends its session. To connect them, IT switches SCIM on in Open WebUI with a secret token, then in Entra adds Open WebUI as an enterprise application, turns on provisioning (Entra's word for sending account changes), and enters Open WebUI's SCIM address and the token. LiteLLM with a monthly budget per department and a small default per person. The provider's own spending limit on the company account, as a last stop behind LiteLLM.

Build it. The pilot accounts become Entra logins; the shared account is closed and its three users get their own. The reporting script moves to a key issued by LiteLLM, stored in the company's password manager, owned by the finance team. Jonas tests the leaver path with a test account: IT disables it in Entra at 10:00; SCIM reaches Open WebUI within minutes and the open session ends at 10:07. The works council signs an agreement with the records table attached. Aylin runs the audit, the leaver test and a monthly update from the runbook while Jonas watches, and in her second week handles a real case alone: a department's budget runs out on the 20th, and the runbook says who may raise it.

In both cases the login was never the problem. The doors next to it were, and the decisions nobody had written down: what's recorded, what each group may spend, who takes over.

What goes wrong

Pilot accounts outlive the pilot. Symptom: people who left still sign in with a password from the early days. Fix: switch off password logins and sign-up entirely once SSO works. Keep one sealed emergency admin account, with an alert on every use.

Disabling a person doesn't end their session. Symptom: the leaver's fresh login fails, but their open browser keeps working for weeks. Fix: shorten how long a login lasts, and connect Redis or SCIM so deactivation ends sessions. Test with an open browser, not only a fresh login.

Keys nobody owns. Symptom: a script, a personal API key or a shared account runs up costs, and nobody can say whose it is. Fix: every key in the access audit, with an owner, a purpose, a budget and a revocation step. Switch off personal keys for ordinary users.

Budgets only on the invoice. Symptom: you learn about a runaway script from next month's bill. Fix: limits in the gateway per person or key, a monthly report per group, and the provider's own spending limit behind it.

Logs become a copy of everyone's questions. Symptom: debug logging from months ago still records every question. Fix: log metadata only, write down who reads what for how long, and check the log level after every change.

Per-person monitoring by accident. Symptom: the cost report names individuals, and the works or staff council hears about it from someone else. Fix: report by group. Agree in writing who sees individual figures, for what and for how long, before the first report goes out.

The operator is the runbook. Symptom: when you're away, nobody can add a group, raise a budget or answer an auditor. Fix: a runbook page per situation, and a substitute who has done each one while you watched.

Do it yourself (5 hours, over a month)

1. Structure it (20 min). Write one sentence each for the way in, the other doors, cost, records and continuity: what must be true, and who decides.
2. Understand it (90 min). List every account, key and admin in the assistant and compare with the directory. Run the leaver test with an open browser and a fresh login. Check the log level and what the logs hold. Ask who has been told what is recorded.
3. Choose tools (20 min). Decide how deactivation will end sessions, where budgets are enforced, and what monitors availability. Name one alternative and why you didn't pick it.
4. Build it: doors and leaver path (90 min). Close password logins and sign-up, convert or remove pilot accounts, give every key an owner, seal one emergency account. Test changes on staging first. Repeat the leaver test and write the stated window into the access audit.
5. Build it: budgets and records (60 min). Set limits per person or key, and the monthly group report. Write the records table with your data protection officer and give it to the staff or works council.
6. Build it: watch and handover (40 min). Set up the Monday post and the runbook pages. Have your substitute repeat the access audit and the leaver test while you watch without helping. Fix every place they got stuck.

Exit check

Written finding: an access audit for the shared assistant, containing:

• every way in: each account type, key and emergency access, with owner, purpose and revocation step;
• the leaver test: the one action, the times for a fresh login and an open session, and the stated window;
• the budgets: limits per person, key or group, and last month's cost per group;
• the records table, signed by the data protection officer, and the staff or works council's agreement;
• your substitute's run, with the date and where they got stuck.

It passes when a test leaver loses both an open session and a fresh login within the stated window after one action, no routine password login works, and your substitute repeated the audit from the runbook alone.

Rule to remember

One action should end a person's access; list and own every door that action can't reach.

Details for experts

Checked on 23 September 2026. You don't need this to follow the book; it's for setting things up or answering a colleague.

Further reading and tools

Next books

• T11-L04 · Put Your Team's Assistant on a Server Colleagues Can Reach: the server, Compose file, backups and updates this book runs.
• T04-L04 · Connect an Assistant to Real Documents Without Widening Anyone's Access: groups and collections when the assistant reads documents.
• T12-L05: governance records across all AI systems.
• T11-L05: capacity and serving models for many people.
• T13-L05: training and AI-literacy records for everyone who uses the assistant.

Tools

• Open WebUI: Taught. The assistant everyone signs in to.
• LiteLLM: Taught. The gateway that counts cost and enforces budgets.
• Uptime Kuma: Taught. Checks that the assistant answers and alerts when it doesn't.
• Docker: Catalogued. Runs the containers, as set up in T11-L04.
• Caddy: Catalogued. The front door from T11-L04.
• Heidelberg AI Desk: Catalogued. The route for one computer or a small group, before a server.