> ## Documentation Index
> Fetch the complete documentation index at: https://conductorone-sathya-add-agent-guardrails-doc.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Enable AI access management

> Turn on AIAM for your tenant and configure tenant-wide defaults for MCP servers, tools, and AI clients.

<Note>
  **Activation required.** AI access management must be enabled for your tenant before you can use it. To get started, [contact the C1 support team](mailto:support@c1.ai) for a walkthrough.
</Note>

AIAM lets you govern which AI clients can call which tools on your behalf, and which end users are allowed to use them. Enabling AIAM for your tenant is a one-time task that requires the **Super Administrator** role. Configuring tenant defaults, registering MCP servers, governing tools, managing AI clients, and using kill switches can be performed by either a Super Administrator or a user with the [AI Governance Administrator](/product/admin/user-roles#ai-governance-administrator) role.

Individual MCP servers, tools, and clients can override most of these defaults later. Set the defaults to the safest configuration you're willing to live with as a fallback.

## Enable AIAM for your tenant

Enabling AIAM exposes the AIAM surfaces (MCP servers, tools, AI clients, AIAM audit log) to admins. It does **not** automatically grant any end user access to any tool — every tool still has to be approved, added to a toolset, and bound to an access profile before it becomes requestable.

<Steps>
  <Step>
    Log in to your C1 tenant as a Super Admin.
  </Step>

  <Step>
    Navigate to **AI > C1 Gateway** and click **Settings**.
  </Step>

  <Step>
    Find **AI connections** and click **Edit**.
  </Step>

  <Step>
    Toggle **Enable AI Connections** to on.
  </Step>

  <Step>
    Click **Save** to confirm.
  </Step>
</Steps>

Once enabled, **MCP servers**, **MCP clients**, and the **AIAM audit log** appear in the tenant.

## Configure tenant defaults

After enabling AIAM, configure the five tenant-wide defaults below. All of them have safer, stricter defaults pre-selected — only adjust them if your organization has a reason to loosen them.

### Allowed client types

Controls which categories of AI client are allowed to register against your tenant. A client whose type is not allowed is rejected at registration time, before any tool is exposed to it.

| Type          | What it is                                                                                 | Default |
| :------------ | :----------------------------------------------------------------------------------------- | :------ |
| **Personal**  | Tied to a single human user (for example, Claude Desktop on their laptop)                  | Allowed |
| **Shared**    | Used by multiple humans behind a single registration (for example, a team workspace agent) | Allowed |
| **Service**   | Machine-to-machine, no human in the loop (CI/CD, batch agents)                             | Allowed |
| **Ephemeral** | Short-lived, single-session (one-off scripts, sandbox runs)                                | Allowed |

The underlying setting is a list of allowed client types. By default that list is **empty**, which means every client type is allowed to register. **Recommendation:** restrict this list to the client types your organization actually uses (typically Personal and Shared) — this is a hardening step you opt into, not the out-of-the-box behavior.

To change which types are allowed:

<Steps>
  <Step>
    In **AI > C1 Gateway > Settings**, find **Allowed client types**.
  </Step>

  <Step>
    Check the boxes for the types you want to permit.
  </Step>

  <Step>
    Click **Save**.
  </Step>
</Steps>

<Note>
  Any in-flight client of a now-disallowed type continues to function until its existing tokens expire. New registrations of that type are rejected immediately.
</Note>

### Default tool classification

When C1 discovers a new tool on a registered MCP server, it assigns the tool this initial state. Until an admin reviews and approves the tool, it cannot be added to a toolset and end users cannot request it.

* **State**: Pending Review / Unset (recommended — keeps every newly-discovered tool out of end-user reach until you've reviewed it)
* **Classification**: Sensitive (default)

To change the defaults:

<Steps>
  <Step>
    In **AI > MCP > Settings**, find **Default tool classification**.
  </Step>

  <Step>
    Select the state and classification to apply to newly-discovered tools.
  </Step>

  <Step>
    Click **Save**.
  </Step>
</Steps>

### Require tool approval

When on, every newly-discovered tool starts in **Pending Review** and must be approved by an admin before it can be added to a toolset. When off, tools become available to be added to toolsets immediately on discovery.

* **Default**: On
* **Recommended**: On for production tenants. Off is appropriate only for sandbox tenants where you're testing the end-to-end flow.

<Note>
  Turning this off does not bypass access profile approval — end users still go through the access profile's approval policy when they request a toolset.
</Note>

### Client lifecycle policy

C1 tracks how long it's been since each registered AI client made a tool call, and how long it's been since a client's credentials were closed. Three thresholds control what happens to an inactive client:

| Field label                     | Helper text                                                                                             | Default  |
| :------------------------------ | :------------------------------------------------------------------------------------------------------ | :------- |
| **Hide inactive clients after** | How long after last activity before the client is hidden from the default list. Set to zero to disable. | 1 day    |
| **Close credentials after**     | How long after last activity before OAuth credentials are closed. Set to zero to disable.               | 1 month  |
| **Delete closed clients after** | How long after close before the client registration is deleted. Set to zero to disable.                 | 3 months |

**Delete closed clients after** is measured from when the client's credentials were closed, **not** from the client's last activity.

To change the thresholds:

<Steps>
  <Step>
    In **AI > C1 Gateway > Settings**, find **Client governance**.
  </Step>

  <Step>
    Set each threshold.
  </Step>

  <Step>
    Click **Save**.
  </Step>
</Steps>

### Emergency kill switch

The kill switch immediately revokes every AI client's access to every tool, across all MCP servers in your tenant. Use it when you suspect an active compromise — for example, a leaked client credential or an MCP server that's behaving unexpectedly.

**What happens when you flip it:**

* All in-flight tool calls fail.
* All AI clients are forced into the **Closed** state.
* End users see an access-denied error in their AI client until you turn the switch off and they re-authenticate.
* Audit log entries are still written for any failed call attempts after the switch is flipped.

<Steps>
  <Step>
    In **Settings > System management**, find **Disable system features**.
  </Step>

  <Step>
    Toggle **Disable MCP traffic**.
  </Step>
</Steps>

### Per-server kill switch

Each registered MCP server also has its own kill switch, independent of the tenant-wide one. Flipping it blocks all MCP requests for that connector only — other servers keep working.

<Steps>
  <Step>
    Open the MCP server's configuration tab.
  </Step>

  <Step>
    Toggle the kill switch.
  </Step>

  <Step>
    Click **Save**.
  </Step>
</Steps>

Combined with the per-tool kill switch ([Govern tools and toolsets](/product/admin/tools-and-toolsets)) and the per-client kill switch ([Manage AI clients](/product/admin/ai-clients)), C1 offers kill switches at four scopes: tenant, server, tool, and client.