Skip to main content
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.
Scopes are how you control what an agent’s token can do at an MCP server. This page covers turning a server’s scopes into C1 entitlements, bundling them into access profiles, and the levers you use to grant and revoke access.

​
Scopes are individual entitlements

Each scope an MCP server exposes becomes its own C1 entitlement. Because a scope is an entitlement, you can request, review, certify, and audit it on its own, the same way you govern any other access in C1. A server can expose many scopes. Modeling each scope as its own entitlement gives you per-scope governance. It does not put C1 between the agent and the system on each call. C1 evaluates your policy when it issues a token, not on every API call the agent makes afterward.

​
Add and enable scopes

You bring an MCP server’s scopes into C1, classify each one, and enable the scopes you want to expose. This happens on the resource server’s Scopes tab (open the resource server from the application’s Cross-App Access tab). The tab lists each scope with its State, Classification, and Source, offers a Pending review quick filter, and has a Declare scope button for adding one by hand.
1
Get the scopes into C1.Scopes are discovered automatically in the background — imported from the server and listed with source Discovered in a Pending review state so you can confirm them before use. To add one by hand, click Declare scope and fill in the drawer: Scope value (the literal OAuth scope string, required and immutable after creation), Display name (required), Description, Classification, and State. Click Declare.
2
Classify each scope.The Classification field offers Unclassified (the default), Read, Write, Destructive, Sensitive, and Dangerous. The classification is metadata you use to filter and reason about scopes.
3
Enable the scopes you want to expose.On the Scopes tab, use the row’s State toggle, or the ⋯ menu’s Approve action (which moves a scope to Enabled) — and Disable to turn one off. You can select multiple scopes and use the Approve / Disable bulk actions in the footer. The Pending review (n) quick filter and the State / Classification / Source filters help you work through newly discovered scopes.
Only enabled scopes can be issued in a token. Scopes are never enabled automatically. Enabling a scope is the ceiling on what C1 will ever put in a token for that server.

​
Bundle scopes into access profiles

An access profile is a named bundle of scopes that users request as one item. Manage profiles on the resource server’s Access profiles tab, where you create a profile and then open it in edit mode to bind scopes in its Bound scopes section.
1
Create an access profile.On the Access profiles tab, click Create access profile, enter a Display name and Description, and click Create. (Scopes are bound in the next step — the create drawer has no scope picker.)
2
Bind the scopes you want to include.Open the profile again (click its name, or ⋯ → Edit). The edit drawer adds a Bound scopes section: use Add scopes to search this resource server’s scopes, select them, and click Add. Remove a bound scope with the trash icon on its row. The drawer also shows a Requestable via link to the backing entitlement in the request catalog.
Users request the profile, and a grant covers every scope bound to it.

​
Revoke access

You have several levers to revoke access. Each takes effect at the next token request, not on tokens that are already issued.
No lever cancels a token that’s already been issued before it expires. A revoked grant stops the next token request; any token already in the agent’s hands keeps working until it expires. The default token lifetime is 300 seconds (5 minutes), which sets how long in-flight access can persist after you revoke a grant.
LeverScopeWhen it takes effect
Revoke a scope or profile grantOne userThe next token request is denied; tokens already issued live until they expire (default 300 seconds)
Disable a resource serverA whole MCP serverThe next token request is denied
Disable the userAll of that user’s token requestsThe next token request is denied

​
Where to go from here

Once a profile exists and your access request settings are configured, users can request it from the standard C1 catalog — there’s no further setup step here.