Platform controls are things you configure once at the org or account level that make it structurally harder to do the wrong thing by accident.<\/p>\n
IAM least-privilege guardrails. The permissions available to team-level AWS accounts should be scoped by default. An engineer shouldn\u2019t be able to provision a public-facing resource with a broadly permissioned role without hitting a guardrail. The guardrail doesn\u2019t stop the work. It stops the worst version of the work from shipping silently.<\/p>\n
Secrets manager enforcement. Hardcoded credentials in vibe-coded apps are not a hypothetical. They\u2019re a near-certainty if you don\u2019t make the right path obvious. Enforcing secrets manager usage at the infrastructure level removes the decision entirely from the individual engineer.<\/p>\n
\u201cThe goal here isn\u2019t to slow engineers down. It\u2019s to make the safe path the easy path.\u201d<\/p>\n
VPN-gated deployment targets. Internal tooling should land behind your corporate VPN by default. If something genuinely needs to be public-facing, that should require an explicit decision, not an accidental default.<\/p>\n
Process controls are what have to happen at the tool level before anything ships.<\/p>\n
Automated baseline check. Before a security-informed human looks at anything, automatically run the code and the infrastructure<\/a> configuration against your baseline. Flag violations, tier them by severity, and give the engineer specific remediation guidance. This is the layer a Claude skill or similar tooling can own. The human review then focuses on what the automated check surfaced rather than starting from scratch.<\/p>\n Security-informed code review with Security escalation. Every internally built tool that touches production infrastructure needs a human with security context to look at it before it ships. For lower-risk tooling, that\u2019s a peer engineer who understands the blast radius of what they\u2019re reviewing. For anything with cloud infrastructure, direct data access, or novel IAM roles, it escalates to a formal Security review. Same control, tiered by risk. The key point is that the reviewer actually needs to understand the code. With vibe-coded tools, the author may not fully understand what they built. That makes the review more important<\/a>, not a formality. It\u2019s not just a quality gate. It\u2019s a comprehension gate.<\/p>\n The safety net<\/p>\n The baseline is preventive. Detection is what catches what slips through.<\/p>\n Your CSPM is the right tool for finding misconfigurations in what already exists. Wiz and tools like it will surface the public-facing endpoint, the over-permissioned role, the storage bucket without appropriate access controls.<\/p>\n But CSPM only finds what\u2019s already deployed. The baseline and the review process are what you\u2019re counting on to prevent that. Detection is the catch layer, not the first line.<\/p>\n The harder detection problem is knowing something exists in the first place. A vibe-coded tool running locally or in a team account may leave no trace in your normal visibility layer. No deployment pipeline. No change ticket. No asset inventory entry.<\/p>\n This is where behavioral signals in your cloud telemetry start to matter. IAM role creation outside your normal pipeline activity. New public-facing resources appearing without a corresponding change record. API calls originating from developer<\/a> machines directly into production accounts rather than through your standard tooling. None of these signals are definitive on their own. In combination, they start to look like something that deserves a closer look.<\/p>\n Most teams aren\u2019t looking for these signals specifically in the context of agent-built tooling. That\u2019s the gap worth closing.<\/p>\n The codified baseline<\/p>\n Documentation that lives in a wiki is a baseline that nobody uses when they need it. The better path is to make the baseline available within the tools engineers are already using, at the point of building.<\/p>\n A Claude skill or similar AI-native tooling that reviews architecture descriptions or generated infrastructure against your specific security baseline is more useful than a checklist in Confluence. The engineer gets specific, actionable feedback before a human reviewer ever sees it. The security team gets a first pass that\u2019s already been filtered for the obvious failures. The review is better because it starts from a more complete picture.<\/p>\n None of this works if engineers don\u2019t know the skill or if the review process doesn\u2019t exist. Awareness is its own prevention layer. Introducing both during onboarding makes the safe path visible, and letting the skill\u2019s feedback do double duty as education on why each check matters makes it stick. A guardrail that doesn\u2019t announce itself isn\u2019t preventive.<\/p>\n That\u2019s where we\u2019re headed internally. The blog post is the argument for why this matters. The skill is what operationalizes it.<\/p>\n The takeaway<\/p>\n Vibe-coded internal tools are not going away. The friction that used to slow down ungoverned infrastructure is gone, and it\u2019s not coming back. The question is whether your security baseline catches up before your CSPM does.<\/p>\n Platform controls make the safe path the default. Process controls make sure a human with security context sees everything before it ships. Detection gives you a catch layer for what slips through anyway.<\/p>\n \u201cBuild the baseline before the CSPM finds it for you.\u201d<\/p>\n None of this requires a dedicated AppSec team or a SOC. It requires a clear baseline, the tooling to enforce it, and engineers who understand what they\u2019re reviewing. That\u2019s a problem a small, well-structured security team can solve. Platform controls are owned at the org or SecEng level, set once and applied everywhere. Process controls are distributed: a peer engineer with security context handles lower-risk tooling, while anything touching cloud infrastructure, direct data access, or novel IAM escalates to a formal Security review. That\u2019s distributed responsibility with a clear escalation path, not a single team reviewing everything.<\/p>\n Build the baseline before the CSPM finds it for you.<\/p>\n This article was originally published on August 13, 2026, on webflow.com<\/a>.<\/p>\n
![](\"https:\/\/www.newsbeep.com\/il\/wp-content\/uploads\/2026\/09\/5f5aae47-andygombar.png\"\/)
<\/p>\n