I Pointed an AI Code-Security Tool at My Own Control Plane

TL;DR

• Security is moving into the code-generation loop itself — guardrails fed to the agent as it writes, plus an AI review on every pull request. Corridor is the sharpest version of this I've tested, and it's the pattern, not just the product, that matters.
• To test it honestly I planted a real authorization bug (IDOR) in my own AWS control plane and opened a pull request. It caught it in under two minutes: CWE-639, high severity, the correct fix handed back — for $0.14.
• My existing scanners — Semgrep, Bandit, CodeQL — missed the same bug. They match known patterns, and broken access control is missing logic, not a pattern. Reasoning about the code is the capability Corridor adds and rule-based tools lack.
• The caveats that keep me honest: on the individual tier your code is processed on Corridor's servers with no zero-retention guarantee, and Corridor caught my bug while running inside Claude Code — the same agent whose vendor now ships this capability natively. Corridor runs on the platforms most likely to compete with it.

---

AI coding tools broke the assumption that most security tooling was built on: that a human writes the code, and a scanner checks it later. Veracode tested more than 100 LLMs across 80 coding tasks and found that when a model could choose a secure or insecure implementation, it chose the insecure one 45% of the time — OWASP Top 10 vulnerabilities, introduced silently, at the speed code is now generated. The scan that runs after commit is reviewing a decision that shipped three prompts ago.

Corridor is one answer to that. The thesis behind it: move security into the generation loop, not after it. The company raised a $25M Series A at a $200M valuation led by Felicis, with angels from Anthropic, OpenAI, and Cursor, and founders who led Secure by Design at CISA. They call the category Agentic Coding Security Management. I wanted to know whether the category is real or whether it's a scanner with a coat of paint.

So I imported one of my own repositories — a serverless AWS control plane with a Cognito auth layer, DynamoDB persistence, and a set of Lambda handlers — and tested it the only way that produces an honest answer: I planted a real bug and watched.

What It Actually Does

Corridor works in two places, and the difference between them is the most important thing to understand about the product.

The first is prevention. Corridor runs a server that your coding agent — Claude Code, Cursor, Codex — calls before it writes code. The agent sends its plan, Corridor returns security guidance scoped to your codebase, and the agent writes code that already accounts for it. Your model still writes the code. Corridor supplies the security context your model would otherwise lack. It does not replace your coding model; it informs it.

The second is detection. When you open a pull request, Corridor receives it, reviews the change on its own servers with its own models, and posts findings back on the pull request. This half runs entirely on Corridor's infrastructure.

Those two places are the whole product. Prevention improves the code your agent writes. Detection reviews the code after it is written and flags what the guidance missed.

YOUR MACHINE (your model writes)          CORRIDOR BACKEND (their model reviews)
─────────────────────────────────        ──────────────────────────────────────
  coding agent
  (Claude Code / Cursor / Codex)
        │
        │  1. plan  ──────────────►  MCP: analyzePlan
        │                                  │
        │  ◄──────────────────────  guardrail context
        │      2. (scoped to your codebase)
        ▼
  agent writes safer code
        │
        │  3. git push + open PR
        ▼
  GitHub  ───── webhook ──────────►  4. review diff (hosted model)
        │                                  │
        │  ◄───── finding on PR ─────  IDOR · CWE-639 · high
                                           (posted back to the PR)

  PREVENTION: your model generates,        DETECTION: their model reviews,
  Corridor supplies the rules              entirely on their infrastructure

The left column is your machine, where your model writes the code. The right column is Corridor's infrastructure, where its model reviews it. Steps 1 and 2 happen before the code exists; steps 3 and 4 happen after you open the pull request. The dividing line also answers the question that matters most for sensitive code: where your code goes. Everything on the right side leaves your machine.

It Read the Codebase Before It Judged It

Setup is a GitHub connection and a repo pick. Corridor scanned the repository and produced ten security guardrails in a few minutes. The guardrails were specific to my code, citing the actual files and functions in each one.

Two examples show the depth. On authentication, Corridor identified that every route enforced the same auth check and that the health-check endpoint was the one intentional exception. On privilege escalation, it traced how the system issues tokens and flagged the exact component that decides what permissions a token carries.

The more telling result was the guardrails Corridor chose not to raise. It examined the code for SQL injection and concluded the bug cannot occur here, because the database layer does not build queries from strings. It reached the same conclusion for cross-site scripting and CSRF: the application returns JSON, has no web frontend, and uses bearer tokens, so those attack classes do not apply. Corridor explained each decision instead of listing the vulnerability as a warning to dismiss.

This is the difference that matters. A rule-based scanner sees a database call and raises SQL injection. Corridor read how the database is actually used and ruled the class of bug out. A tool that reasons about the code earns attention. A tool that fires on every pattern gets muted.

Planting a Real Bug

Clean-repo guardrails prove little. The real test is whether Corridor catches a bug that a developer, or a hurried agent, would actually introduce.

My usage API already handled this correctly. One route returned a team's usage, and it verified that the caller was allowed to read that team's data before returning anything.

if not principal.is_admin and principal.team != team:
    raise errors.ForbiddenError("Cannot read usage for another team")

I broke it on purpose. I added a second route that took the team name straight from the URL and returned that team's usage without the ownership check.

if path.startswith("/usage/") and method == "GET":
    team_id = path[len("/usage/"):].strip("/")
    if team_id:
        return _handle_usage(team_id, history=0, models=False)

This is a textbook Insecure Direct Object Reference (IDOR): the route checks that the caller is logged in but never checks that they own the data they asked for. Any team can read any other team's spend by changing the team name in the URL. It is the kind of bug that appears when someone adds a convenient shortcut and forgets that the original route earned its safety with a check the shortcut skipped. I committed it, pushed the branch, and opened a pull request.

What Came Back

The review posted in under two minutes, as an inline comment on the exact lines:

Because this endpoint only requires INVOKE_SCOPE, a team client can request /usage/other-team-id and retrieve another team's usage data. This is an IDOR / cross-tenant authorization bypass.

The remediation it proposed was correct: check that the caller owns the team before returning data, and allow reading another team's data only for an admin. This is the same protection the original route already had. Corridor reconstructed my own security pattern from the codebase and handed it back as the fix.

The finding came with everything needed to act on it: the vulnerability class (CWE-639), a high severity rating, the exact code, and the file and line. The entire review cost $0.14.

Was the Finding Real?

Yes. It is a genuine cross-tenant data exposure, classified correctly, with the right fix. My existing scanners ran on the same pull request — Semgrep, Bandit, and CodeQL — and none of them flagged it. They look for known bad patterns, and this bug is not a pattern. It is missing logic. Judging whether an authorization check is present requires understanding what the code is supposed to do, and that is the capability Corridor adds.

Two caveats keep this honest.

Corridor marked the finding as not proven reachable. It identified the vulnerable code but did not claim a working exploit path, because reachability depends on deployment details it cannot see. The finding is a strong signal, and confirming exploitability is still the reader's job.

The finding also did not appear in the default results when I queried Corridor's data through its API. It existed and I could retrieve it directly, but the default view shows only the main branch, and my bug lived on a feature branch. This is a configurable default rather than a failure, though it is the kind of default that hides branch findings from anyone who does not know to change it.

What's Missing

Corridor caught the bug. The open question is what happens to your code to make that possible.

On the individual tier, both halves of Corridor send your code off your machine: the guidance step sends your plan and surrounding context to Corridor's servers, and the review step sends the full pull request diff. Zero data retention is available only on the enterprise tier. The finding record confirmed that Corridor processed my diff on its own servers with a hosted model. For a personal repository, that is a fair trade. For code under a real data-classification obligation, a security tool that retains your source is itself a risk to weigh, and removing that risk requires the enterprise tier and a sales conversation.

The larger question is convergence. In February 2026 Anthropic shipped Claude Code Security, and its own description matches Corridor's pitch closely: rule-based static analysis "catches common issues but often misses more complex vulnerabilities, like flaws in business logic or broken access control." Broken access control is the exact bug Corridor caught for me, and it caught it while running inside Claude Code. Corridor's advantage is that it works across every agent, the same way whether you use Cursor, Codex, or Claude Code. Its risk is that the agent vendors are building the same capability into their own products, and Corridor depends on those products to run. The company is building on top of the platforms most likely to compete with it.

The Verdict

The category is real, and Corridor is a credible version of it. I have run enough security scanners to recognize the difference between one that matches patterns and one that reasons about code, and the IDOR catch is the second kind. It read my code, understood the missing check, and handed back the fix my own scanners could not produce. Security that runs inside the generation loop is the right answer to code that ships faster than anyone can review it.

One test does not settle the question. I ran the prevention path and a single pull request. The number that decides whether a tool like this survives daily use is the false-positive rate across dozens of pull requests over months, and I have not measured that yet. Corridor earned the next test.