More than 100 billion tokens. That’s what Team Atlanta spent using a single OpenAI model during DARPA’s Artificial Intelligence Cyber Challenge (AIxCC)—and they didn’t limit themselves to just that model, so the total number of tokens the team used during the two-year competition was well north of that figure.
AIxCC saw some of the best and brightest minds in cybersecurity designing, testing, and improving new AI systems to identify and patch software vulnerabilities in record time. In keeping with the challenge’s goal of advancing the field of cybersecurity, all seven finalist teams open sourced their projects to benefit researchers anywhere.
But it was Taesoo Kim and other members of Team Atlanta who would join Microsoft to turn that research into enterprise-grade product reality.
We sat down with Kim, now a VP of Security Research at Microsoft and leader of the new Microsoft Security FORGE (Frontier Offensive Research & Generative Exploration) Labs, as well as a professor at Georgia Tech, to learn how the research concepts Team Atlanta explored during AIxCC went on to inform the Microsoft Security multi-model agentic scanning harness (codename MDASH), the role that MDASH plays in Microsoft’s broader DevSecOps story, and what comes next.
Let‘s jump right into it. What brought you to Microsoft?
Oh, that’s a great question to start. I joined Microsoft about six months ago. After our team, Team Atlanta, won DARPA‘s AIxCC competition, we thought about which company to join, and Microsoft was one of those companies where we found more opportunity for the future, particularly in the context of finding vulnerabilities, right? Microsoft has a huge asset—not just proprietary software like Windows. They also have a platform like GitHub that‘s literally one of the world‘s biggest code repositories that you can get access to. So enabling any technologies in that context would be a huge career achievement for our team.
Myself and several members of the team joined Microsoft together. Our team consists of many of my PhD students at Georgia Tech, as well as former PhD students and professors there. We all joined as a single team and competed for the DARPA Grand Challenge.
Oh, very cool.
We’re really building a team that enables AI–native vulnerability research at Microsoft. And we’re launching the Microsoft Security FORGE (Frontier Offensive Research & Generative Exploration) Labs so we can focus more, take advantage of frontier AI models, with the goal of completely automating the process as researchers, so that we can ultimately help advance the work. We’re really pushing the boundaries of finding and fixing zero-day vulnerabilities.
Following your PhD in computer science at MIT, you joined Georgia Tech as a professor, and then you branched out to the corporate world with Samsung and now Microsoft. What differences have you come across, working for large corporations compared to working in academia? And are there any similarities that people would find surprising?
So I would say 20, 30 years ago, universities were at the frontier. They did the latest research, and then industry was following. But lately, the gap between this frontier research and what industry can do has become extremely slim. For example, at Samsung, I was developing integrated SIM cards, which is one of the operating system layers in Galaxy devices, so that they can host multiple SIM card operations inside the kernel. We took advantage of the latest research, like instead of using C, we used Rust because, at that time, this was state of the art. We brought those technologies together and applied them in the context of industry.
Similarly, with AI, this gap between academia and industry, it’s almost none. Our industry often has incredible resources, more than you can imagine, right? Data, compute power, engineering, the backend. That actually makes us excited about the opportunity. In just six months, we could design the project that we’d like to pursue, conduct the research, make a prototype, and then finally arrive at a production-ready system. That’s because of all the support that Microsoft can provide. As long as you do great research, you can convince the people inside, your colleagues. And if they see the opportunity for industry, then they’ll pour all these resources into the effort so it’s extremely successful.
In terms of finding the proper problem that motivates you, what we call an intellectually challenging problem, we’re never short of those in industry or in academia. But here, we’re ready to tackle them if necessary. And we don’t worry too much about funding. But the problem is what’s really important.
Let’s switch gears to talk about MDASH. For those who are unfamiliar, what‘s the elevator pitch?
MDASH is what we call Microsoft’s multi-agent, multi-model vulnerability discovery and remediation agent. Given a huge repository, it’s going to find vulnerabilities and propose fixes. But it can take advantage of multiple models.
It’s not bound to a particular model like Mythos, so we take advantage of the latest and greatest models all together. Not only that, we have more opportunity for token efficiency because of the way we constructed the system. We have more opportunity to take advantage of certain models in specific ways.
Right.
We can use the right model for the right job. Not only that, one of the key ideas of MDASH is to have a dynamic validation model, or proving stage. So we’re not just finding the vulnerability in a static way—you can just ask an LLM to find the bugs. We actually validate them through discussions among multiple personas we created. They debate whether it’s a bug or not. And then we also pushed the capability to generate an exploit at the end, so that, when we say there’s bugs, there’s proof associated with it, so that the security auditor and developer can verify the existence of the vulnerability by actually reproducing it.
That’s a great segue to my next question. MDASH is orchestrating these 100+ specialized agents that are challenging each other. Tell us more about the decision to have multiple models in the room, so to speak, working together, debating, and validating the ”what“ and the ”severity“ of what they find. And I’m curious if that was your first approach or if you arrived at it through trial and error.
The design behind the 100+ specialized agents is tightly related to our lessons learned when we’re interacting with agents. When you’re working with Copilot or any type of coding agent, you can say, ”Hey, find bugs.“ And it does find bugs, but it takes a long time. It doesn’t know what type of bugs to look for. It doesn’t know what I want, and it spends a lot of time figuring out what a bug even is, right?
But you can specify what you want in much finer-grained detail and just be very specific about what you want to find. For example, you could say, “Hey, given the past vulnerability A, can you find a similar bug?” That’s the best way to formulate what you want to achieve out of a single agent, but MDASH has more than 100 specialized agents, and it follows a similar philosophy. Each one of the agents has very specific guidelines. “I don’t care about the rest of the bugs, but I really care about this one particular type of vulnerability.”
When you can provide fine-grained controls and scope, it accelerates the performance significantly. But unfortunately, if you combine all of them as a single prompt, it has what we call cognitive load around the work that it has to do.
Right, right.
The model gets distracted, you know? ”Hey, is that really a bug in terms of other bug contexts?“ It’s self-debating all that stuff in a way where it couldn’t find the bug in the end. We like to make sure that the scope that each model is working on is well isolated, but at the same time, the models don’t have tons of cognitive load in their context windows so that they can really focus on and deep dive into it.
That’s really cool. And then what did the process of designing MDASH teach you about decomposition? Are there parts of vulnerability discovery that really benefit from that specialization, or are there parts that still require more of a general reasoning model?
We still have a general reasoning model behind the scenes as well, which is activated all the time. In fact, more than 50% of the total bugs are caught by that non-specialized model, but these are relatively shallow types of vulnerabilities or one of the weakest points in the code repository. With a specialized agent, you’re looking for a very particular vulnerability that otherwise you’re going to miss it.
Our system is designed in such a way that we can assemble all these results together, so you can just unite all these reports and findings in a way that we can push back or push on to the next stage of validation at the end of the scanning. One nice thing about this is that we provide a system where we can assemble everything, where each models’ job is to find as many vulnerabilities as possible, but then we have a nicer system to deduplicate and combine them together in a way that we can enable the rest of the pipeline very seamlessly.
When we’re designing those specializations, we take advantage of the past vulnerabilities and corresponding patches. We study any missing gaps between what we can find with the existing vulnerability as a specialized agent and what type of bugs that we observe in the wild but couldn’t find with the agent. Then we create a research agent so we can extract the specialized agent out of that data. Our system supports this accumulation. You can just add another agent, and our system works fine.
A lot of AI coding and security demos stop at generating a plausible finding, but MDASH is emphasizing proof of exploitability before it gets to a human. What does ”proof“ mean in the system, and how did you design the pipeline to avoid mistaking plausible reasoning for a real vulnerability?
Most static scanning merely complains about, ”Hey, there’s a potential bug in this code snippet.” But unfortunately, it doesn’t necessarily mean that an attacker can reach those locations or that you can formulate the constraint in a way that you can trigger those buggy conditions. So in order to achieve this actual exploitability, we like to solve these two problems: reachability and constraint.
Our proving agent provides an input to the program that resolves the reachability issue and triggers the vulnerability at the end. What I mean by this is that, if there’s a PDF parser render, then we actually create the PDF document in a way that the PDF viewer crashes because of the input that we created, then craft the PDF file that we created as a proof. By crashing your software, by launching the PDF viewer, you can say, ”Hey, this bug exists. I don’t know exactly what it is, but because of the fact that the program crashed, I know that indicates the existence of that vulnerability.
Were there any really challenging or non-obvious architectural decisions that you had to make along the way, or any interesting or difficult tradeoffs that you can talk about?
In the validation phase, we came up with the idea of debate. At that time, it was kind of a novel at the end. It was also based on our lessons as security operators. What I mean by this: When we discover a vulnerability, when we say there’s a bug, we create a bug report and show it to the developer. The very first response from the developer is often, ”Hey, that’s probably not a bug. That‘s the intended behavior because I documented it.“ Even though the program crashed, they documented it, right? This is common behavior. So we created an agent that mimics the behavior of a software developer. It can be defensive.
Right.
So that agent defends against the argument that, according to the design, this is a bug. It might say that the other agent made a mistake and didn’t use it in the right way. But at the same time, another agent takes the offensive perspective, the offensive research perspective. It tries to convince them, “This is still worth fixing because it has a security implication.”
So we created a persona that represents the perspective of the exploit writer and another that represents the perspective of the software developer, and we make sure that they reach a consensus at the end, so that we’re validating certain findings that we have. Either all of the personas that we create reach the consensus, or they feel less severe, less confident about the bug.
So when agents disagree, there’s like a voting mechanism that takes place and it’s sort of majority rules. Is that right?
Yup. Exactly. So at least we can say this is debatable, but we’re not super confident. We can then mark the finding as less confident, so the rest of the pipeline spends more energy to validate those findings after the validation phase.
If you were explaining the architecture to other security researchers, where do traditional program analysis techniques still matter the most? And where do you see LLMs or agentic reasoning really changing the game? Many of the traditional techniques, like analyzing core graph, like CodeKL tools, they understand that some of the data flow in program analysis perspective. Whenever we can take advantage of them, we have to because it’s much faster. In order to resolve the core graph, LLMs consume every single piece of source code and analyze it. It’s extremely expensive, but traditional tools are extremely fast and cheap. So whenever possible, we have to take advantage of them, including core graph generations and data flows and stuff. We provide them as a database and tool in a way that the agent can decide whether we need those analyses separately from the LLM itself.
Are there any classes of bugs or environments that are still really difficult for agentic systems today? And if so, what would need to change for AI systems to handle them well?
There are many types still. For example, side channel is one thing because they have to reason about potential performance characteristics and the codebase’s actual implementation. This is a very difficult area. Another one, I would say spec-driven vulnerability is a logical error, but tightly bound to the certain spec. For example, if you didn’t correctly implement the spec, there’s a potential vulnerability there. The LLM has to reason all these together. They’re not really good at it because the spec itself is extremely formal.
LLMs are designed to be less formal and handle this, I would say, unstructured input, unstructured code as your input, but you have to juggle between this very formal wording and unstructured wording at the same time.
Jumping around a bit, how do you see MDASH fitting into today’s broader Project Perception announcement? Is it one layer of a larger system? How does it relate to the overarching vision for cybersecurity in the agentic AI era here at Microsoft?
MDASH can be plugged in at a very early phase of Project Perception, meaning that we identify potential vulnerabilities in the repository, and then Project Perception can take advantage of this information. So if MDASH says, ”Hey, there’s a potential bug in here because we know those from the code repository,” Project Perception makes sure that it actually exists in the actual environment that they deploy in and understand the whole network topologies. It has multiple sources of information that they’re taking advantage of, and MDASH‘s information is one of the very high-confidence, high-fidelity signals to Project Perception.
And how, if at all, did the insights generated by your work on MDASH help inform the development and training of MAI–Cyber–1-Flash, which is Microsoft’s first cybersecurity specialized model?
We’re closely collaborating with the Microsoft AI team in terms of how to construct the reinforcement learning environment. And also we provided the dataset—this is the past scanning information from internal projects. We discussed how to best utilize a cyber model in a way that can reduce certain inefficiencies in certain bases of MDASH so that we can take advantage of Microsoft‘s internal model as well.
And then I‘m just curious, from a broader perspective, how would you characterize Microsoft’s DevSecOps story and vision, and how do you see your work fitting into that larger puzzle?
MDASH started as an internal project, so we designed everything for our internal developers. We tightly integrated together with the Copilot SDK so that all the full-time employees at Microsoft can launch MDASH as a project on their laptops. It’s great, and the Windows developers realized that when they tried to scan their codebases in MDASH, they significantly increased the pace at which they discovered vulnerabilities with high fidelity. And then they really saw the potential of MDASH and started integrating it in the CI/CD pipeline. We’re also using ADO, Azure Development Ops, inside of most of the projects at Microsoft. So we‘re exhaustively scanning ecosystems and infrastructures across Microsoft by using MDASH. In other words, for certain releases, very frequently, we‘re enabling an MDASH-like scanning tool so that developers can get automated pen testings out of their repository before releasing the software.
What’s next for you? Are there any interesting research questions that you’re exploring at the moment?
We’re focusing on how to automate exploit generations given a finding, which should stop whenever we prove the existence of a vulnerability. But the existence of a vulnerability is different from its exploitation, meaning, what‘s the implication of this bug? Can we actually take control of the program, and what are the impacts after? There‘s a huge difference between, ”Hey, I can trigger this vulnerability” and the program actually crashing. So we’re enabling the last milestone. This is very, very important in the journey of fully automated remediation.
What I mean by this: We discovered the vulnerability, estimated the severity by creating the exploitation, and by using this, we can actually test the generated patch and prevent those exploitations. This is one of the very objective metrics in terms of measuring the validity of the patch that we’re generating. So end-to-end, from discovery all the way down to the exploit generations, and by using it, we like to enable the pipeline for automated remediations as well. This is one of the big journeys that we’re taking.
Another big area is what we call binary support. Certain programs, like many Windows device drivers, don’t have symbols, like even source code. Given that, can you enable MDASH-like systems in those contexts for a broader set of programs, beyond a repository?
Interesting. If a PhD student or a security engineer wanted to push this field forward, what open research problems would you point them toward?
I think one interesting area—I‘ve pitched this idea many times to my students—is that, in the software world, there’s a technique called obfuscation. In order to prevent an attacker from analyzing my software, I obfuscate the binary, obfuscate the source code. Many agentic systems minimize their source code, right? They create a bundle. And AI systems are extremely good at unpacking those and understanding them, but what is the technique to influence the analysis that an LLM can perform?
For example, instead of creating just a minimized version, should I introduce a more complex control flow, or is there a technique that we can play with the symbol name in such a way that the LLM can confuse you about the existence of the source code? I think these are pretty interesting new areas of how to defend my software from an LLM power attacker in terms of software analysis. Is there any technique that can slow down that analysis so that we can enable that packaging before releasing my software with an additional layer of mitigation? Going back to the beginning and being part of the winning team for DARPA‘s AIxCC competition: Tell me a little bit more about what that experience was like.
A DARPA Grand Challenge is one of the biggest competitions in your career—not just me, but for any computer science professor or researcher. DARPA only announces them very occasionally, maybe every 10 years? It’s a huge opportunity.
When they announced the AI Cyber Challenge, that’s my area that I’ve been working on my whole lifetime. So my clear goal was to demonstrate that we are the best. We are very competitive people. And we’re not just doing this competition. We’ve won multiple other competitions, but we thought, “We’re not gonna win this competition.“ People around the world brought their best knowledge and best effort to compete. That was an amazing experience. I never thought of working that hard over two years in my entire career.
That’s pretty amazing. So how did your work in that competition ultimately inspire or inform MDASH?
Every single activity that we‘ve done at Microsoft was influenced by AIxCC, even like at the idea level and lessons level. Because after spending 100 billion tokens during the competition—actually more. So on one OpenAI model alone, we spent more than 100 billion tokens.
Wow.
And we had all these lessons that we had learned. So that was a pretty interesting exercise after the competition. Now we have a huge amount of engineering resources, so let’s tackle this domain of the problem with the insights that we have.
Right.
And that’s why it’s worked very well in practice.
That’s a crazy stat. I know we’ve covered a lot of ground. But if people reading this story take one thing away from it, what do you hope that would be and why?
The world has already changed because of highly intelligent models. Say you’re a software developer or a software company. I think this is a very important moment to think about what an AI power attacker could do to your organization. It’s just scary at first, but if you think through what’s going to happen in the longer-term future, this is the first time where the defender might win this game.
Because before releasing new software, we have a huge chance of finding and eliminating all these possible vulnerabilities ahead of time. I‘m one of the true believers that an MDASH-like system can help us eliminate all of them so that we can win the game. And this is the first time in my career in security where it’s actually possible—or even probable—that the attacker might lose the game in the end.
Learn more about codename MDASH:
Defense at AI speed: Microsoft’s new multi-model agentic security system tops leading industry benchmarkBeyond the benchmark: Advancing security at AI speed
Learn more about Project Perception: