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