Anybody know how to lower the sec-risk of someone running a dag for a phi-job and parametrizing in a public s3 bucket?

can you say more?

Yeah so Analyst B sets up a report to pull claims from the warehouse and roll them up Analyst A knows that their ex-partner works for company Y and runs that job with parameters to extract this person's medical history. Access control in the face of dynamic parameters and such.

Hey Manny- one way I could imagine doing this today is: • apply a tag to runs at launch time that determines who the submitting user is by checking headers or other properties of the request to Dagit (https://docs.dagster.io/guides/dagster/run-attribution#custom-run-coordinator has a slightly clunky example of how you might do this by using a custom run coordinator component - if your goal is to disallow certain users from launching the job at all, you could also just fail the run submission in the submit_run call, rather than applying a tag) • You could also check that tag's value in your op function (context.pipeline_run.tags) and use it to incorporate identity into your op execution - for example, changing which permissions are available to which users Not sure how well either of those solutions map to the use case you had in mind, but it's one possibility.