Skip to content

Teams, Models, and Virtual Keys

Organizations and Teams determine where resources and access belong. Virtual keys let your code use those resources with a specific owner, policy and limits. Human roles determine what you can manage in the Console or management API.

Organization and Team

An Organization owns the catalog and contains Teams. A Team groups members, service accounts, model/tool/deployment allowance and budgets. Selecting a Team in the Console changes your working context; it does not grant access.

A virtual key belongs to one Team and one exact user membership or ordinary service account. Effective API access is catalog ∩ Team allowance ∩ key policy. The key also needs the requested operation. A human role controls administration; it does not replace key policy.

For example, a developer in the Support Team might be able to edit Agents but still have a key that can only call the support model. Adding tool.invoke to that key cannot enable a tool the Team is not allowed to use. An Organization member without Team access can still use a published Agent if included in its Chat audience.

Human roles and application permissions

The eight built-in Organization/Team presets and bounded custom roles are listed in Roles and permissions. Each task guide identifies the exact permissions it needs. Do not infer publication, captured-content access or inference access from the word “developer” or “admin.”

Inference operations such as model.generate, tool.invoke and deployment.invoke belong to key policy. Management permissions such as agent.edit and team.allowance.manage belong to human authority. The two controls have different purposes.

Choose a credential

Task Credential Where to obtain it
Develop as yourself User virtual key (mck_…) Access → Virtual keys → Create key → For me
Run backend code Service-account virtual key (mck_…) For a service, with service-key management permission
Connect an interactive MCP client OAuth client connection (mcc_…) backed by a logical user key Connect a client during onboarding
Automate administration Expiring scoped management token (mcm_…) Account Access; usable on the control listener only
Execute a managed app Caller virtual key for API entry, or actual browser session for Chat Deployment's explicit API owners or Chat audience

Managed execution credentials are internal and cannot be revealed or copied. An Agent is content for a managed application, not an identity required by external code. A service account remains when its creator leaves. User keys bind membership instances and cannot revive when a removed user rejoins.

Keys are shown once. Rotation replaces the secret while retaining the logical key and its accounting history; clients must reload the new secret. Current policy, status and namespace edits take effect on the next check without restart. Terminal revocation cannot be undone.

Models, tools and deployments

A virtual model such as support is a stable name routed to provider infrastructure. GET /v1/models returns authorized names and operation capabilities. An embedding model need not support generation. A Connector exposes governed MCP tools; use the actual names/schemas returned by tools/list.

An Agent draft becomes an immutable snapshot. Private Preview uses that snapshot; Production publishes a version with reviewed execution policy, connection bindings, audience and API owners. Chat can serve Organization members outside the publishing Team. API callers may be invoke-only, without direct model/tool permission; managed children use separately governed execution access funded by the publisher.

Evidence and grouping

A Request's decision records authorization/outcome. Each physical model attempt or business tool dispatch has a financial ledger fact. Trace spans add observations, never authorization or extra cost. A Trace is Organization + Team + Trace ID. A Session is namespace + Session ID, and does not grant conversation ownership.

Keep X-Mission-Control-Trace-Id and the correlation ID. Use Observe → Requests, Traces, Sessions and Usage within your permissions. Captured content and export require separate permissions from metadata. An external key may export standalone OTLP with telemetry.ingest; no preceding model call or Builder Agent is needed.

Continue