Documentation Index
Fetch the complete documentation index at: https://www.c1.ai/docs/llms.txt
Use this file to discover all available pages before exploring further.
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.