Start with the correct MCP resource
SpringRoll serves its own deployment and app-management tools. Coding clients use /api/mcp; ChatGPT uses /api/mcp/chatgpt. Each publishes protected-resource metadata so an OAuth-capable client can find the authorization server.
The MCP authorization specification describes a flow based on OAuth 2.1 with PKCE and resource indicators. SpringRoll validates the requested resource and the registered client before presenting consent. A reachable discovery URL is not permission to read tenant data.
Bind consent to the client, redirect and PKCE challenge
SpringRoll requires S256 PKCE, registered redirect matching and a short-lived authorization code. The token exchange checks the client, redirect, verifier and resource. An authorization code cannot be spent twice.
HTTPS callbacks, local loopback callbacks and qualifying private-use schemes are supported. Wildcards and unsafe redirects are rejected. Client compatibility must fit those rules; the Cursor guide uses its CLI login path rather than relaxing redirect validation.
Guest onboarding uses the same authorization checks. Opening the consent page does not create a guest; choosing Connect SpringRoll does. A guest connection represents the saved credential, not a verified identity at the AI provider.
Review scopes and workspace permissions separately
For ChatGPT, the resource accepts the scopes below. The general coding-client endpoint uses springboard:agent and the member’s role. A tool name being visible does not prove that the connected member can execute it.
Scroll sideways to see all columns. With the table focused, use the arrow keys.
| Scope | What to review |
|---|---|
| springroll:read | Read authorized context and resources. |
| springroll:deploy | Deployment operations, with the member’s permissions and applicable checks. |
| springroll:write | Supported changes to authorized resources. |
| springroll:confirm | Submit the member’s explicit approval of one exact proposal. This is not standing approval for future actions. |
Confirm the exact proposal, then verify its outcome
ChatGPT prepares a proposal before a deployment or other supported change. The user reviews its target and effect, then confirms that exact proposal through SpringRoll or explicitly instructs an authorized client to submit the confirmation. Changed, expired or unauthorized proposals do not become permission for a different action.
A configured Staged release still needs the required human reviewer. Data grants and launch audiences remain separate decisions. The operation and audit record are written transactionally; asynchronous provider work must still be followed to its actual result. An accepted request is not a successful deployment.
Test revocation and preserve the audit record
Refresh tokens rotate. Revoked grants and inactive memberships cannot continue acting as an authorized member. Review the recorded client, workspace, operation and result when investigating an action, without copying raw credentials into tickets or chat.
Revoke the relevant OAuth grant when removing an agent’s access. A guest browser credential and a saved OAuth connection have separate revocation lifecycles; signing out of the browser is not the same as revoking the agent.
Run a small security acceptance check
Use a synthetic project in an authorized test workspace. Record the release, test identity, expected denial and actual result. These are checks to perform in your environment, not claims that a particular customer environment has passed.
- Read the workspace identity and confirm that it is the intended owner.
- Try an out-of-scope operation and a resource belonging to another workspace; verify denial.
- Prepare a change, inspect it, confirm only that proposal and follow the result.
- Revoke the connection and verify that the next authenticated call is denied.
- Test the app’s direct provider URL and private API separately from the App Portal link.