When designing a platform, you need to ensure security and compliance. There are two fundamentally different philosophies for doing this: Gates and Guardrails.
Gates: Blocking Progress
A Gate is a checkpoint that stops a process until a human approves it. It is a "stop and ask for permission" model.
- Example: A developer wants to deploy to production. The CI/CD pipeline pauses and sends a Slack message to the security team. A security engineer reviews a spreadsheet of changes, approves or rejects, and the pipeline resumes — two days later.
Gates are effective at catching problems, but they have serious costs:
- They create bottlenecks that scale with the number of deployments, not the size of the security team.
- They introduce waiting time that kills developer momentum and delays incident response.
- They shift responsibility from the developer to the reviewer, reducing ownership.
- They are often theater — reviewers rubber-stamp approvals because they lack context or are overwhelmed.
Guardrails: Enabling Safe Speed
A Guardrail is an automated boundary that keeps developers on a safe path without stopping them. It is a "move fast within safety limits" model.
- Example: A developer writes Terraform code to create an S3 bucket. An automated policy-as-code check (using a tool like Open Policy Agent or Checkov) runs in the CI pipeline in under 30 seconds. If the bucket is configured to be public, the pipeline fails immediately with a specific, actionable error:
ERROR: S3 bucket 'my-bucket' has public ACL. All buckets must be private per policy SEC-042. See: [runbook link]. If it's private, the pipeline proceeds automatically with no human involved.
Guardrails are embedded into the platform itself. They provide immediate feedback, scale infinitely, and allow developers to move quickly and autonomously — knowing that the platform won't let them make a catastrophic mistake.
When Gates Are Still Appropriate
Guardrails are almost always preferable to gates for routine compliance checks. However, gates remain appropriate for:
- Irreversible, high-blast-radius actions: Deleting a production database, decommissioning a critical service, or making a change that affects all customers simultaneously.
- Regulatory requirements: Some compliance frameworks (SOC 2, PCI-DSS) explicitly require human approval for certain change categories. In these cases, the gate is non-negotiable — but it should be as narrow as possible, covering only what the regulation requires.
- Novel risk: When a change is genuinely unprecedented and automated policy can't yet assess it, a human gate is appropriate while you build the guardrail.
The goal is to minimize the surface area of gates over time by converting manual reviews into automated policy checks wherever possible.