I think you mistake 'authorized' with 'approved'.

Authorized is:

Restricted push access. Access to main follows business function: every engineer at Amp can push, and most of Amp is engineers. But the percentage of people with access matters less than being able to explain exactly who has it and why.

So like you know exactly who can push the code and let's say random from marketing can't push code because he is not authorized.

No, I understand that. Authorisation is a basic feature of pretty much any hosted version control system.

What is less clear here is approvals.

> What is less clear here is approvals

This. My understanding is that SOC2 does require approvals (eg 2nd person reviews/approves the code change). This approach doesn't seem to include that step. Is that not a requirement?

SOC2 requires basically nothing beyond that you follow the procedures that you say you're going to follow. The relevant text of CC8.1 is:

> The entity authorizes, designs, develops or acquires, configures, documents, tests, approves and implements changes to its infrastructure, data, software, and procedures to meet its objectives.

You'll note that this doesn't actually say much of anything.

It's very common for companies which are working on SOC 2 compliance to write down that all changes will be reviewed and once you do that you're required to actually follow through and do it, but you don't have to write down that all changes will be reviewed. The point of SOC2 is mostly that if you are vibing slop into production you have to document that fact (or rather, document your lack of change controls that make it possible) and so your customers can be aware of that. Large conservative customers may insist on more rigid processes as a condition of buying from you.

Amp will probably claim the agent wrote the code and the human approved it

That is seems is the main point of the article, that you don't need approvals for SOC2.