Audit MCP access

What C1 records for every token request, how to read a denial, and how to debug a signature rejection at the MCP server.

Early access. This feature is in early access, which means it’s undergoing ongoing testing and development while we gather feedback, validate functionality, and improve outputs. Contact the C1 Support team if you’d like to try it out or share feedback.

C1 records every enterprise-managed authorization token request, granted or denied. This page covers what each record holds, how to read a denial, and how to debug a token an MCP server rejects.

Audit MCP access in your SIEM

The recommended way to audit MCP access is to stream C1’s events into your SIEM. C1 emits every enterprise-managed authorization and MCP access event to the system log, and the System log exporter forwards them to the SIEM or log store you already use for the rest of your security data.

To set it up, go to Settings > Security > System log > Add exporter and point the exporter at your destination. From then on, every token request C1 records — the fields and status details described below — lands in your SIEM, where you can search, alert, and retain it alongside everything else. See System logs.

C1 recommends this approach for every customer auditing MCP access, not just enterprise tenants. You can also use Read and download system logs to read the same events directly in C1.

What’s recorded

C1 writes one audit event for every token request, whether it’s granted or denied. Each event records who asked, what they asked for, and what C1 decided.

Field	What it records
User	The C1 identity the token was requested for
Client	The agent’s client that made the request
System	The MCP server the token is for (the token’s audience)
Scopes	The scopes requested and the per-scope outcome (granted or denied)
Token ID	The identifier of the issued token
Signing key ID	The key C1 signed the token with
Algorithm	The signing algorithm C1 used (ES256 by default)
Lifetime	How long the token is valid
Status detail	On a denial, the reason the request was denied

Read a denial

When a request is denied, the status detail names the cause. Use this table to map a status detail to what to fix.

Status detail	Cause
No grant for the scope	The user does not hold a grant for a requested scope
Scope not enabled	The requested scope exists but is not enabled on the system
Server paused	The resource server is paused, so no token is issued for it
Target URL not registered	The call’s target URL is not registered on the resource server
No signing key for the algorithm	No signing key exists for the chosen algorithm

Debug a signature rejection

A token that C1 issued successfully can still be rejected by the MCP server. When that happens, the audit record for the issuance points to the cause. Check the signing key ID and algorithm columns first: C1 signs with ES256 by default, and if the server’s authorization server expects a different algorithm, it rejects an otherwise valid token. The fix is to set the server’s signing algorithm to one its authorization server verifies.

What C1 sees, and what it doesn’t

C1 records the issuance decision: every token request, granted or denied. It does not see the agent’s later API calls, because those run directly against the MCP server and never pass through C1.

To retain these events long-term and search them alongside the rest of your security data, stream them to your SIEM with the System log exporter.