Skip to main content

Permissions & Resources

For MCP applications, the useful runtime question is effective access: can this principal call this tool for this application right now, and why?

AuthSec models that as:

  • Application: the protected resource server.
  • Tool: the MCP capability being called.
  • Scope/access label: the capability label granted into OAuth tokens.
  • Application role: a bundle of labels operators can assign to users or groups.
  • Access assignment: the binding from principal to application role.

The current SDKs enforce this model through the runtime mount APIs. They do not ask application code to create permissions or bindings from inside request handlers.

Runtime enforcement​

import { loadConfigFromEnv, mountMCP } from "@authsec/sdk";

mountMCP(app, {
  path: "/mcp",
  handler: mcpHandler,
  config: loadConfigFromEnv(),
});
from authsec_sdk import from_env, mount_mcp

cfg = from_env()
mount_mcp(app, "/mcp", existing_handler, cfg)

The SDK:

  1. Validates the bearer token.
  2. Resolves the application policy from AuthSec.
  3. Checks the requested tool against mapped scopes.
  4. Denies safely when policy is unavailable in remote_required mode.

Debugging access​

Use Effective Access in the AuthSec console when you need a human-readable answer for a user, client, application, and tool combination. It shows the verdict, the access path, the failed condition if denied, and the safest remediation.

The older authz-sdk permission helper examples are not the recommended path for new MCP protection work.