One Coven per Client: Keeping Accounts, Subscriptions and Repos Apart

I have branches that add features in unrelated repos. Sensible branch names, tidy commits, in repositories that have nothing to do with the feature. My agent has access to many repos, it forgot to confirm which one it was working in, and it got on with the job.

Nothing was merged, so the damage was a few confusing branch lists and my pride. But I keep thinking about the version of this where the repos belong to different clients.

Per-coven AI connections, and per-coven accounts for GitHub, Linear and Google Workspace, are in AICoven 3.0.0. Slack, Figma and Notion arrive in 3.1.0.

---

One mistake, three places

Say you have three clients. Each one adds you to their GitHub, their Figma and their Slack. Each one either hands you an AI subscription or pays for the one you invoice them for. Add your personal accounts and that's four worlds times four logins: 16 accounts, one of you, and an agent that will cheerfully use whichever is nearest.

The agent reaching for the wrong one is always the same mistake. It just lands in three places:

• Whose AI account pays. Client B's work runs on the subscription client A pays for. Or on your personal one, which you can't bill to anybody.
• Whose app accounts get touched. A comment about client B's design appears on client A's Figma file, signed by you.
• Whose repos get written to. See above. (I am still deleting branches.)

Telling the agent to be careful didn't work. I had told it. An instruction is something a model can forget, and a list of what it's allowed to reach isn't.

One coven per client

A coven is a workspace with its own agents, threads and memory, and what one coven's agents remember isn't read by another's. The part that matters here is that each coven also has its own Connections, and they work as allow-lists.

AI connections. Add every key and subscription once, in Settings → AI connections, and give each one a name you'd recognise on an invoice. Then, in each coven's Connections, turn on only that client's. The coven says it plainly: "Agents in Nostromo Freight run only on the AI connections turned on here."

An agent runs on the one account and model you gave it. If that account isn't turned on in the coven, the message fails and says what to fix. It doesn't quietly try another account.

Two connections from the same provider can sit side by side, so client A's OpenAI key and client B's OpenAI key are two rows with two names. The same goes for OpenAI Codex: connect it once per ChatGPT subscription and name each one. That sign-in happens on OpenAI's page in your browser, so check which ChatGPT account the browser is in before you approve. AICoven stores whichever account said yes.

App accounts. In Settings → Connected Apps you can sign in to GitHub, Slack, Figma, Linear, Notion or Google Workspace more than once (Connect Another Account). Each coven then chooses which account it uses for each app. A coven with no account chosen for an app can't use that app at all. Nothing falls back to another of your accounts.

What it can reach inside the account. Per coven, you choose the repositories, the Slack channels, the Figma files. A new choice starts on Read. Read and make changes is something you turn on, per app, per coven.

A client's coven ends up looking something like this:

Nostromo Freight
  AI connections   Nostromo · OpenAI key    on
                   Rapture · Codex          off
                   Personal · OpenRouter    off
  GitHub           andreea-nostromo         Read and make changes
                   nostromo/storefront
                   nostromo/api
  Figma            andreea@nostromo.example Read
  Slack            Nostromo workspace       Read
                   #eng, #design

What "make changes" means depends on the app, and it's worth reading the footer under each one before you flip it:

• GitHub: agents can create branches, write files and open pull requests, in the coven's repositories. On Read, those are refused.
• Slack: agents draft messages as you, and a draft is sent only after you approve its exact text.
• Figma: agents post comments as you, without asking first.
• Linear and Notion: agents make their changes without asking each time.

So Figma is the one I'd leave on Read in a client's coven until I had a reason not to.

The repo part, since that's what bit me

I checked this one in the code, because a picker that only filters what you see would be worth nothing.

The coven's repository list is enforced on AICoven's server when the tool runs. Every GitHub call an agent makes through AICoven's GitHub connection (reading a file, writing one, creating a branch, opening a pull request) is checked against the coven's list before it goes to GitHub. A repository that isn't on the list is refused.

Two things to know:

1. The list starts open. When you first choose a GitHub account for a coven, Repositories reads "Every repository this account can open". The limit starts when you tap Choose Repositories… and pick. After that the footer says "Agents in Nostromo Freight can use only these repositories." Don't skip this step. (I would have.)
2. A call that names no repository gets the first one on the list, unless you named another listed repository in the thread. A coven with one repository on its list has nothing left to confirm.

Cost per client

AICoven doesn't produce invoices, and it doesn't split your spend by client. What it does is keep a key used for one client only. The provider does the accounting.

1. At the provider, create one API key per client and name it after the client.
2. Add each key to AICoven under the same name, and turn it on only in that client's coven.
3. At invoice time, read that key's usage on the provider's own usage page.

Check that your provider reports usage per key before you rely on this.

A subscription is a flat fee, so there's nothing to split. There the point is only that client A's subscription never does client B's work.

On the Mac, the AI connections list has a Used in column: "Nostromo Freight", "Nostromo Freight and Home", or "Not used in any coven". That's the audit. A client's key that shows two covens is a mistake waiting for an invoice.

What it doesn't do

• It doesn't fence in an agent that brings its own tools, unless you route its GitHub work through AICoven. Hermes, OpenClaw and an agent running through your Mac run their tools themselves, with whatever git credentials that machine has. The coven's repository list covers AICoven's GitHub connection, not their shell.

  You can close most of that gap with a Workspace MCP Key:

  • Make the key in the coven's Connections. A key belongs to one coven.
  • Turn on its GitHub switches and point the agent at AICoven's MCP server with that key.
  • The GitHub tools it finds there go through AICoven's connection. The coven's repository list applies, and a new branch, file or pull request waits for you to approve it in the app.
  • Write the repository into the coven's "Every agent here knows…". The agent can read it through the same key, so it knows where it is working.
  • Tell the agent, in its own instructions, to use only AICoven's tools for GitHub whenever the work comes from AICoven. An agent that follows that never reaches for its own git, so it can only touch what the coven allows.

  It's more setup, and the agent's shell is still there. This narrows an agent that follows instructions; it doesn't lock one that won't.

• An MCP server you add yourself isn't covered by the repository list. It's on or off per coven, on Read or Read and make changes, but the list doesn't reach inside it.

• Covens you had before 3.0.0 start wide open. They came through the update with every AI connection turned on, and their app accounts on Read and make changes, so nothing broke. The first job in a client's coven is turning things off.

• It can't stop you typing in the wrong coven. Ask Nostromo Freight's coven for Rapture Records' feature and it will build it, carefully, in Nostromo Freight's repository.

If you have stray branches too, start with the repository list: one coven, one client, the fewest repositories you can get away with. Then go and delete the branches. I still have some left.