Roles & governance
Atrium resolves a tool list per caller, from the roles you assigned them — not from what the caller or their assistant asks for.
Roles and entitlements
A role is a named bundle of entitlements. An entitlement grants one role access to one hosted server — or, for a curated Postgres server, to one specific named query. A caller sees the union of their roles’ entitlements and nothing beyond it.
Access is deny by default. A connector nobody has been granted is not merely locked — it is absent from the tool list, so the assistant cannot describe it, attempt it, or explain around it.
Scope bound on the server
Curated named queries take their scope from properties you assign — a value on the user, falling back to a default declared by their role. When the query runs, Atrium binds those values itself.
Scope parameters are absent from the tool’s published input schema. The model never sees them, so it cannot pass a different value, and a prompt-injected instruction to “query for another region” has no parameter to reach for. The caller supplies only the arguments you marked as caller-supplied.
The curated catalog
Alongside the connectors it runs, Atrium keeps a per-organization catalog of external MCP servers your team installs themselves. Entries are drafted, published, and scoped to a visibility tier, and the assistant reads the catalog live rather than from a wiki page that went stale the day it was written.
When a user asks to install one, Atrium returns the right artifact for the client in front of them — a one-click Cursor or VS Code deeplink, a claude mcp add command, or a Claude Desktop config snippet.
Approval requests
A restricted catalog entry is surfaced to a non-admin as restricted rather than hidden, so they know it exists and can ask for it. The assistant files the request through request_approval, and it lands in your dashboard queue with a pending badge — instead of the conversation dead-ending or the user going around you.
Policy awareness
If your organization ships a managed MCP policy to endpoints, check_policy_status reads it and tells the user which situation they’re actually in: “already approved — run this” versus “not in your policy yet — request it here.” The assistant stops handing out commands that the endpoint will refuse.
Authentication
Desktop and web clients connect over OAuth against your existing identity provider, and their organization role maps to what they can see. Server-to-server callers use an organization API key (sk_org_…), which carries its own role. Multi-org users can pin an organization by connecting to that org’s endpoint path.