Summary The OAuth token strategy attached "oauth_scope" and "oauth_granted_resources" to the request user, but the ACL middleware never consulted either. An OAuth token issued with a restricted scope (e.g. MCP-only) therefore inherited the full permissions of the underlying user across all routes; the "granted_resources.base_id" restriction was bypassed on org-level endpoints that don't populate "req.context.base_id". Details In "packages/nocodb/src/strategies/oauth-token.strategy.ts", the strategy set "is_oauth_token", "oauth_client_id", "oauth_granted_resources", and "oauth_scope" on the user object, then mapped through to the user's existing "roles" / "base_roles". The ACL middleware in "extract-ids.middleware.ts" honoured "is_api_token" via "blockApiTokenAccess" but had no equivalent gate for "is_oauth_token" or scope-string enforcement. The base/workspace restriction logic short-circuited when "req.context.base_id" was unset (org-level routes), so an OAuth token scoped to one base could still call org-level endpoints as the underlying user. The fix adds a path-prefix allowlist ("['/mcp', '/api/v3/', '/auth/user/me']") enforced inside the strategy and a "blockOAuthTokenAccess" ACL flag for endpoints that should never accept OAuth tokens. Impact - Scope escalation: tokens issued with a narrow scope received the underlying user's full role. - Resource boundary bypass: per-base restrictions did not apply to org-level routes. - Violates least-privilege expectation for third-party OAuth integrations. Credit This issue was reported by "@ik0z" (https://github.com/ik0z).