Scopes
In AuthSec's current MCP model, scopes are application access labels. They describe the runtime capabilities an OAuth token may receive, and the SDK enforces them against each tool call.
New applications should not create scopes from protected application code. Use the AuthSec console or the application aggregate APIs so AuthSec can show impact previews, affected users, tool mappings, and audit evidence before the scope changes.
Runtime SDK behavior
The SDK publishes suggested tool-to-scope mappings from your manifest. Operators review those suggestions in the application Scopes and Tools screens.
import { loadConfigFromEnv, mountMCP } from "@authsec/sdk";
mountMCP(app, {
path: "/mcp",
handler: mcpHandler,
config: loadConfigFromEnv(),
tools: [
{
name: "list_repos",
suggested_scopes: ["github:repos:read"],
risk_level: "low",
},
],
});
from authsec_sdk import from_env, mount_mcp
cfg = from_env()
mount_mcp(
app,
"/mcp",
existing_handler,
cfg,
tools=[
{
"name": "list_repos",
"suggested_scopes": ["github:repos:read"],
"risk_level": "low",
}
],
)
Where to manage scopes
- Application Scopes: create, attach, edit, and delete access labels with impact preview.
- Application Tools: map each tool to the access label required at runtime.
- Effective Access: simulate whether a user, client, and tool combination is allowed and why.
The older authz-sdk helper docs are not the recommended path for new MCP protection work.