Activation required. AI access management must be enabled for your tenant before you can use it. To get started, contact the C1 support team for a walkthrough.
How clients register
C1 supports two registration methods:- Dynamic Client Registration (DCR) — the AI client registers itself with C1 by calling the registration endpoint, receives a unique client ID and secret, and then authenticates the user. Each client instance gets its own credentials.
- Client ID Metadata Document (CIMD) — the AI client presents a metadata URL as its client ID (for example,
https://claude.ai/oauth/mcp-oauth-client-metadata). C1 fetches and validates the metadata document on the fly. No per-instance registration step is needed — all instances of the same client share a single published identity.
- Which client types are allowed (tenant-wide; see Enable AI access management)
- Which access profiles each user has (which determines what tools each client can call)
- Per-client overrides (kill switch, lifecycle override; see below)
View registered clients
Go to AI access management > AI clients. The list shows every client registered against the tenant, with:| Column | What it shows |
|---|---|
| Name | Client display name (for example, “Claude Desktop”) |
| Type | Personal / shared / service / ephemeral |
| Owner | C1 user the client is bound to |
| State | Active / hidden / closed / deleted (see lifecycle below) |
| Last used | Timestamp of the last tool call |
| Toolsets | Toolsets currently accessible to the client (via the user’s access profiles) |
Client lifecycle states
C1 transitions clients through four states based on inactivity. Thresholds are set at the tenant level but can be overridden per client.| State | What it means | What the user sees |
|---|---|---|
| Active | Recently used; tokens valid | Normal operation |
| Hidden | Inactive past the hidden threshold | Client is hidden from the user’s connected-clients list, but tokens still work |
| Closed | Inactive past the closed threshold | Tokens revoked; user must re-authenticate to use the client again |
| Deleted | Inactive past the deleted threshold | Client registration is removed; user must re-register from scratch |
Per-client overrides
From a client’s detail panel:- Kill switch — immediately revokes all tokens for this client and forces it into Closed state. Use when a specific client is suspected of being compromised or behaving unexpectedly.
- Lifecycle override — exempt this client from the tenant inactivity policy, or set stricter thresholds. Useful for service clients that shouldn’t be auto-closed, or for sensitive clients that should be auto-closed sooner.
Tenant policy on client types
The tenant decides which of the four client types — personal, shared, service, ephemeral — are allowed to register at all. A client whose type is not allowed is rejected at registration time and never appears in the list. To change which types are allowed:Clients of a now-disallowed type that are already registered keep working until their tokens expire. New registrations of that type are rejected immediately.