> ## 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.

# Use case: Apps and MCP self-service

> See how C1 gives people and agents on-demand access to approved apps, AI tools, and MCP servers — one catalog, policy applied before anything provisions — and where to go for setup details.

When people can't get access quickly through a sanctioned path, they find one anyway — a shared login, a personal API key, an unsanctioned AI tool — and that's how shadow IT and shadow AI take hold. Self-service access means someone gets what they need without filing a helpdesk ticket and waiting: they find it in a catalog, request it, and — if policy allows — it's provisioned automatically. This page walks through how C1 puts that together for apps and AI tools alike. It's a closer look at the self-service section of the [identity governance use case](/docs/product/use-cases/identity-governance).

<Note>
  This page assumes you've already [added and configured connectors](/docs/baton/intro) for the apps you want to make requestable, and — if you're including AI tools — [enabled AI access management](/docs/product/admin/enable-ai-access-management).
</Note>

## One catalog

Apps, entitlements, and AI tools all surface in the same place. The **App catalog** on the [Requests page](/docs/product/how-to/create-requests#request-from-the-requests-page) lists everything currently assigned to a user or available for them to request, searchable by entitlement name even when they don't know which app it belongs to. AI tools don't get a separate catalog: [access profiles containing toolsets appear in the catalog alongside app entitlements](/docs/product/how-to/ai-tools#browse-the-catalog), each showing what tools it grants and what its approval policy is.

What's visible to a given user is scoped by [access profiles](/docs/product/admin/profiles) — an Accounting employee and a Product Design employee see different catalogs, and each of them only sees what they're allowed to request.

## Request from wherever you work

C1 supports requesting access from several places, not just the web app: the [C1 app for Slack](/docs/product/how-to/create-requests#request-using-the-c1-app-for-slack), the [Microsoft Teams app](/docs/product/how-to/create-requests#request-using-the-microsoft-teams-app), and the [C1 CLI](/docs/product/cli/install) for anyone who'd rather stay on the command line. Conversational, agentic request filing is real too, through two distinct paths: ask the [C1 AI assistant](/docs/product/admin/ai-assistant) what's available and request it, in the C1 web app or over Slack DM; or, for a coding agent like Claude Code or Cursor, install [c1i as an agent skill](/docs/product/cli/c1i-agent-skills) so it can create and manage access requests from natural-language instructions.

<Note>
  **A word on MCP specifically.** [C1 MCP](/docs/product/admin/c1-mcp) — the integration that lets an external AI client like Claude Desktop or Cursor query C1's own data over the Model Context Protocol — is read-only: it can answer questions about access, but it can't file a request on its own. For an agent to actually request or manage access on your behalf, use the C1 AI assistant or the c1i agent skill above instead.
</Note>

## Policy before provisioning

Every request — app, entitlement, or AI tool — runs through an approval [policy](/docs/product/admin/policies) before anything is granted: auto-approve for routine, low-risk access, or route to a manager, app owner, or other reviewer for anything sensitive. See [Access requests](/docs/product/admin/access-requests) for how policies attach to what's requestable, and [Get started with self-service access requests](/docs/product/how-to/qs-self-service-requests) for a full walkthrough of setting this up.

## Self-service AI tools, with admin control

Making an AI tool self-service doesn't mean giving up review. Through [AI access management (AIAM)](/docs/product/admin/aiam-overview), an admin approves the individual tools an MCP server exposes and bundles the approved ones into a toolset before it's ever requestable — end users can only ever request from what's already been reviewed, the same review-then-publish shape as any other entitlement. See [Get started with AI tools](/docs/product/how-to/ai-tools) for the end-user side of requesting and connecting.

## Remove access when work ends

Access doesn't have to be permanent by default. Requests — for apps or AI tools alike — can carry a just-in-time expiry instead of standing access, so it's removed automatically once the window closes rather than lingering until someone notices during a review. See the [JIT access use case](/docs/product/use-cases/jit-access) for the full picture, including emergency access and automatic removal.

## Related resources

<Columns cols={2}>
  <Card title="How to request new access" iconType="duotone" icon="key" horizontal href="/docs/product/how-to/create-requests" />

  <Card title="Get started with self-service access requests" iconType="duotone" icon="rocket" horizontal href="/docs/product/how-to/qs-self-service-requests" />

  <Card title="Access requests" iconType="duotone" icon="list-check" horizontal href="/docs/product/admin/access-requests" />

  <Card title="AI access management" iconType="duotone" icon="robot" horizontal href="/docs/product/admin/aiam-overview" />

  <Card title="Get started with AI tools" iconType="duotone" icon="sparkles" horizontal href="/docs/product/how-to/ai-tools" />

  <Card title="c1i agent skill" iconType="duotone" icon="terminal" horizontal href="/docs/product/cli/c1i-agent-skills" />

  <Card title="Identity governance use case" iconType="duotone" icon="layer-group" horizontal href="/docs/product/use-cases/identity-governance" />

  <Card title="JIT access use case" iconType="duotone" icon="clock" horizontal href="/docs/product/use-cases/jit-access" />
</Columns>