It's time for a new way of doing product security. We're amidst the greatest revolution in the history of software development since its inception. AI coding has forever changed the day-to-day lives of software developers, with code now being written faster than it can be reviewed. The security industry's response to this revolution? To more or less stay the same.
While AI is being used to successfully find swaths of vulnerabilities in products after their release, the same approaches of finding and fixing vulnerabilities after the fact aren't going to cut it. AI is enabling attackers to weaponize and exploit flaws faster than ever, and the ship a product→responsible disclosure→patch release→six-month patching cycle that we've lived with for decades is no longer appropriate in a world where attackers are empowered by AI.
Instead, we believe that vulnerabilities should be prevented at the source. With AI coding agents, for the first time, human fallibility is no longer the fundamental weakness that prevents companies from shipping their customers secure code the first time. However, it's going to take some real work to get there.
Here, we lay out our vision for the future of secure agentic coding: Agentic Coding Security Management (ACSM). Existing tools aren't working, so why stick to old paradigms? ACSM represents a fundamental shift in the creation of secure software; it's how AI coding is made trustworthy and safe in the enterprise. Read on to find out how.
Why now?
Our goal at Corridor is to make AI-assisted software engineering trustworthy and safe. Though the AI coding revolution has just begun and its associated implications remain unpredictable, the countless conversations we've had with companies across all sorts of sectors have surfaced the following initial challenges:
1) Uncontrolled Shadow AI Adoption: When asked which of the dozens of AI coding tools they use, one customer simply replied "Yes." Companies are rapidly adopting AI coding in an attempt to keep up with the pace of innovation. But for the security minded, tool adoption feels more random than strategic and targeted and makes it difficult for security, privacy and compliance teams to keep doing their jobs.
2) AI tools produce vulnerable code: AI coding tools are getting good. But, like any good dev, they are still prone to creating bugs. One academic benchmark focused on LLM generated vulnerabilities has shown that even the best models write both correct and secure code just over half the time.
3) Lack of Company-Specific Security Context: We know coding tools will only keep getting better, but the best security context is unique to your company's needs and your codebase's context. Without this context, these tools struggle to generate code that meets your security, privacy and compliance needs, leaving a significant (and widening) gap between the tool's full capability and its real-world security performance.
Current approaches don't cut it.
From our conversations with customers, it's become increasingly clear that existing approaches won't cut it. Traditional security-testing products, such as static-analysis (or SAST) tools, focus on reviewing code after the fact, creating a massive build up of remediation tasks for engineers. SAST products also have high false positive rates, which have poisoned the well with engineering teams who now look askew of any product security tools. Even if AI helps find vulnerabilities faster, it doesn't address the fundamental problem that scans are happening after code is already written. To keep up, the next generation of code security tools will need to prevent work, not add more.
So, what do we do?
We offer four value propositions to address emerging gaps in AI powered cybersecurity:
1) Proactive Security Flaw Prevention: We proactively inject relevant security context into the AI coding workflow to prevent standard security flaws, such as SQL injections in web apps or use-after-free flaws in C++ code. We provide standard packs of security checks that are relevant for various languages and frameworks, such as the MITRE CWE 25 and OWASP Top 10.
2) Custom Guardrails Creation: We allow companies to create custom security guardrails that match their specific security requirements. This could include how a FinTech company does credit card tokenization, how a healthcare provider does service-to-service authentication, or how a high-speed trading firm uses a secure allocator to prevent entire classes of flaws.
3) Post-Generation Testing: We inject this advice into coding sessions and then test code after it is generated, either during the session or once it is uploaded into a pull request, giving the security team the assurance that code that is both AI and human written is being held to the same security standard. We also provide detailed recommendations and fixes and customers can configure merge protections to prevent flaws from entering their code base.
4) Visibility: We provide visibility into how software engineers are using AI coding tools, both inside of their IDEs and on the command line. We pull their configuration details, prompts, tool use, MCP calls, and code generated into one pane of glass.
So, what do we call this?
While we're finding that our product matches a clear need among customers, it doesn't cleanly fit into any existing security product categories.
Isn't this SAST?
No! While it's true that our product will flag security flaws in code, our goal is to ultimately prevent bugs through proactive security guardrails. We're not in the business of giving companies backlogs of thousands of vulnerabilities. There is still a place for those tools and companies, as our world still has hundreds of billions of lines of old code to fix. That said, we're positioning ourselves for the future of software development – one where more code will be generated in the next few years than has ever been written before, and will require security that moves at the speed of code.
How about "Vibe ___"?
Oh no. No. Just… no.
We really believe in the AI coding revolution. These new tools have the potential to finally unlock the full capabilities of computing for the billions of people around the world who have never had the opportunity to write code or study computer science. It's absolutely amazing, but we think it's important to use the correct terminology. Our CSO, Alex, spoke about this at Vercel's excellent ShipAI conference:
As Alex discussed, there are really big differences between vibe coding and AI-assisted engineering. Vibe coders are describing outcomes while engineers are often describing components. Vibe coders need a much more aggressive level of security-opinionated assistance and are more likely to use a fully-integrated coding/hosting platform. As a company, we hope to address the security needs of both groups, but for now we are focused on assisting professional software engineers who are adding AI coding agents to their workflows while still keeping control of what is already written. These engineers understand security requirements and the responsibilities to their stakeholders — they just need help maintaining AI velocity while also keeping coding agents on track.
Enter Agentic Coding Security Management (ACSM)
To make this change, we did what any reasonable enterprise startup would do in this situation: we invented a new category to dominate, as the overall scope of what we are trying to accomplish does not fit into any existing tool category. So, we hereby invoke the names of the Ancient Gods of the IT Analysts to bring forth a new Category, that of Agentic Coding Security Management. Let's break it down:
- Agentic: We are trying to avoid using the term AI. We think that saying you use AI to do anything is like saying you use "computers" to do something. Yeah, obviously you use AI. We prefer agentic which means a system that is operating autonomously to execute a user's instructions.
- Coding: "Agentic Coding" is probably a better way to capture the space than "AI-assisted software engineering" as we avoid the dreaded AI but also the overloaded term engineering, which applies to many other fields. Coding is specific, direct and doesn't insult the Professional Engineers who spend years studying to build bridges, for example.
- Security: This should be obvious.
- Management: This is key, as we are not just Testing as in SAST but managing the security of these Agentic systems, providing proactive security advice, configurations, and attempting to prevent security mistakes before a human gets involved. This also aligns us with the CSPM segment.
ACSM. The best IT acronyms are pronounceable. Maybe A-SCUM? Axe 'em? Eh, maybe not.
ACSM in Action
What role do the coding agents play in all of this? Through our implementation of the first ACSM tool in the industry, we've worked closely with AI coding agents as partners and collaborators on this journey. Corridor interfaces with coding agents using MCP and hooks.
The Current State of MCP
MCP is the primary mechanism by which Corridor interacts with coding agents. Agents are instructed to invoke the Corridor MCP server whenever they make a plan, or whenever they require additional security context to perform a task.
While MCP has seen incredible success and uptake across a variety of tools, it poses several challenges when implementing a reliable security and compliance product like ours. First off, MCP invocation is non-deterministic; while our IDE plugin will insert rules into the appropriate rule files for each tool, the LLMs behind these tools will only invoke us if they "feel like it." This works surprisingly well, but "surprisingly well" is not what you want to tell an auditor when they ask how well our security control operates.
The second issue is that it is possible for us to get current coding agents to invoke us during the planning stage so that we can inject security context into the conversation, but it is very hard to get these agents to invoke MCP after code is generated. These days, it is possible to ask an AI coding tool to pull a bug from Jira, Sentry or Pylon, to form a plan to address the issue and to create a first pass at a solution in the background while the software engineer works on something totally different. In such a situation, we would like to be able to provide the coding agent with the proper security context, check the code after it's been generated, provide feedback on any vulnerabilities, and then check any fixes. This is impossible with MCP today.
Hooks and the Future
Fortunately, there is a new type of integration that solves this problem for us: Hooks! To better understand how to best support our shared customers, we've been working side-by-side with two of the leading innovators in the extension of agents with hook interfaces, Anthropic and Cursor.
Going forward, we believe that all coding agents should provide hooks that are deterministically executed at the following moments:
- Agent Start: When the agent is first started, it should call this hook and provide it with the initialization context. This context should include the current directory, the associated git repository (if any), the logged-in user, the account type, and the selected model. This is important in allowing an enterprise security team to audit for unauthorized tools and the use of personal accounts that leak data.
- Pre-Code Planning Complete: Most agents perform a lot of planning before they start coding, even if they are not in an explicit plan mode. This is where we currently inject security context with MCP. We want to capture the moment where the agent decides what it's going to do (which may not be fully baked in just a user's prompt), but before it writes any code.
- MCP/Tool Invocation: Every time a tool or MCP server is called, a hook should be invoked. This allows security agents to enforce enterprise policies, if defined, in order to allowlist or blacklist specific MCP servers, or control data that flows into or out of them.
- After Code Generation: Right after code is generated, but before control is returned to the user, this hook can be called with the completed file as well as context and a link to the relevant source control information (such as the working commit number).
More complicated interactions could require deeper integration points, but these basic hooks should allow products such as ours (in the new ACSM category!) to provide security context and a basic level of security scanning.
Looking Forward
We are excited to work closely with our growing community of partners ushering in a new era of software development. With our proposed paradigm shift of ACSM and secure by design AI coding, this era will yield the most secure code yet. We welcome everyone to try out Corridor, to join our mailing list to stay up to date on what we are building, and reach out to join us in this mission!