Document MCP resource governance

docs.json

@@ -235,6 +235,7 @@
                   "product/admin/aiam-overview",
                   "product/admin/enable-ai-access-management",
                   "product/admin/tools-and-toolsets",
+                  "product/admin/mcp-resources",
                   "product/admin/tool-call-hooks",
                   "product/admin/ai-clients",
                   "product/admin/audit-ai-tool-usage"

product/admin/aiam-overview.mdx

@@ -1,15 +1,15 @@
 ---
 title: AI access management overview
-description: How C1 governs AI tool access — MCP servers, tools, toolsets, and AI clients.
+description: How C1 governs AI tool and resource access — MCP servers, tools, toolsets, and AI clients.
 og:title: AI access management overview - C1 docs
-og:description: How C1 governs AI tool access — MCP servers, tools, toolsets, and AI clients.
+og:description: How C1 governs AI tool and resource access — MCP servers, tools, toolsets, and AI clients.
 sidebarTitle: How AIAM works
 ---
 
 {/* Editor Refresh: 2026-05-08 */}
 
 <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>
 
 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.
@@ -19,10 +19,11 @@
 AIAM covers the following capabilities:
 
 - Registering and configuring MCP servers (from the 3,000+ hosted catalog)
-- Discovering and classifying the tools each server exposes
+- 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 access through the standard C1 request and approval workflow
+- 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
 
@@ -37,11 +38,12 @@
 | **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
@@ -49,18 +51,20 @@
 A typical end-to-end flow:
 
 1. **Admin registers an MCP server** in C1 (for example, the GitHub MCP server) and configures its auth mode.
-2. **C1 discovers the tools** the server exposes and lists them as Unset.
+2. **C1 discovers the tools and resources** the server exposes. Tools begin as Unset; resources begin as Pending.
 3. **Admin reviews and approves tools**, then bundles approved tools into a toolset.
-4. **Admin binds the toolset to an access profile** with an approval policy.
-5. **End user registers their AI client** with C1.
-6. **End user requests the access profile** from the C1 catalog (web, Slack, or from their AI client).
-7. **Approver approves**, and the toolset becomes available to the user's AI client.
-8. **AI client calls a tool** → request hits C1 MCP → C1 checks the user's access profile and the tool's approval status → forwards to the downstream MCP server using the configured auth mode → returns the result, logging the call.
+4. **Admin reviews and approves resources**. C1 links each approved resource to its resource-specific read entitlement; resources remain independent of toolsets.
+5. **Admin binds the toolset to an access profile** with an approval policy.
+6. **End user registers their AI client** with C1.
+7. **End user requests the tool access profile** from the C1 catalog (web, Slack, or from their AI client).
+8. **Approver approves**, and the tool becomes available to the user's AI client.
+9. **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](/product/admin/enable-ai-access-management).
 - Already enabled? Move on to [Set up an MCP server](/product/admin/mcp-servers).
 - Setting up audit and compliance? See [Audit AI tool usage](/product/admin/audit-ai-tool-usage).
 - Ready to test your setup as an end user? See [Get started with AI tools](/product/how-to/ai-tools).
+- Need to approve a discovered resource or manage its access? See [Govern MCP resources](/product/admin/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](/product/admin/enterprise-managed-authorization/overview).

product/admin/audit-ai-tool-usage.mdx

@@ -1,17 +1,17 @@
 ---
 title: Audit AI tool usage
-description: What C1 logs for every AI tool call and AI system event, and where to find audit export options.
+description: What C1 logs for AI tool calls, MCP resource reads, and AI system events, and where to find audit export options.
 og:title: Audit AI tool usage - C1 docs
-og:description: What C1 logs for every AI tool call and AI system event, and where to find audit export options.
+og:description: What C1 logs for AI tool calls, MCP resource reads, and AI system events, and where to find audit export options.
 ---
 
 {/* Editor Refresh: 2026-05-08 */}
 
 <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>
 
-Every tool call that flows through C1 MCP is logged. This page covers what's captured and how to export it for long-term retention, SIEM ingestion, or compliance reviews.
+Every tool call and resource read that flows through C1 MCP is logged. This page covers what's captured and how to export it for long-term retention, SIEM ingestion, or compliance reviews.
 
 ## What gets logged
 
@@ -28,6 +28,8 @@
 | **Denial reason** | Populated when result = denied (for example, "tool not in user's access profile", "kill switch active", "client closed") |
 | **Latency** | Round-trip time for the call |
 
+Each MCP resource read also produces an audit log entry. It includes the end user, AI client, MCP server, resource URI or URI template, result, denial reason when applicable, latency, and response byte count. C1 does not store resource content in the audit event.
+
 In addition to tool call events, the following non-call events are also captured:
 
 - Access request submitted / approved / denied
@@ -50,4 +52,3 @@
 ## Export the audit log
 
 AI tool usage events are included in the C1 system log. To set up export to S3 or another data source for SIEM ingestion, see [System logs](/product/admin/system-log).
-

product/admin/mcp-resources.mdx

@@ -0,0 +1,98 @@
+---
+title: Govern MCP resources
+description: Review MCP resources and URI templates discovered by C1, approve them, and inspect the access state that controls who can read them.
+og:title: Govern MCP resources - C1 docs
+og:description: Review MCP resources and URI templates discovered by C1, approve them, and inspect the access state that controls who can read them.
+---
+
+{/* Editor Refresh: 2026-08-25 */}
+
+<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>
+
+An MCP server can expose more than tools. It can also expose static resources, such as a named document, and URI templates, which resolve a resource from a URI supplied by the client. C1 discovers these items when it discovers the MCP server and governs them independently from tools.
+
+This page describes how to review and manage discovered MCP resources. For tool governance, see [Govern tools and toolsets](/product/admin/tools-and-toolsets).
+
+## How resource access works
+
+Each approved MCP resource has its own read entitlement. A user can read a resource only when all of the following are true:
+
+- The resource is **Approved**.
+- Its linked entitlement is active.
+- The user has a grant for that entitlement.
+- The MCP server and tenant controls allow the request.
+
+A tool grant does not grant access to a resource. Resources are not added to toolsets or exposed as catalog items. C1 does not provide an end-user resource request flow.
+
+Resource content is returned only when the AI client explicitly reads the resource. C1 does not automatically add resource content to a tool call or an AI prompt. Resource access is the same whether the client uses Code Mode or direct tools.
+
+## View discovered resources
+
+To see the resources C1 discovered from a server, open the server's resource inventory.
+
+<Steps>
+<Step>
+Go to **AI > MCP**.
+</Step>
+<Step>
+Open a registered MCP server.
+</Step>
+<Step>
+Click the **Resources** tab.
+</Step>
+</Steps>
+
+The table lists static resources and URI templates that C1 discovered from the server. It includes each item's name, kind, URI or template, MIME type, state, access status, and last-discovered time.
+
+Use the search field to find a name, description, URI, or template. Filter by kind or state when you need to focus on a subset of the inventory. Open a resource to view its complete URI or template, metadata, linked entitlement, grant count, and discovery history.
+
+## Review and change resource state
+
+New resources begin in **Pending** state. They cannot be listed or read by an AI client until you approve them.
+
+| State | What it means |
+| :--- | :--- |
+| **Pending** | Newly discovered and not available to users. You can approve or disable it. |
+| **Approved** | Eligible for use, but each user still needs a grant for the linked read entitlement. |
+| **Disabled** | Not available to any user. You can approve it again when it is ready for use. |
+| **Removed** | The upstream server no longer advertises this resource or template. It is read-only and cannot be read. |
+
+To approve or disable a resource:
+
+<Steps>
+<Step>
+On the MCP server's **Resources** tab, open the resource's **...** (more actions) menu, or click the resource's name to open its details panel.
+</Step>
+<Step>
+Click **Approve** or **Disable**.
+</Step>
+</Steps>
+
+Only the lifecycle state is editable. C1 preserves the URI or URI template exactly as the MCP server advertised it. Changes to discovered metadata retain the resource's state. A changed URI or template is a new pending resource; the old resource is marked Removed.
+
+## Inspect resource access
+
+After you approve a resource, the resource details panel shows its linked read entitlement and grant count. Select either item to open the standard entitlement details page and inspect its current state. Resource entitlements are separate from toolsets and are not available through the end-user request catalog.
+
+The **Access** column identifies resources that are not ready for users:
+
+| Access status | What it means |
+| :--- | :--- |
+| **Entitlement missing** | C1 cannot use the resource until its linked entitlement is available. |
+| **Entitlement inactive** | The resource's linked entitlement is not active. |
+| **No grants** | The resource is approved, but no users can read it. |
+| **Grant count** | The number of grants for the resource's linked entitlement. |
+
+Revoking a grant takes effect on the next resource read, including for an existing MCP session.
+
+## Track discovery changes
+
+C1 repeats discovery on a schedule. Open **View history** from a resource's **...** (more actions) menu, or click the resource's name to open its details panel and select **View history** there. The history shows changes to the resource's metadata, lifecycle state, URI or template, entitlement, and discovery times.
+
+If an upstream server stops advertising a resource, C1 marks it **Removed**. If the server later advertises the same resource identity again, review its current state before it becomes available to users.
+
+## Audit resource reads
+
+C1 logs each allowed and denied resource read. The audit record identifies the caller, MCP server, resource, result, reason for a denial when applicable, latency, and response size. It does not store resource content. For audit-log details and export options, see [Audit AI tool usage](/product/admin/audit-ai-tool-usage).

product/admin/mcp-servers.mdx

@@ -1,17 +1,17 @@
 ---
 title: Set up an MCP server
-description: Register an MCP server with C1, link it to a C1 application, and configure authentication so C1 can govern access to its tools.
+description: Register an MCP server with C1, link it to a C1 application, and configure authentication so C1 can govern access to its tools and resources.
 og:title: Set up an MCP server - C1 docs
-og:description: Register an MCP server with C1, link it to a C1 application, and configure authentication so C1 can govern access to its tools.
+og:description: Register an MCP server with C1, link it to a C1 application, and configure authentication so C1 can govern access to its tools and resources.
 ---
 
 {/* Editor Refresh: 2026-05-29 */}
 
 <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>
 
-This page walks through registering an MCP server with C1, linking it to a C1 application, and configuring authentication. Once registered, C1 automatically discovers the tools the server exposes — see [Govern tools and toolsets](/product/admin/tools-and-toolsets) for what to do next.
+This page walks through registering an MCP server with C1, linking it to a C1 application, and configuring authentication. Once registered, C1 discovers the tools and resources the server exposes. See [Govern tools and toolsets](/product/admin/tools-and-toolsets) and [Govern MCP resources](/product/admin/mcp-resources) for what to do next.
 
 ## Before you begin
 
@@ -34,15 +34,15 @@
 <Step>
 Select which application the MCP server should be registered under:
 
 - **Add to an existing managed or unmanaged app** — select this if you already have a connector-backed C1 app for the same downstream service. The MCP server registers under that app and inherits its user assignments.
 - **Create a new app** — select this if you do not have a connector-backed app for the service. C1 creates a new app for the MCP server. You will need to add users to this app before they can request access to its tools.
 </Step>
 <Step>
-Click **Register**. C1 connects to the server, validates it, and runs initial tool discovery.
+Click **Register**. C1 connects to the server, validates it, and runs initial discovery.
 </Step>
 </Steps>
 
-After registration, the server appears in **AI > MCP** with its discovered tools listed under the **Tools** tab and in the connected app's details page. You can sort the **Tools** tab by tool name, visibility, classification, state, and last updated.
+After registration, the server appears in **AI > MCP**. Its discovered tools are listed on the **Tools** tab. If the server exposes resources, they are listed on the **Resources** tab. You can sort the **Tools** tab by tool name, visibility, classification, state, and last updated.
 
 ## Configure authentication
 
@@ -55,10 +55,10 @@
 | **Basic auth** | A single shared identity via username and password | Services that use HTTP Basic authentication |
 | **Client credentials** | A single shared OAuth client | Machine-to-machine OAuth where per-user identity isn't needed |
 | **OAuth2 — service mode** | A single shared identity (admin authenticates once) | When the downstream requires an OAuth auth code flow but a single shared credential is acceptable |
 | **OAuth2 — per-user passthrough** | Each end user, with their own credentials | When the downstream needs per-user identity (Google Workspace, GitHub, Salesforce, and so on) |
 | **JWT Bearer (RFC 7523)** | A service identity via signed JWT | Services that support certificate-based or JWT-based auth (for example, Tableau or Google service accounts) |
 
 For per-user OAuth passthrough, C1 vaults each user's downstream tokens and auto-refreshes them so end users don't hit token expiry mid-session.
 
 To configure auth:
 
@@ -79,7 +79,7 @@
   - **Per-user (each user submits their own)**: No credentials to enter. Each user provides their own username and password when they connect, and MCP requests run under their individual identity.
 - **Client credentials** — enter client ID, client secret, and token URL.
 - **Service mode** — enter client ID, client secret, authorization URL, token URL, and scopes. An admin completes the OAuth flow once; all users share that credential.
 - **Per-user passthrough** — enter client ID, client secret, authorization URL, token URL, and scopes. End users see a Connect prompt the first time their AI client calls a tool from this server.
 - **JWT bearer** — enter the issuer, private key, subject, audience, token URL, and scopes.
 
 If the server supports OAuth Dynamic Client Registration (DCR), you can skip entering a client ID and secret entirely. Toggle on **Use dynamic client registration** — C1 registers itself with the server's authorization server automatically.
@@ -97,12 +97,11 @@
 | :--- | :--- | :--- |
 | **Authentication** | Required | See above |
 | **Data sensitivity** | Optional | Metadata tag on the server (low / medium / high). Surfaces in the catalog and audit log; no enforcement |
 | **Tool prefix** | Optional; required if multiple servers under one app | Prepended to tool names so AI clients can disambiguate (for example, `gh_` vs `gl_` for two Git providers). If you don't set one, C1 uses the prefix the server's own implementation declares; if it doesn't declare one, C1 generates a default. |
 | **Tool enablement** | Optional | Choose **Require enablement** or **Auto-enable** for this server's tools, independent of your tenant's [default tool approval setting](/product/admin/enable-ai-access-management#require-tool-approval). Leave unset to inherit the tenant default. |
 
 ## What happens after registration
 
-- C1 runs an initial **tool discovery** sweep against the server. Discovered tools appear under the **Tools** tab with state **Pending Review** by default.
-- C1 re-runs discovery on a schedule. New tools appear as Pending Review; tools that disappear are flagged but not auto-deleted.
-- No tool from this server is callable by any end user yet — see [Govern tools and toolsets](/product/admin/tools-and-toolsets) to approve, classify, and bundle them.
-
+- C1 runs an initial discovery sweep against the server. Discovered tools appear under the **Tools** tab with state **Pending Review** by default. Discovered resources and URI templates appear on the **Resources** tab with state **Pending**.
+- C1 re-runs discovery on a schedule. New tools and resources need review. Tools that disappear are flagged but not auto-deleted. Resources that disappear are marked **Removed** and cannot be read.
+- No tool from this server is callable by any end user yet — see [Govern tools and toolsets](/product/admin/tools-and-toolsets) to approve, classify, and bundle them. A resource also needs approval and a user grant before it can be read. See [Govern MCP resources](/product/admin/mcp-resources).