What stops a developer from editing a workflow to deploy something nonstandard or expensive?

In Azure DevOps, we used some pipeline templates and allowed only the Azure team to modify these production release steps. This helped us control what got deployed to Azure. I'm unsure how to think about control/policy aspect in GitHub. I want to be able to show to an auditor that only approved code/infra got deployed and am looking for ideas and solutions.

Here is what I'm thinking so far

• I know that I can add an environment on my GitHub repo, for example I could call it 'prd'.
• I know that we can have our azure team approve the 'prd' environment.
• However, I'm not sure how to verify that the pipeline run being approved/deployed is not deploying something nonstandard.
• One idea was to use standard YAML templates, but even if we call templates, there isn't really anything stopping any contributor from adding more infra to the YAML file, right?

Is there can we be sure some other unwanted resources aren't being deployed via a contributor-added step?

This is what an 'Environment' looks like. It allows me to protect Azure connection secrets behind an approval but doesn't provide any guardrails to the pipeline code itself which uses that connection:

You can set platform team as CODEOWNERS on the .github/workflows directory so that any change to the workflow files requires platform team approval. This provides strict control but will require your platform team to have access to all repos. This will also create a dependency on the platform team and add extra time demand on the team.