In July, a Cursor cloud agent working in our repository wrote code that would have leaked every credential our backend holds. It was fixed in seconds, never reached a commit, and no reviewer ever saw it.
We caught it because we had moved security review from the pull request to the commit a few weeks earlier. Here is why, and what happened when we did.
Where we started
In January, zero pull requests against our monorepo came from a cloud agent. By July, 95.5% of them did. Simultaneously, we were opening 6.4x as many pull requests as before.
Our security review, meanwhile, hadn't moved. It sat where it has always sat: at the pull request, after the code was written, waiting on a reviewer.
Traditionally, that is exactly where security review has belonged. A developer writes a change and opens a pull request, and a scanner reviews it before it is merged. That placement made sense when a human wrote every line: waiting a few hours for review was cheap next to the time it took to write the change in the first place. But as our code volume increased sixfold, the time it took to create a PR decreased with it. In January we opened a pull request roughly every three hours; by July it was once every thirty minutes.
This was spurred largely by our transition toward a new form of development. Cloud agents, kicked off from Slack or running in cloud VMs, now ship a majority of our code.
We are seeing the same shift happening for our customers. Back in January, only a handful of customer teams had used cloud agents before, with those agents producing just a few pull requests. By July, cloud agents had become a core part of how our customers ship code.
Back on our own repository, the review load increased drastically. Monthly pull requests against our monorepo grew 6.4x between January and July, from 232 to 1,484. Over the same period the number of times we actually had to review something grew 15.3x, from 1,150 review runs to 17,587. In July alone, 17,587 review cycles covered 87,062 changed files.
In the face of this exponentially increasing code volume, PR review became our clearest bottleneck.
So we stopped treating the PR reviewer as the place where insecure code gets caught, and asked a narrower question. What if it were caught the moment it's written, inside the agent's own session, and fixed before a pull request ever existed?
Over the past several months we rearchitected our security review to run earlier, inside the agent's own session, and built the pre-commit scan.
This is what we found.
Key results
Over the past few weeks that we've used pre-commit scanning internally:
- 52% of all detected vulnerabilities were caught before a pull request was opened. After supporting more cloud agent providers and increasing usage, that has run between 69% and 73%.
- Vulnerabilities caught at the commit-stage are fixed in 1.7 minutes at the median, compared to 50 minutes for those caught at the review-stage.
- Pre-commit scanning ran 10,933 scans and blocked 536 commits, a 4.9% block rate. Those 536 are vulnerabilities that never entered the codebase at all, and because only 1 in 20 commits stopped, the gate achieves that without becoming friction developers route around.
Where vulnerabilities surface
Since we've enabled pre-commit scanning, 692 of 1,342 detected vulnerabilities were caught before a pull request was opened. These never became review comments and never entered the merge queue. That matters because every vulnerability that reaches the review-stage costs a reviewer's attention and a context-switch for whoever wrote it; catching it at the commit-stage removes both costs entirely.
As our team leaned more heavily on cloud development across many different providers, the number of vulnerabilities caught before the review-stage has steadily increased: now, roughly seven in every ten detected vulnerabilities are caught and remediated before a pull request exists.
Time to remediation
Using our internal record of every state change on a security finding, we measured the time between when a vulnerability was generated to when it was confirmed fixed, split by the stage at which it was caught.
We see that the time to fix is about 30x faster at p50 and 78x at p75. The mechanism is straightforward. A vulnerability caught at the commit-stage can be remediated by an agent that still has the change in context, mid-task, with nobody waiting on it. A vulnerability caught at the review-stage requires a human or a follow-up agent to context-switch back to old work, costing more time and effort.
Whether the fix holds
Catching vulnerabilities earlier is only useful if it doesn't resurface. We took all 215 unique vulnerabilities pre-commit scanning caught that were subsequently fixed, then looked for evidence if any of them returned.
We found that:
Almost none came back. Of the 215 vulnerabilities remediated at the commit-stage, 3 later resurfaced, meaning a subsequent scan detected the same issue in that code again. The other 98.6% stayed fixed.
What this looks like in practice
The following case studies are real vulnerabilities found when writing production code, caught at the commit-stage, remediated, and confirmed absent from the file at the review-stage.
Vulnerability 1: Credentials handed to an AI agent subprocess
A Cursor cloud agent working on our own agent-harness code spread process.env into a subprocess that then executes inside a target repository. That handed every backend environment variable, including database credentials, webhook secrets, API keys and cloud credentials, to a coding agent operating on untrusted repository content and user-controlled prompts. If that agent can run shell or tool actions, or is steered by prompt injection, those secrets become readable and exfiltratable.
The remediation it handed back: stop spreading process.env, construct a minimal allowlisted environment containing only non-sensitive runtime basics plus the specific model-proxy variables the run needs, and keep execution inside the credential-less sandbox boundary.
Vulnerability 2: CI secrets exposed through a mutable branch trigger
A Cursor cloud agent, working on our post-deployment E2E pipeline, added a temporary branch-scoped push trigger that checked out and executed code from that same mutable branch, while later steps exposed SERVICE_API_KEY, REPO_TOKEN and LLM_API_KEY in the environment. Had it landed on the default branch, anyone able to push to an unprotected branch of that name, or any compromised write collaborator, could have edited the checked-out tests to read those variables and exfiltrated them. It widened secret access from the trusted deploy and E2E path to arbitrary code on a feature branch.
The remediation it handed back: drop the temporary trigger and its job before merge, or if the verification has to stay, gate it behind a protected environment with manual approval on trusted refs, or check out an immutable trusted SHA before injecting any secrets.
Where we are going next
Pre-commit scanning is now running in customer repositories, not just our own, and since mid-July it has already been blocking commits and surfacing vulnerabilities before any of that code reached a pull request. As usage grows, customers can expect most vulnerabilities in their agent-written code to be caught and fixed before a pull request ever exists.
Over the next few months, we are focused on two main improvements to pre-commit scanning:
- Building better context and memory systems. The reasoning output from pre-commit scanning, and customer policy will continue to drive our self-improvement loops around pre-commit scans.
- Improving how pre-commit scans behave as they scale. Pre-commit scanning behaves differently across agent setups, and we only learn where by running it at volume. We are now rolling it out to customers, which means the next round of learning comes from real organizations rather than from our own monorepo.
Closing
Seven in ten of our vulnerabilities now never reach a pull request. The review queue that used to form at the PR is a fraction of what it used to be.
Agents aren't going to slow down — so security feedback needs to be instant at any volume. That's the property we built for, and it's live today for cloud agents on Corridor. Read the docs to get started.