Run Your Organisation's Connectors: One List, Per-Person Access, a Log and a Clean Exit | Heidelberg AI Curriculum
T14-L05
Run Your Organisation's Connectors: One List, Per-Person Access, a Log and a Clean Exit
Operate the connectors a department or company relies on: one list of every route from an assistant into a system, per-person access, a log line for every call, a check of third-party connectors before install, a daily test, and a retirement you can prove.
In a company, Lea's stock connector works so well that the head of sales wants it for all 25 sales staff. Today it runs on three laptops, each with a personal token. Stefan in IT does the arithmetic: 25 laptops, 25 tokens, 25 copies of the program to update, and no single place that shows who asked what.
In both places each connector was a good idea on its own. Together they're a set of routes into real systems that nobody can list, update or switch off.
You are at Level 5 Operator. You run the routes that many people's work goes through. When one breaks, a whole team loses an answer it relies on; when one reaches too far, many people's assistants do.
After this you can
Keep one list of every connector in use, with what it reaches, whose access it uses, its version, who is responsible and how to stop it.
Run a connector for many people so each person reaches only what they may, and prove it with two accounts.
Log every tool call, including refused and failed ones, without copying the data itself into the log.
Judge a third-party connector before anyone installs it: publisher, tools, access, and how updates arrive.
Retire a connector and prove it can no longer be called, with a fallback for the people who used it.
Admin access or a contact for your assistant's organisation settings (in Claude, the organisation's Owner, the top admin role), and for each system a connector reaches.
Two test accounts with different access, for example members of two different groups or teams.
A stand-in, someone who didn't build the connectors, with an hour in their calendar.
About 3.5 hours: 21 minutes to read, about 3 hours of doing, over two weeks.
Last verified 23 September 2026. In Claude Team and Enterprise, only Owners can add custom connectors, and each member then connects with their own sign-in. Claude reaches such connectors from Anthropic's cloud, so they must be reachable from Anthropic's addresses. Details for experts at the end of this book.
The idea in one page
A connector is a route: from a person, through a program, into a system. At Level 4 you built one and proved its limits. At Level 5 you run many of them, for many people, over months. Five practices keep that under control.
Local, on each user's laptop, started by Claude Desktop
Version and source
1.2, from the department's GitLab, pinned
Tools
find_stock
Log
One line per call, on the laptop
Responsible and stand-in
Birgit, Oskar
Stop
Delete the key in eLabFTW
Next review
15 January
If a field is unknown, the row says unknown, and the connector pauses until it isn't.
2. Every call carries a person. When many people use one connector, the system must know who is asking, for two reasons: so each person reaches only what they may, and so the log can say who did what. There are two ways. The connector can use each person's own access (their own key or sign-in), so the system applies its usual rules. Or it can use one service account with a narrow role, check each person's identity itself, and write that identity into every log line. The first is simpler and preferred. The second needs you to rebuild permission checks in the connector, and to test them with two accounts.
3. A log line for every attempt. Every call, including refused and failed ones, produces one line: time, person, connector and version, tool, result (answered, nothing found, refused, failed), how many records came back, how long it took. Not the question, not the answer. The log tells you what happened without becoming a second copy of the data. The data protection officer (DPO) decides how long it's kept, because it names people.
4. Third-party connectors are checked before installation. Anyone can publish a connector. Before one is installed, someone answers four questions: Who publishes it?Which tools does it offer, and can any of them write?Whose access does it use?How do updates arrive? Each local connector has a start line in Claude Desktop's settings, the command that launches it. If that line asks for the latest version, the connector downloads and updates itself every time it starts, so what you checked last week isn't what runs today.
5. Every route has a daily test and a clean exit. A small automatic test calls each connector once a day with a known question and checks the answer. It catches the day a system changes a field name. And retiring a connector means proving it's gone: the tool no longer appears, the key no longer works, and the people who used it know what to do instead.
Who decides: the system's administrator decides what a connector may reach. The organisation's assistant admin decides which connectors are offered. IT decides where central connectors run. The DPO decides how long logs are kept. You keep the list, the log, the tests and the reviews.
Worked example: two sets of routes, four quadrants
Structure it. Katrin: "Every connector in the department is on one list, with a responsible person and a stop. Nobody reaches the lab notebook through a connector with more access than their own. A useful result: a list the department head signs, a leaver's access closed, and one connector retired so cleanly that nobody can call it."
Understand it. She starts with the organisation settings of the department's Claude Team plan, which the head of IT administers. There's one organisation connector (Microsoft 365, switched on by IT) and no custom connectors. So the nine routes are all local: programs that Claude Desktop starts on individual laptops. The organisation settings can't see or control those. The list has to come from people.
She sends each user of Claude Desktop one request: open the settings file and send her the list of connector names and the line that starts each one. The instructions fit in two lines: in the Claude menu, choose Settings, then Developer, then Edit Config; this opens claude_desktop_config.json, where every local connector is one entry under mcpServers. Then she sits down with Birgit and Jens, the eLabFTW administrator, to read the answers.
Three things stand out.
The three versions of Birgit's connector: two colleagues still run her first version, which used a single shared key created under Birgit's account. That key sees a collaborating group's inventory, as T14-L04 · Build a Read-Only Connector for a System Your Assistant Can't Reach Yet found. Anyone on the old version sees more than their own access allows.
The community eLabFTW connector from GitHub, installed by a PhD student to draft experiment entries. Its tool list includes creating and changing experiments. It runs with his read-and-write key. And its start line runs the package with npx, Node.js's tool for fetching and running a package, and ends in @latest: every time Claude Desktop starts, it downloads whatever version the author published last.
The unexplained connector on the leaver's old laptop, now used by a new student, turns out to be Birgit's second version, still configured with the leaver's key. Her account is active, because nobody closed it.
The problem is bigger than the one Katrin set out to solve. Back to Structure it: "A list alone won't do. Every route must use its user's own access, every version must be the current one, third-party connectors need a check before installation, and closing an account must close its keys."
The department's GitLab as the only source of the inventory connector, with each version tagged, that is, given a fixed label such as 1.2 that always points at the same code. The start line in Claude Desktop names an exact version, never latest.
eLabFTW's own key list. Each key shows when it was last used, which makes unused and forgotten keys visible at each review.
A one-page check for third-party connectors, with the four questions, signed by Jens before any installation that touches the lab notebook.
Build it: close what's open. Jens deactivates the leaver's eLabFTW account. The new student creates her own read-only key and switches to the current version. Birgit then sends one test request with the leaver's old key: refused. That closes the route, and the test proves it.
For the old versions, Birgit deletes the shared key in her own eLabFTW settings. Every copy of version 1 stops working at once. The two colleagues install the current version from GitLab with their own keys. Their runs show their own group's items only.
Build it: judge the community connector. Katrin and Jens fill in the check:
Question
Answer
Who publishes it?
One person's GitHub account; no organisation behind it; last change three weeks ago
Which tools, and can any write?
Seven tools; four create or change experiments and items
Whose access?
The user's own key, which here can write
How do updates arrive?
Downloaded fresh at every start, unpinned
Decision: not approved for the lab notebook. Any update could add a tool that deletes, and nobody would notice. The student's need, drafting experiment entries, is real. So Birgit adds a second tool to the department's own connector, draft_entry, which writes nothing: it only returns a formatted draft that the student pastes into eLabFTW himself, after the same six tests. The student uninstalls the community connector and deletes his read-and-write key.
Build it: log, test, review. Birgit adds one log line per call to the connector, written to a file on each laptop: time, tool, result, count, duration. It helps her support colleagues, and it names only the laptop's own user. Katrin asks the DPO about a central log; the DPO sees no need, since the connector reads inventory, not personal data, and each person's own key already limits them. That decision goes into the row with its date.
A daily test isn't needed for a tool people use when they want to; if it breaks, they notice and use the fallback. The quarterly review is: compare the list with each user's connectors, check eLabFTW's key list for keys unused for 90 days, and confirm each installed version.
Build it: retire and prove it. Version 1 of Birgit's connector is retired. The inventory row gets a retirement record: key deleted (date), test call with the old key refused (date), tool gone from both colleagues' Claude Desktop (checked on screen), users told the fallback (look it up in eLabFTW in the browser). The row stays, marked retired, so the next review knows it existed.
Oskar, Birgit's stand-in, runs the next quarterly review from the list alone. He finds one key unused for four months, belonging to a technician who stopped using the connector; she deletes it.
What it taught Katrin: the organisation settings showed one connector. The laptops had nine. The riskiest one wasn't written by anyone in the department, and it changed itself every morning.
Company: one central connector for 25 people
Structure it. Stefan: "All 25 sales staff can check stock and delivery dates from the assistant, through one connector IT runs, with each call logged under the person's name. It reads only, it's tested every day, and IT's deputy can run it without me. A useful result: the head of sales signs the list, two test accounts show the permission check works, and the three laptop versions are retired."
Understand it. He looks at two ways to scale Lea's connector.
The first is to keep it local: 25 laptops, 25 personal tokens, 25 installations to keep on the same version, and logs scattered across 25 machines. That's the lab's pattern, and it works when a few people use a read-only tool on non-personal data. For a whole sales team it means 25 places where a token can leak and no answer to "who checked stock for Hartmann last week?"
The second is a remote connector: the same program running once on a company server, reached over HTTPS through the format MCP uses for remote servers, called Streamable HTTP. In Claude Team, only the organisation's Owner can add one as a custom connector. Each member then connects with their own sign-in.
Reading Claude's documentation, he finds the catch: Claude reaches a custom connector from Anthropic's cloud, not from the user's laptop. A server that only the company network can reach won't work. It must accept connections from Anthropic's published addresses.
Back to Structure it: "The central connector runs on a small server outside the internal network, with the firewall open only to Anthropic's addresses, and every request must carry a valid company sign-in. Nothing without a sign-in gets an answer."
Choose tools.
The MCP Python SDK serving Lea's connector over Streamable HTTP, with its built-in check for sign-in tokens, the short-lived passes the company's identity provider (the service that runs company logins, here Microsoft Entra ID) issues after login. IT writes the few lines that check a token came from the company's Microsoft Entra ID and that the person is in the Sales group.
Build it. Stefan deploys the connector on a small cloud server in the company's account. IT registers the connector as an app in Entra, as in T12-L04 · Lock Down a Self-Hosted AI Service Before Real Data Goes In, and gets a client ID and secret. The Owner of the company's Claude organisation adds the connector under Organization settings, Connectors, with its HTTPS address and that ID and secret. Lea and a colleague from purchasing, who isn't in Sales, connect as tests. Lea gets stock answers. The purchasing colleague signs in successfully, and then every call is refused with "This connector is for the sales team." That's the permission check, proved with two accounts.
Every call writes one line to the connector's log:
The item number isn't logged; the answer isn't logged. The DPO sets a retention of 90 days, long enough for a customer complaint to be checked. The log is rotated to match: a new file every day, and files older than 90 days are deleted.
Build it: the daily test. Uptime Kuma calls a small check page on the connector every morning at 07:00. The page runs check_stock for one fixed test item, compares the answer with what it should be, and prints OK or FAIL. Uptime Kuma's keyword check alerts whenever OK is missing. In November it fails: Northstar's update renamed the field for the next delivery date, and the connector returns stock without a date. The alert reaches Stefan and his deputy, Aylin, before the first sales call. Aylin fixes the field name from the runbook, runs the six tests from T14-L04 · Build a Read-Only Connector for a System Your Assistant Can't Reach Yet, and records version 2.1 in the list. The sales team never notices.
Build it: retire the laptop versions. Stefan revokes the three personal tokens from the local phase. A test call with one of them is refused. Lea and her two colleagues remove the local entry from Claude Desktop and connect the central one. The inventory records the retirement with its dates and the refused test call.
Build it: what the auditor sees. When the hospital customer from T12-L05 · Keep One List of Every AI System Your Team Runs, and Make It Survive You asks a follow-up question, "Can you show who accessed stock data for our orders?", Stefan can answer from the log: who called the stock tool and when, without the log holding any order data itself.
What it taught him: moving to a central connector wasn't mainly about convenience. It made one log, one version and one stop, and it forced the question the laptops had hidden: who exactly is allowed to ask?
In both places the connectors worked before anyone started operating them. What changed was that someone could now say which routes exist, whose access each one uses, and prove that a closed route stays closed.
What goes wrong
The admin view shows only part of the map.Symptom: the organisation settings list one connector, and people's laptops run nine. Fix: ask every user for their local connectors, and repeat at each review. Local connectors never appear in the organisation settings.
Everyone appears as one service account.Symptom: the system's log shows one account for all calls, and nobody can say who asked. Fix: use each person's own access, or have the connector check and log each person's identity on every call.
Only successful calls are logged.Symptom: the log looks clean while a hundred refused calls went unrecorded. Fix: log every attempt: answered, nothing found, refused, failed.
The log becomes a copy of the data.Symptom: the log holds questions and answers, including customer details. Fix: log what happened, not what was said. The DPO sets how long it's kept.
An unpinned third-party connector.Symptom: a connector's start line ends in latest, and its tools change without anyone deciding. Fix: pin an exact version, check each update before it's installed, or don't install it.
A retirement that only removed the icon.Symptom: the connector is gone from one person's list, but its key still works. Fix: delete or revoke the key, prove it with a refused test call, and record the date.
A route breaks quietly.Symptom: a system update changes a field, and the connector returns incomplete answers for a week. Fix: a daily test with a known answer for every connector a team depends on, with alerts to two people.
Do it yourself (3 hours, over two weeks)
Structure it (15 min). Write one sentence: which department or team, which systems connectors reach, and what "under control" means. Name your stand-in.
Understand it (50 min). Check your assistant's organisation settings for connectors. Ask every user for their local connectors and the line that starts each. For each system, look at the list of keys or tokens and when each was last used. Rewrite your sentence if what you find changes the job.
Choose tools (15 min). Decide where the list lives (your AI inventory), where connector code comes from and how versions are pinned, where logs go, and how daily tests run.
Build it: list and close (45 min). Write a row for every connector. Close what's open: leavers' keys, shared keys, unpinned third-party connectors. Prove each closure with a refused test call.
Build it: identity and log (30 min). For one connector used by many people, show with two test accounts that each reaches only what they may. Make sure every call writes one log line without content. Ask the DPO for retention.
Build it: retire and hand over (25 min). Retire one connector with a record: key revoked, test call refused, tool gone, users told the fallback. Let your stand-in run one review from the list alone.
Exit check
Written finding: a connector list for one department or company team, and one retirement record.
Every connector row has purpose, what it reaches, whose access, where it runs, version and source, tools, log, responsible person and stand-in, stop and next review.
One two-account test for a connector many people use, showing each account reaches only what it may.
One third-party check, with the four questions answered and the decision.
One retirement record: key revoked, refused test call, tool gone, fallback communicated, dates.
It passes when every row is complete or marked paused with a reason, the two test accounts show different access where they should, the retired connector can't be called, its former users know the fallback, and the department head or manager has signed.
Rule to remember
A route you can't list, log and close isn't yours to run.
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.
What
Details
What it means for you
Claude custom connectors
Remote MCP servers added under Organization settings → Connectors. On Team and Enterprise only Owners can add them; members then click Connect and authenticate themselves. Owners can enter an OAuth client ID and secret, the details your identity provider issues for the connector.
One place to offer, and to remove, a central connector.
Where Claude connects from
Claude connects to custom connectors from Anthropic's cloud, not the user's device. Servers must be reachable from Anthropic's IP ranges; ones only on a private network or behind a VPN won't connect. Anthropic publishes the addresses to allow in your firewall.
Allow only those ranges on the connector's port.
Local connectors
Servers in Claude Desktop's settings file run on the user's device and use the local network. They don't appear in the organisation's connector settings.
Collect them from users at each review.
MCP sign-in
Over Streamable HTTP, an MCP server checks an OAuth 2.1 bearer token (a short-lived pass from your identity provider) on every request. In the Python SDK you supply a TokenVerifier and AuthSettings; the server never signs anyone in itself.
IT writes the token check against your Entra setup, or Keycloak, a self-hosted sign-in server.
eLabFTW keys
Each API key records when it was last used.
Delete keys unused for 90 days at each review.
Uptime Kuma
Version 2.5.5; checks an address or keyword on a schedule and alerts by email or chat.
Point it at a check page that calls the tool with a known answer.
Caddy: Catalogued. The front door for a central connector.
GitHub: Catalogued. Where many third-party connectors are published; check before installing.
Watch
Connecting Claude Securely to Microsoft 365
Connecting Claude Securely to Microsoft 365T-Minus365
T14-L05: Understand the administrator's role in approving Claude's Microsoft 365 connection and reviewing delegated access. Follow current vendor guidance for permissions; use the book for tool-call logs, access tests and retirement.
