Thanks for sharing the additional context.
For opening a non-embedded QuickSight console, you don’t have to generate any embed URL. You can simply direct them to QuickSight using a URL pointing to the desired asset, like a dashboard - e.g. https://eu-west-1.quicksight.aws.amazon.com/sn/dashboards/<DASHBOARD-ID>. While you can append parameters to that URL, users could change them as they wish.
Parameters are no mechanism to restrict access to data that a user can see. To achieve that, you should have a look at the row-level-security (RLS) capability that QuickSight offers.
You mentioned that you are opening QuickSight in a new browser so that users can check your application and QuickSight at the same time. What most customers do instead in such cases is to embed QuickSight into their application, so that they have the insights from QuickSight right next to the content from their own application. Additionally, the embedding SDK allows you to build an advanced integration between the two, by adding callback functions, listening to events, or triggering certain actions or filtering from within your parent application. In such a case, your parameters or filters would also not be directly visible to the end user (but again, if it is all around security and restricting access to the dataset, please look at RLS).