Skip to content

Seats & Policy#

Your AI was a personal tool. IT couldn't see who used which model on whose subscription, couldn't set a budget, couldn't stop an agent, couldn't take over when someone left. Team Policy removes those limits one field at a time and leaves everything else as it was.

A policy is the rules for one team: who reaches which provider through which seat, which models and integrations they may use, how much they may spend, what gets recorded. Admins edit it in the Team Policy app; members see a one-line summary of what applies to them.

Seats#

Couldn't be given a seat without being given the keys. A seat is a credential the team holds for its members. There are two kinds.

  • A subscription seat (Claude Max or Team, ChatGPT, Gemini — OAuth). The admin declares it once. Each member sees a seat waiting in their credentials — team seat · sign in to connect — and does one OAuth sign-in. The token the vendor issues is theirs; the binding is the team's.
  • A team key (an API key). The admin pastes it once. It lives in the service account's config dir, never in a member's home. Members see team key · connected and nothing else. It is injected into the agent process at start exactly as a personal key would be; nothing downstream knows the difference.

Members can't create, read, replace or delete a team credential. A vendor can have several seats (your work on one subscription, a client's on another); one is the default, and a group can be told which it may bill to. Contractors bill the seat, never the API key is one line.

What the member experiences is the point: SSO login, one sign-in card, a working agent. No settings page, no API keys.

Providers, models and families#

Couldn't say "not that model". A policy turns providers on or off for the whole team and, for each provider, allows any model or only some. Allow-lists are written in families — "Claude Opus", "GPT Codex" — so the rule still holds the day a new version ships. Exact ids still work when you need to pin one.

Groups come from your identity provider (Keycloak, or your own IdP federated through it) and override the team default with two lists: may use and never. A person's effective set is the union of their groups' allows (or the team default) minus the union of their denies. Deny always wins. A contractor who is also in engineering never gets the model contractors are denied. No priorities, no first-match rules; two lists and one rule is the whole grammar.

The model picker shows only what a member may pick. A request the policy refuses gets a visible reply naming what the team allows, never a silent downgrade.

Integrations and data#

MCP servers get the same grammar: a team-wide allow-list plus per-group may use and never lists. A server the policy removes is dropped from the agent's session, and the agent says so once. The same list is pushed to the node's Claude Code managed settings, so a CLI in a shell matches.

Excluded paths — **/.env, ~/.ssh/**, **/*.pem — become deny rules written into every Claude Code session the platform starts. An agent asked to read a key file is refused by the harness, and the refusal is visible in the reply. (Claude Code today; Codex and Gemini CLI don't expose an equivalent yet.)

Spend#

Couldn't see the bill until it arrived. Every completed turn writes one row to a team ledger: who, which agent, channel, model and seat, tokens in and out, and a cost at list price from a versioned price table, so the numbers are reproducible. Subscription turns are priced too, so you can see what a seat saves against pay-per-token.

Budgets apply at three levels — team per month, group per month, member per month — and the tightest applicable limit governs. Crossing 50%, 80% and 100% puts a one-line notice on the member's next reply and a row in the audit log. The default is warn; switch it to refuse and the turn past 100% is refused, visibly, and nothing is billed.

The Usage tab shows any date range by user, agent or model. Export CSV writes exactly the rows on screen, filters included.

Audit and the kill switch#

Couldn't answer "what did the agents do?" The Audit tab has two views: activity (every dispatch, filterable by user, agent, channel, model and date) and admin actions (every policy save, support edit, grant, stop and offboarding). Both export as CSV or JSONL with a custodian filter: an eDiscovery request is one URL, and your SIEM ingests the rest. Transcripts, grants, retention and holds are on Channels & the Record.

Couldn't stop it. Stop one member's agent, or every agent in the team, from the console. Live sessions end with a visible stopped by admin, the heartbeat stays off until an admin turns it back on, and the stop is on the record, including on the member's own summary.

Every admin action is visible hands: a member's policy view lists what admins looked at or changed. Admins fix configuration; they never read content without a grant.

Roles and provisioned agents#

Three roles. Owner: billing, delete the team, assign admins. Admin: policy, seats, agents, audit, usage. Member: use. On an SSO node roles and groups come from Keycloak; without SSO the policy file lists them. There is no third user table. See Identity & security.

Couldn't roll an agent out to the whole company. An admin builds an agent — prompt, model, harness, MCP servers, skills — tests it, and names it in the policy. Saving snapshots it as a template; every member who lacks it gets their own copy, bound to the team's default seat, heartbeat running. Anyone who joins later gets it at first sign-in. The copy is the member's from then on, memory and all; the template is the seed, not a live link. See Agents.

How it fits#

A policy is one JSON file per team under the platform's config dir, owned by the service account, every prior version kept. It is read when an agent process starts — model, seat, MCP set, permission flags, environment — and by the edit API. There is no proxy in front of the model: LIT starts the vendor's own harness with the right flags and keys. Saving a policy restarts the live sessions it changed, so it takes effect immediately. A hundred-person team is one file, not a hundred settings pages.

The invariant that makes it safe to ship to every install: no policy file means nothing changes. Desktop and single-user installs never grow one unless someone writes it.

Related: Any harness, any model · Partners set policy for the teams they bring.