A compromised npm maintainer account pushed malicious versions of Axios, one of the most widely used JavaScript libraries, to the registry. The attack, which hit last month, bypassed GitHub Actions entirely. The attacker published directly via the npm CLI with stolen credentials. A hidden dependency deployed a remote access trojan. For three hours, every npm install that pulled the affected versions was compromised. The blast radius extended further than anyone expected: the attack later reached OpenAI’s own macOS signing pipeline, forcing certificate rotation.
The same month, CVE-2025-55182 turned React’s server-side rendering mechanism into an attack vector. A deserialization flaw in React Server Components was exploited through Next.js to breach 766 hosts, stealing database credentials, SSH keys, and AWS secrets. The framework that developers trusted as infrastructure became the entry point.
A week later, CVE-2026-33579 exposed a privilege escalation vulnerability in OpenClaw, an open-source AI agent platform. Over 135,000 instances were running with zero authentication. A non-technical manager at one organization had set up OpenClaw on a personal VPS without IT approval. Shadow IT, but with an AI-powered attack surface.
Three incidents in the same month, with three different attack vectors, yet the same underlying failure: in every case, the security review gate that was supposed to catch the problem came after the vulnerable decision had already been made.
The Axios attack slipped past code review because the malicious code never went through the repository. The Next.js exploit survived penetration testing because the vulnerability lived in the framework, not the application. The OpenClaw exposure evaded access review entirely because the deployment happened outside the organization’s visibility.
Security gates review what has already been built. They cannot prevent what was never designed to be secure.
The Gate Model and Why It Persists
The dominant security model in most organizations is a gate: development builds something, then security reviews it before it goes to production. The gate has different names depending on the organization: security review, penetration test, compliance check, architecture review board. The mechanism varies, but the structure is the same: build first, validate later.
This model persists because it is organizationally convenient. It gives security teams a defined role with clear boundaries. It gives development teams freedom to build without interruption. It gives leadership a checkbox: “security reviewed.”
The problem is that the gate model was designed for a world where the development cycle was measured in months, the attack surface was relatively stable, and the number of dependencies was manageable. None of those conditions hold anymore.
Modern development cycles are measured in days or hours. AI coding tools accelerate this further. A developer using an AI assistant can generate and deploy code faster than any security team can review it. The attack surface now includes not just the code you write, but every dependency your tools install, every framework you trust, every API consent your admin approves, and every AI agent that acts on your behalf.
When I wrote about threat modeling in the cloud, the argument was that security considerations must happen before deployment, not after. That argument has only gotten sharper. Shifting security left is no longer the debate; the real challenge is making security an inherent property of the development process rather than an external validation of its output.
What Breaks When Security Is Only a Gate
The symptoms are consistent across organizations that rely on gate-based security.
The dependency blind spot. When an AI coding tool runs npm install or pip install, it is making a security decision. It is trusting a package, its maintainers, its transitive dependencies, and the registry’s integrity. The Axios attack demonstrated that this trust can be exploited at the registry level, bypassing every code-level security control. A security gate that reviews application code cannot catch a compromised dependency that was installed before the review.
The scale of this problem is growing. AI agents that auto-install dependencies multiply the blast radius. Every automated npm install is an unreviewed trust decision. When the development process generates dependencies faster than the security process can evaluate them, the gate becomes a bottleneck that teams route around, or a formality that catches only what it was designed to catch.
The framework-as-attack-surface problem. The React2Shell exploit (CVE-2025-55182) turned a trusted framework into an attack vector. Security gates typically assume that frameworks are safe. They review the application code, not the framework code. But when the framework itself is the vulnerability, the gate model has a structural blind spot. The 766 breached hosts were running applications that would have passed any standard security review.
The consent-path gap. When Anthropic extended Claude’s Microsoft 365 connector to all users, it created a data path that flows through the Graph API, not through the browser. Endpoint controls and browser policies do not see this path. A Global Admin consents, and suddenly an AI model has read access to corporate email and meeting transcripts. The security gate for this decision is a consent dialog, with no threat model, no data flow analysis, and no governance framework for evaluating AI data connector requests.
This is the pattern I described in the GenAI governance gap: organizations deploying AI capabilities without the governance infrastructure to manage them. The consent-path gap is the security dimension of that governance gap.
The velocity mismatch. this month, Anthropic revealed that their Claude Mythos model autonomously discovered thousands of zero-day vulnerabilities across every major operating system and browser, including a 27-year-old bug in OpenBSD, a 16-year-old flaw in FFmpeg, and full browser sandbox escapes. The previous model produced 2 working exploits from hundreds of attempts on Firefox. Mythos produced 181.
Vulnerability discovery just became cheap and fast. Patching millions of deployed systems is still slow and expensive. When AI can find vulnerabilities at machine speed, a security model that depends on periodic reviews and scheduled penetration tests is structurally outmatched. The gate opens once a quarter. The attacks arrive continuously.
Security as a Constraint, Not a Checkpoint
The alternative to the gate model is not “no security.” It is security embedded as a constraint in the development process itself, the same way that type safety is a constraint in a typed language. You do not run a “type safety review” after writing code in TypeScript. The compiler enforces it continuously. Security constraints should work the same way.
A constraint is different from a gate in three ways:
Constraints are continuous, not periodic. A gate fires once, at a defined point in the process. A constraint is always active. Every commit, every dependency installation, every infrastructure change is evaluated against the constraint in real time.
Constraints are preventive, not detective. A gate detects problems after they exist. A constraint prevents them from being introduced. When a pipeline rejects a deployment because it contains a hardcoded secret, that is a constraint. When a penetration test finds a hardcoded secret in production, that is a gate, and it is too late.
Constraints are owned by the development team, not the security team. This is the cultural shift that most organizations resist. When security is a gate, the security team owns it. When security is a constraint, the development team owns it, with the security team defining the constraints and verifying their enforcement. The security team becomes the architect of the constraints, not the operator of the gate.
The most compelling example of this shift happened this month. The Linux kernel, the most foundational open-source project in the world, formalized its policy on AI-generated code in 59 lines. AI agents cannot add Signed-off-by tags. Only humans can certify the Developer Certificate of Origin. Every AI-assisted contribution must carry an “Assisted-by” tag identifying the model and tools used. The human submitter takes full legal responsibility for every line, every bug, and every security flaw. The kernel community did not create a review gate for AI code. They embedded accountability as a constraint in the contribution process itself: attribution is mandatory, human sign-off is non-negotiable, and responsibility is unambiguous. If the Linux kernel can formalize AI code accountability in 59 lines, the question for every engineering organization is why they haven’t.
Five Constraints That Replace the Gate
These are not aspirational. They are implementable today, and organizations that have adopted them report fewer security incidents, faster deployment cycles, and less friction between security and development teams.
1. Dependency Governance in the Pipeline
Every dependency installation must be validated against a policy before it enters the build: pinned versions, verified checksums, known-vulnerability scanning, license compliance. This is not a periodic audit of package-lock.json. It is a pipeline step that fails the build if a dependency violates the policy.
For AI-assisted development, this constraint is critical. When an AI agent generates code that includes a new dependency, the pipeline must validate that dependency before the code is merged. The agent’s speed does not exempt it from the constraint.
2. Secrets Detection as a Pre-Commit Hook
No secrets in source code. This is a constraint, not a policy. A pre-commit hook that scans for API keys, database passwords, and credentials before the code leaves the developer’s machine. A pipeline step that scans again before merge. A runtime check that flags any secret that appears in logs or error messages.
The number of repositories where I still encounter hardcoded credentials is remarkable. The tooling exists. The barrier is cultural: the belief that “we’ll fix it later” is acceptable when the constraint should make “later” impossible.
3. Infrastructure Policy as Code
Security policies for infrastructure should be codified and enforced in the deployment pipeline. Encryption requirements, network segmentation rules, IAM least-privilege policies, tagging standards: all validated automatically before any template is applied. If a Terraform module creates a public S3 bucket, the pipeline fails. No exception. No manual approval.
This connects directly to the argument in Infrastructure as Code Is Not DevOps. IaC without automated governance is automated provisioning with an exposed attack surface. The governance layer is the security constraint.
4. AI Data Connector Review Framework
Every AI tool that requests access to organizational data must go through a defined review process before consent is granted: what data does it access, through what path, what controls apply to that path, who approved it, and when does the approval expire?
This is the constraint that would have changed the Claude M365 connector story. Instead of a Global Admin making a consent decision alone, the organization would have a framework: data classification check, DLP coverage verification, access scope review, and a documented approval with an expiration date.
5. Threat Model as a Development Artifact
A threat model should not be a document that security produces and developers ignore. It should be a development artifact that lives alongside the code, updated when the architecture changes, referenced when new features are designed. When a developer adds a new API endpoint, the threat model for that service should be updated as part of the same pull request.
This is the evolution of the argument I made before in other post: threat modeling must happen before deployment. The next step is making it a living artifact that evolves with the code, not a one-time exercise that becomes stale the moment the architecture changes.
The Enterprise Guardrails Model
There is a structured way to implement security constraints across an organization. In the AI-DLC methodology, we use what we call Enterprise Guardrails Specifications: a set of non-negotiable principles, constraints, and standards organized by category, each with a severity level and a designated owner.
The categories cover security baseline, compliance constraints, architectural guardrails, coding standards, operational readiness, cost guardrails, and AI-specific guardrails. Each guardrail has a severity: mandatory (violation blocks the deployment), required (exceptions need a documented decision with risk acceptance), or recommended (best practice, deviation noted but not blocked).
The key design decision is that guardrails are enforced in the development process, not reviewed after it. Every code generation session, every infrastructure change, every deployment is validated against the guardrails automatically. The AI collaborator itself is instructed to validate its output against the guardrails before presenting it to the team.
This is security as a constraint — the guardrails do not slow down development, they channel it. Teams that work within well-defined guardrails move faster, not slower, because they do not waste cycles on rework, security findings, or compliance remediation after the fact.
The Enterprise Guardrails model is explored in depth in Reimagine, Don’t Retrofit, where it connects to the broader argument that AI-driven development requires governance by design, not governance by review.
The Cultural Resistance
The biggest obstacle to security-as-constraint is cultural, not technical.
Development teams resist constraints because they associate security with friction. “Security slows us down” is the most common objection. But the friction they experience is the gate model: build something, wait for security to review it, get findings, rework, resubmit. That friction is real, and it is a product of the gate, not of security itself.
Security teams resist the shift because it changes their role. In the gate model, the security team is the authority. They review, they approve, they reject. In the constraint model, the security team defines the rules, but the pipeline enforces them. The security team’s value shifts from operational gatekeeping to architectural design. That is a more impactful role, but it requires different skills and a different identity.
Leadership resists because constraints require investment. Building automated policy enforcement, dependency governance, secrets detection, and threat modeling workflows costs time and money upfront. The gate model is cheaper to start: hire a security team, schedule reviews, check the box. The constraint model is cheaper to operate: fewer incidents, faster deployments, less rework. But the upfront investment is real.
What Engineering Leaders Should Ask Now
The incidents of early 2026 have made the argument concrete: supply chain attacks that bypass code review, framework vulnerabilities that bypass application security, AI data connectors that bypass endpoint controls, and vulnerability discovery at machine speed that outpaces quarterly reviews.
Each of these breaks the gate model in a different way. Together, they make the case that security must be embedded in the development process as a constraint, not applied to its output as a review.
Every organization does security. But few have a security model designed for the speed, complexity, and attack surface of how software is actually built today.
If your security still depends on a gate that fires after the code is written, the dependencies are installed, and the infrastructure is deployed, the gate will keep finding problems. It will just find them too late.
Ricardo
