CSPM ends up as the intake queue for agent-provisioned infrastructure

The boundary itself disappears, because the whole sequence happens inside infrastructure you already control. The employee is real, the credential is one you issued, and the account is one you already pay for ^[7]. All four of the signals the piece names for the SaaS era are records of a tool sitting outside your infrastructure ^[2][1]. A resource created inside the account emits none of them, which is why the author frames the change as SaaS sprawl becoming code sprawl and says the detection playbook does not carry over ^[12].

That leaves CSPM as the first detector, and CSPM is a scan. In the worked example the app runs for six weeks before the finding lands on a public-facing endpoint with an over-permissioned IAM role ^[3], so 42 days of exposure precede the alert ^[2]. The author's read is that lateral movement is realistic rather than theoretical by then ^[8]. The engineer never filed a ticket, because none was required ^[3], which is the one detail in the story that survives contact with any organisation.

The speed claim is what breaks the process-control answer. The agent writes code, generates Pulumi programs and stands up infrastructure faster than any review process can handle ^[13], and the engineer is helping rather than evading, so there is nothing for a policy-enforcement posture to push against ^[6]. A procurement gate assumes someone is trying to get past it.

Which is why the interesting half of the proposal is the platform layer. Of the three controls named, IAM least-privilege guardrails are described as scoping the permissions available to team-level AWS accounts by default ^[5][3]. That has a prerequisite the piece does not state: team-level accounts. If your engineers provision into one shared account, there is no ceiling you can lower for them without lowering it for the platform team too. VPN-gated deployment targets carry the same condition, because "behind the VPN by default" needs a paved deploy path you own rather than whatever the agent picks ^[5]. Secrets manager enforcement is the strongest of the three, and for a specific reason: it is the only one that does not depend on the engineer or the agent knowing your conventions. The author's phrasing is that it removes the decision entirely from the individual engineer ^[5]. That is the right shape for a control.

This evidence carries two limits worth naming. This is a baseline being built toward at Webflow, described without an incident count or a measured detection lag ^[4]. And the version supplied here breaks off mid-sentence as it starts on the tool-level process controls ^[10], so the half that would act before the agent runs is not in front of us.

In my context I would spend on the ceiling before the scanner. A scoped account enforces itself on every API call, while a scan only enforces itself on its own schedule. That preference assumes multi-account topology and engineers who already hold provisioning rights. If you do not have the first, the argument points at building the account boundary before buying more detection.