Thanks for sharing the additional context.
For opening a non-embedded Quick Sight console, you don’t have to generate any embed URL. You can simply direct them to Quick Sight 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 Quick Sight offers.
You mentioned that you are opening Quick Sight in a new browser so that users can check your application and Quick Sight at the same time. What most customers do instead in such cases is to embed Quick Sight into their application, so that they have the insights from Quick Sight 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).