AI access management overview

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.

AI Access Management (AIAM) extends C1’s identity governance platform to the AI tool layer. It acts as a control plane between AI clients (Claude Desktop, Cursor, ChatGPT, Copilot, and other MCP-compatible clients) and the downstream MCP servers those clients connect to. When AIAM is enabled, every tool call from an AI client is routed through C1’s identity-aware proxy. The proxy authenticates the caller, checks the tool call against the user’s granted access profile, enforces any configured policy constraints, forwards the call to the downstream MCP server, and writes an audit log entry with full identity context. AIAM covers the following capabilities:

Registering and configuring MCP servers (from the 3,000+ hosted catalog)
Discovering and classifying the tools and resources each server exposes
Governing tool access at a granular level — admins review, approve, or disable individual tools and control which tools each user and agent can call
Governing resource access at a granular level — admins review, approve, or disable each static resource and URI template; C1 checks its linked read entitlement on every read
Bundling approved tools into toolsets and binding them to access profiles
Provisioning end-user and agent tool access through the standard C1 request and approval workflow
Vaulting and rotating downstream credentials so they are never exposed to end users or stored locally
Logging every tool call with identity, tool, parameter, and policy context for audit and compliance

C1’s AI Connections feature has two sides. This page covers AI access management (AIAM) — governing outbound AI tool calls to external services like Salesforce and GitHub. If you want AI assistants to query C1’s own identity data instead, see C1 MCP.

Key concepts

Concept	Description
MCP server	A downstream service that exposes one or more tools via the Model Context Protocol. C1 hosts a curated catalog.
C1 MCP	The proxy your AI clients connect to. It accepts connections from AI clients, routes requests to the appropriate downstream servers, and enforces authorization on every tool call. AI clients connect to one URL — C1 MCP — not to each downstream server directly.
Tool	A single capability exposed by an MCP server (for example, `github_create_issue` or `salesforce_query`). C1 discovers tools automatically when an MCP server is registered.
MCP resource	A static resource or URI template exposed by an MCP server. C1 discovers it automatically. C1 checks its approval state and linked, resource-specific read entitlement on every read. Resources are not toolsets or catalog items.
Toolset	A named bundle of approved tools. Two kinds: C1-maintained (for example, “All approved tools” and “All read tools”) and custom (admin-curated).
Access profile	The same mechanism C1 already uses for traditional app access. A toolset is bound to an access profile, which carries the approval policy, expiry, and approvers.
AI client	A specific registered AI client instance (for example, “Jess’s Claude Desktop” or “the team’s shared Cursor agent”). Registered via Dynamic Client Registration (DCR) or Client ID Metadata Document (CIMD).
AI connection	The authenticated link between a user’s AI client and C1. When a user connects an AI client to C1, C1 creates an AI connection record that ties the client instance to the user’s identity. Admins can view, manage, and revoke AI connections across the tenant.
Auth mode	How an MCP server authenticates downstream. Supported methods include bearer token, custom header, basic auth, and OAuth2 (client credentials, service mode, per-user passthrough, and JWT bearer).
Client type	A classification on each AI client: personal, shared, service, or ephemeral. Tenant-level policy controls which types are allowed.

How the pieces fit together

A typical end-to-end flow:

Admin registers an MCP server in C1 (for example, the GitHub MCP server) and configures its auth mode.
C1 discovers the tools and resources the server exposes. Tools begin as Unset; resources begin as Pending.
Admin reviews and approves tools, then bundles approved tools into a toolset.
Admin reviews and approves resources. C1 links each approved resource to its resource-specific read entitlement; resources remain independent of toolsets.
Admin binds the toolset to an access profile with an approval policy.
End user registers their AI client with C1.
End user requests the tool access profile from the C1 catalog (web, Slack, or from their AI client).
Approver approves, and the tool becomes available to the user’s AI client.
AI client calls a tool or reads a resource → request hits C1 MCP → C1 checks the user’s current access and the item’s approval status → forwards to the downstream MCP server using the configured auth mode → returns the result, logging the operation.

Where to go from here

New to AIAM? Start with Enable AI access management.
Already enabled? Move on to Set up an MCP server.
Setting up audit and compliance? See Audit AI tool usage.
Ready to test your setup as an end user? See Get started with AI tools.
Need to approve a discovered resource or manage its access? See Govern MCP resources.
Governing an MCP server that supports the standard? The gateway is one of two paths C1 governs. For servers that can verify C1-issued tokens, C1 can issue a scoped token and let the agent call the server directly. See Enterprise-managed authorization.

Overview

C1 MCP

Workforce & app access

AI agent governance

Risk & intelligence

Cloud infrastructure access

Platform & administration

AI access management overview

Key concepts

How the pieces fit together

Where to go from here

​Key concepts

​How the pieces fit together

​Where to go from here

Key concepts

How the pieces fit together

Where to go from here