Let’s talk about fixing bugs. My second favorite activity after creating them.

How do I know the bug is fixed? Well, I’ve been taught by wiser and more experienced people than me (way back when), that if you want to make sure the bug never shows its face again – write an automated test for it.

Ok, I admit that there were times I didn’t write a test. Some fixes are so trivial, that sometimes a test is a luxury.

But even then, I was working on a hidden assumption. Just like in Fallout, code never changes. Until it does. But between those times it never changes.

I fix the bug. From this point until it actually changes by a human, or a bot or someone in-between – that code will compile, or transpile, or whatever we call “runs” the same way. A statement will execute, a condition evaluated, an exception caught – every time in the same way.

And now we come to modern programming languages: Prompts. Agents, prompts, workflows – they don’t run the same way every time. What they do is run their interpretation of the request. If they run tools – they run the deterministic parts. If they run sub-agents, they run interpretations based on other interpretations.

Interpretations work mostly the same way, until they don’t. When I was teaching my agent to develop in TDD, I had a couple of requests. One of them was to not create code without a test.

Which I thought was a very normal request from an agent. In fact, when I started out by telling it – we’re working in TDD – I assumed it knows what TDD is. Ha.

Always remember that what LLMs know is exactly what most of the population knows. And usually the “don’t create any code without a test” falls through the cracks.

So I made it official: One of the agent rules was exactly that. This was a legitimate bug fix. At least I thought so.

But it really was a suggestion. Which the agent considered, and depending on its mood, sometimes did, and sometimes didn’t.

I won’t go into the full solution (still in progress, if you want me to elaborate, comment), but part of it was to run a targeted coverage tool – a deterministic one, check it and stop the process if it found extra code. The TDD sequence looks like this:

Per step:
1. Write test(s).
2. `node scripts/tdd.mjs red <test-file>` — all newly added tests must fail. Pre-existing passing tests in the same file are allowed to remain passing.
3. Implement minimum to pass.
4. `node scripts/tdd.mjs targeted <test-file>` — targeted coverage + pass check.
5. `node scripts/tdd.mjs lint` — ESLint.
6. `node scripts/tdd.mjs full` — full suite + coverage.
7. Script says STOP. Human reviews.
8. Human runs `node scripts/tdd.mjs commit "message"`.
9. Human confirms next step. AI runs `/clear`.

But each step here is the suggestion. The real enforcement is done in the tdd.mjs code. Real code.

But this is just an example. The real problem is that more and more “code” is not programmed. It’s interpreted. That means that bugs are a lot more flaky to catch, but also are not permanently fixable.

And don’t get me started on companies switching model capabilities every other Tuesday. In the past, updating versions was a whole ceremony because we were worried something would break.

Now LLM providers do it for us without us knowing.
We can live with that. We should make sure we know.

And remember – bug fixes in prompts are not real bug fixes. They are more like wishes. Which may or may not come true.

Testing features that run on interpretation – and building the checks that don’t – is one of the four things we go through in the Masterclass.

The API Testing Masterclass: The Tactician
Four weeks, live, hands-on. Test data, debugging, fighting flakiness, and testing AI-based features.
Starts October 5. Twenty seats.
Early bird $399 through Jul-31, then $599.
Enroll here

The API Testing Masterclass: The Strategist – API quality strategy at the organizational level.
Join the waitlist

Your agents can now discover and load Agent Skills directly from a Model Context Protocol (MCP) server. Instead of shipping every skill inside your application or copying skill folders into each deployment, you point an agent at an MCP server and it pulls the skills it needs on demand. A central team can publish skills once, and every agent across your organization picks them up without a redeploy. This is available today in .NET through the Microsoft.Agents.AI.Mcp package.

For makers, this removes a distribution problem: you author a skill in one place and serve it to many agents. For enterprise leaders, it means domain expertise – expense policies, compliance workflows, data-analysis playbooks – can be governed centrally, versioned on a server, and rolled out consistently without touching application code.

What MCP-based skills are

An Agent Skill is a portable package of instructions, resources, and scripts that gives an agent specialized capability using a progressive-disclosure pattern: the agent sees a short advertisement of each skill up front, then loads the full instructions and resources only when a task matches.

MCP-based skills apply that same pattern, but the skills live on an MCP server rather than on local disk or in code. The server advertises its skills through a discovery document at skill://index.json, and the framework retrieves the referenced skill content through the authenticated MCP connection.

The .NET implementation supports two ways a server can distribute a skill:

• skill-md – The server exposes the skill’s SKILL.md and its sibling resources as MCP resources. The framework fetches them on demand, file by file, as the agent loads the skill and reads its resources.
• archive – The skill is packaged as a single archive (ZIP, TAR, or gzip-compressed TAR). The framework downloads it, unpacks it locally under a controlled directory, and serves the extracted files.

Both types are consumed through the same builder API, so your agent code does not change based on how a skill is packaged.

Why this matters

Author once, serve everywhere. A platform or domain team publishes skills to an MCP server. Any agent that connects picks them up – no per-agent packaging, no copying folders, no rebuild.

Update without redeploying agents. When the server’s skill content changes, connected agents get the new version the next time they discover skills. Policies and playbooks evolve on the server, not in every downstream application.

Consistency across many agents. The same skill, from the same source, reaches every agent. That is the difference between “each team maintains its own copy of the expense policy” and “there is one expense policy, and everyone uses it.”

Guardrails for remote content. Skills that arrive over MCP keep the same progressive-disclosure discipline as local skills, with explicit controls for archive extraction and script execution (covered below).

Getting started

MCP-based skills require the Microsoft.Agents.AI.Mcp NuGet package:

dotnet add package Microsoft.Agents.AI.Mcp --prerelease

Connect an MCP client to the server that hosts your skills, then use the UseMcpSkills extension method on AgentSkillsProviderBuilder to add it as a source:

using Microsoft.Agents.AI;
using ModelContextProtocol.Client;

// Connect to the MCP server that hosts the skills
await using McpClient client = await McpClient.CreateAsync(
    new StdioClientTransport(new()
    {
        Name = "skills-server",
        Command = "dotnet",
        Arguments = [skillsServerPath, "--server"],
    }));

// Build a skills provider that discovers skills over MCP
var skillsProvider = new AgentSkillsProviderBuilder()
    .UseMcpSkills(client)
    .Build();

Add the provider to an agent through its context providers so the framework advertises the server’s skills to the agent, and the agent can load and read them as it would local skills:

using Azure.AI.OpenAI;
using Azure.Identity;
using OpenAI.Responses;

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
    .GetResponsesClient()
    .AsAIAgent(new ChatClientAgentOptions
    {
        Name = "SkillsAgent",
        ChatOptions = new()
        {
            Instructions = "You are a helpful assistant. Use available skills to answer the user.",
        },
        AIContextProviders = [skillsProvider],
    },
    model: deploymentName);

AgentResponse response = await agent.RunAsync(
    "Summarize our expense reimbursement limits for international travel.");
Console.WriteLine(response.Text);

The agent sees the skill advertised in its system prompt and, when the request matches, loads the relevant content. For a skill-md skill, the framework fetches SKILL.md from the server when the agent loads the skill. For an archive skill, it uses the skill archive downloaded from the server and extracted locally. In both cases, referenced resources are read as needed.

Use case: a central skills server for many agents

Suppose a platform team owns the company’s operational knowledge – expense policy, incident-response runbooks, and a data-classification guide. They host these as skill-md skills on an MCP server. A finance assistant, an on-call helper bot, and a data-governance agent all connect to that same server with the same UseMcpSkills(client) call shown above.

None of the three agents bundles any of these skills. When the platform team updates the expense policy on the server, all three agents reflect the change on their next discovery – no coordinated release across teams.

Because UseMcpSkills adds a source to the builder, you can compose it with local skills in the same provider. An agent can carry its own file-based skills and also pull shared ones from the server:

var skillsProvider = new AgentSkillsProviderBuilder()
    .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "local-skills")) // team-owned, on disk
    .UseMcpSkills(client)                                                 // shared, from the server
    .Build();

This includes Microsoft Foundry Toolbox – if your organization manages skills through the Foundry Skills API and attaches them to a toolbox, UseMcpSkills connects to that toolbox’s MCP endpoint the same way it connects to any other MCP server. You author and version skills in Foundry, and your .NET agents discover them over MCP without additional integration work.

Use case: distributing a skill as an archive, safely

Some skills bundle several reference files – templates, lookup tables, checklists. Serving them as a single archive entry lets the server ship the whole package in one download. Because archive extraction writes remote content to local disk, it needs guardrails: an archive can be larger than expected, expand dramatically when decompressed, or contain more files than you intend to accept. Without bounds, a malformed or hostile archive could exhaust disk, memory, or CPU on the machine running the agent.

For that reason, AgentMcpSkillsSourceOptions exposes a set of options that let you bound exactly how much an archive is allowed to consume before it is extracted and served:

using Microsoft.Agents.AI;

var skillsProvider = new AgentSkillsProviderBuilder()
    .UseMcpSkills(client, new AgentMcpSkillsSourceOptions
    {
        ArchiveSkillsDirectory = Path.Combine(AppContext.BaseDirectory, "extracted-skills"),
        ArchiveMaxFileCount = 50,
        ArchiveMaxSizeBytes = 2 * 1024 * 1024,             // cap the download size
        ArchiveMaxUncompressedSizeBytes = 4 * 1024 * 1024, // cap the total unpacked size
    })
    .Build();

Each option guards against a specific class of abuse:

• ArchiveMaxSizeBytes caps the size of the archive that is downloaded, guarding against oversized payloads.
• ArchiveMaxUncompressedSizeBytes caps the total unpacked size, guarding against decompression-bomb archives that are tiny on the wire but expand to gigabytes on disk.
• ArchiveMaxFileCount caps how many files a single archive may contain, guarding against excessive-file-count archives.

The framework downloads the archive, validates it against these limits, unpacks it under ArchiveSkillsDirectory, and serves the extracted SKILL.md and resources. An archive that exceeds any of these bounds is skipped, so an untrusted server cannot use skill distribution as a way to overwhelm the host.

There is one more trust boundary around remote archive content:

The rest of the skills governance model still applies. Skill tools such as load_skill, read_skill_resource, and run_skill_script require approval by default, giving you a human-in-the-loop checkpoint before an agent acts.

Why this matters, restated

MCP-based skills turn Agent Skills into something you distribute rather than something you embed. Author a skill once, host it on an MCP server, and let every agent discover it on demand – updated centrally, governed centrally, and consumed the same way whether it arrives as skill-md resources or as a packaged archive. For teams building many agents against shared domain knowledge, that is the difference between maintaining copies and maintaining a source.

To go deeper:

• MCP-based skills documentation
• MCP-based skills sample
• Skills in Microsoft Foundry
• Agent Skills for .NET Is Now Released
• Agent Skills in .NET: three ways to author, one provider to run them

The post Discover Agent Skills from MCP servers in .NET appeared first on Microsoft Agent Framework.

If you’re feeling overwhelmed by AI right now, you’re not alone.

Every day it seems there is a new tool, new MCP, new model, new skill, new workflow, new feature, new social post that is some form of “Hey look! I have completely figured out AI with this one weird prompt.”

I…don’t believe you.

I work with AI every single day, and what I’m finding is that less is way more. It’s not about what I install or configure or trick the agent into doing that makes any real difference. That stuff is interesting, but at the end of the day it feels like gimmicks.

I see the biggest gains in my productivity from how I use the harness and how well I understand it.

So in this post, I’m sharing you a simple workflow that you can use to drastically improve your effectiveness with AI just by using existing features of GitHub Copilot. No weird prompts. No skill everyone else seems to know about. Just the harness. The harness is all you need—mostly.

1. Pick a tool, any tool

This is an obvious one, right? Pick a tool! It’s so easy!

But even within the GitHub Copilot family, there are a lot of options. These include the CLI, the new GitHub Copilot app, VS Code, Visual Studio, and JetBrains, just to name a few.

The good news is that these experiences are increasingly being centralized on the same harness. The details can differ by tool, but the core workflow is consistent. Learn the harness once, use it everywhere.

That said, I do believe that learning the harness is key, and the best way to learn it is to be as close to it as possible. So if you are just starting out, I’d recommend beginning with the GitHub Copilot CLI. It’s a terminal interface, which means it’s just text. There isn’t much UI to learn. You enter a prompt. The agent does things. But the interaction is more direct, immediate, and, frankly, very satisfying.

For this demonstration, I’ll be using the new GitHub Copilot app. But the harness that app uses is the exact same thing you’ll be using if you are using the GitHub Copilot CLI, Visual Studio Code and many other places you can find GitHub Copilot.

2. Turn on YOLO mode

YOLO mode is also known as “Allow All.” This lets the agent execute any command without asking permission. This can vary depending on the tool you are using, but for most it is simply an /allow-all command in the chat. Otherwise, the agent is going to stop and wait for your approval every single time it needs to do some work.

Agents need autonomy for you to see an increase in productivity. If you have to approve everything the agent does, you might as well just do it yourself. Besides, that’s a miserable user experience. Nobody wants to be relegated to sitting at a desk pressing the “Approve” button all day. And pressing “Approve” over and over just trains you not to read what you are being asked to approve, which defeats the purpose.

You want to be safe with agents, though. Bad things happen to good people. When using YOLO mode, you don’t want to run the agent on your local machine. This is especially true when you are using them at work—data is private on your organization’s systems, and mistakes can be costly.

Fortunately there are a bunch of options for running agents in sandboxes. An easy one to get started with is GitHub Codespaces or development containers.

3. Start with a prototype

One of the most magical things about AI is that you can easily prototype anything and everything up front. Historically, this was not the case. Prototyping was a full phase of a project, and were often a luxury. Now, you can make one with a prompt.

Let’s look at a few examples.

Let’s say we want to build a date picker web component. That seems straighforward, but it’s actually quite complex. Think of all the different things you might want to do with it.

• How do you navigate within the component?
• What does the selected date look like?
• What does a selected range look like?
• How does the user navigate between days, months, and years?

Start with a simple prototype and get several variations. I usually start with something like this:

Give me 20 mocks for a date picker web component. Put them all in an HTML file so I can compare.

In this case, the AI generated a bunch of different layouts, but one of them is a mock where it starts with the year view. That’s interesting. I would like my date picker to enable the user to zoom out to the year, then into the month, and finally to the day. These are the kinds of things you don’t consider until you see them.

As humans, we process sensory-rich models like images, shapes, and tangible layouts much faster than dense text. Creating low-effort prototypes early on helps make complex concepts immediately intuitive.

And this applies to non-visual tasks as well.

For instance, if I want to add a new API endpoint, I’ll still create a visual prototype to understand the requirements and constraints before diving into the implementation.

Create a visual mockup of the API for this project. Add five options for how we could handle a new API endpoint that allows the user to download their analytics data.

Since the GitHub Copilot app supports Mermaid diagrams, the agent renders this as Markdown, mapping out five different ways we could implement this API endpoint.

When working with agents, it’s easy to forget that everything is nuanced. Prototyping helps uncover the nuances up front, so you avoid spending valuable time and tokens on rework.

I recommend using a medium-sized model, such as GPT 5.6 Terra or Claude Sonnet, on medium reasoning for most work. I also recommend you stick with whatever model you choose here for the duration of this particular feature, bug, or enhancement. Prompt caching will save you tokens. As long as you don’t switch to a different model or reasoning level, your previous chats remain cached with the model, giving you a discount on future requests.

4. Plan methodically

Now that you know what you actually want versus what you initially thought you wanted, it’s time to plan out the implementation.

Switch to plan mode in GitHub Copilot without starting a new session.

“/plan Build a date picker web component. I want the user to be able to zoom in and out of years, months, and days.”

That’s a pretty vague prompt, and you’ll likely have more context for the model than I do here, but this is just a demonstration. If you don’t have more context, it’s OK. That’s exactly what this step is for.

In theory, you can get a model to one-shot anything if you compose the perfect prompt with the perfect context in the perfect order. In theory.

But none of us can do that. Planning helps you get closer to that ideal, though, by asking all of the questions that you would need to answer yourself along the way if you were to build this out by hand:

• Can the start and end date be the same?
• Are partial selections valid?
• Should users be able to clear the date?
• Should “today” always be a visible option?
• Is manual entry allowed?
• What format is the date stored in?
• Should pasting in dates be allowed?

The list goes on and on. You cannot possibly think of all of these edge cases, but the model can help you identify many of them.

You can make plan mode even more aggressive in the sheer number of questions and edge cases it asks about by installing the “grill-me” skill from Matt Pocock.

/plan /grill-me Build a date picker web component. I want the user to be able to zoom in and out of years, months, and days.

This planning step is critical. The point is not for you to just accept every suggestion from the AI. If you do that, you are negating the value of this planning process. The point is for you to deeply engage with the problem and guide the model. This is where your expertise comes into play.

You can also ask the model questions back. In the screenshot below, it asks me about “non-contiguous dates.” I’m pretty sure I know what the model means here, but I’m going to ask for clarification so we’re on the same page.

The planning process will keep going even if you interrupt to ask clarifying questions, etc.

5. Implement with Autopilot

Once the plan is finished, GitHub Copilot will likely prompt you to switch to Autopilot and start implementing the plan.

Autopilot is a built-in loop. It forces the model to continue working by ensuring that it has actually done what it said it would do—which in this case is completing every item in the plan.

GitHub Copilot will automatically act as an orchestrator during this phase. If it needs to read files in the codebase, it will use the “Explore” subagent with a small model. If it deems an action relatively complex, it will likely choose the “General Purpose” subagent with a larger model. While you can get fine-grained control over orchestration in GitHub Copilot with custom agents and instructions, you don’t need to do anything special to get the advantages of subagents and multimodel workflows. This works out of the box, even if you did not know that any of these things existed.

6. Human review and iteration

This is where you get your dopamine hit. You get to see what the AI has created.

But it’s likely that you won’t get exactly what you wanted. That’s normal and expected. The model cannot read your mind, and it is error-prone. Iterate with the model until you get what you actually want. Whether that’s just code or an improved UI, this is the part where your taste will decide the quality of the final product.

For instance, here’s the date picker that GitHub Copilot gave me.

Already I can see it has some issues:

• Animations are inconsistent
• Text is unreadable when hovering over a selected date because of color contrast
• It doesn’t need to say “12 YEARS” at the top.
• When I click “Today”, it doesn’t take me to the day if I’m in the month or year view.

Also, I don’t love the design. It looks a little too much like it was created by AI—because it was!

So here we’re just in follow-up mode. I’m going to use a CSS framework I created called Postrboard. I add it as a skill that just points to the CSS and tells the agent how to use it. You can feel free to install it yourself if you’d like to use it, or you can pick any other CSS framework out there that you like. Giving the model some design guidance is quite helpful, and often a CSS framework is all you need.

ok - we don't need a landing page here - just the component, output and settings panel in a minimal setting. Use the /postboard skill for the design and colors.

For the date picker, when I click on the day, it tries to zoom in, but can’t because there is nothing to zoom to. There should be no zoom there.

It doesn’t need to say “Zoom Out” at the top

When I mouse over a month or year that contains the selected day, I cannot read the hover text.

When I click “Today” it should take me to that day view, even if I’m on the month or the year.

The months don’t need numbers under them and they don’t need to be in boxes

Same goes for years. And it doesn’t need to say “12 years” at the top.”

Notice how conversational this is. Don’t overthink it. When you’re fixing a bunch of small things like this, just give it to the model. If you’ve got the context, you’ve got the prompt.

The most important thing is not to settle for AI output that is “good enough.” Insist on quality. Be ruthless about it. That part is still your responsibility, and knowing what a quality result is from something that isn’t is the value that you bring. No AI will ever replace your human touch and creativity.

Here’s what my final date picker looks like. Scroll to the end of this post to see it in action.

7. Rubber duck the result

After you’ve iterated and are happy with what you’ve created, it’s time to do a final review.

Request a Rubber Duck review from GitHub Copilot. You can do this just by asking for it:

Perform a rubber duck review on this date picker component implementation

In a Rubber Duck review, GitHub Copilot will request a review from a model of a different AI family. For instance, since I was using GPT 5.6 Terra, it requested a review from Sonnet. Different models were trained on different data, so they have different blind spots. A Rubber Duck review helps identify potential issues that might be missed by a single model.

Note that you can use this at any point in this workflow. You can rubber duck prototypes. You can rubber duck plans. It all just depends on if you want a second AI review on something.

And if you want to take this a step further, you can combine rubber duck with Autopilot to get the models to work together in a loop to improve the final result.

“/autopilot rubber duck this date picker implementation. When you have the result, review it carefully and make any necessary adjustments. Repeat the rubber duck review until both you and the reviewing model agree that the only items that remain have diminishing returns.”

After this step, you will have an even more refined result than before and will have likely identified many extra edge cases. This step does cost more tokens, but you are really battle-hardening the code. Think of it as an investment in your future self who won’t have to deal with these issues because you caught them now.

8. Profit

At this point, you’re ready to stage and commit, or move on to the next feature you want to add along with this pull request.

I’d recommend starting a new chat session for anything you do next that doesn’t have to do with this date picker. You can think of chat sessions as being topical; if you start to diverge too much from the main topic, it’s probably time for a new session.

Here’s the final result from my workflow building the date picker for this post.

I realize that this is a bit of a contrived example, but can we all just pause for a moment and marvel at what we’re able to pull off with AI now? Building a date picker used to be one of the hardest things you could try to do. Just ask any of the heroes out there who have built them.

Things don’t have to be complicated

This simple workflow will be enough for most people. The simplicity also helps you multitask. It’s easier to reason about what agent is in what state and what you were doing last when you keep things simple. Your context window is limited too.

There is so much happening in the AI space right now. There is no upper limit on the things that you can build and experiment with. You can add MCP servers, skills, instructions, and custom agents. You can set up workflows and loops, create agents that prompt agents, and stand up entire virtual dev teams.

But keep in mind that nobody really knows what they are doing right now. We’re all figuring this out as we go. A lot of what is today’s magical incantation for AI will be tomorrow’s anti-pattern.

Just focus on getting a repeatable, high-quality result in the simplest way that you can. Learn the harness and you’ll be just fine.

The post The harness is all you need (mostly) appeared first on The GitHub Blog.

Most AI safety testing still happens inside the walls of individual organizations. That has resulted in a fundamental disconnect: many of the highest-risk failure modes in modern AI systems require deep domain expertise, multilingual context, or regional understanding that no single internal team can fully replicate on its own. 

As frontier models become more capable, the attack surface expands with them. AI red teaming is no longer just about prompt injection or content safety edge cases. It increasingly involves security operations, misuse scenarios, multilingual harms, alignment failures, and domain-specific abuse patterns that can vary significantly across geographies and languages. 

Microsoft’s AI Red Team has observed that meaningful testing of advanced AI systems- and models similarly requires broader participation from researchers and practitioners who operate outside traditional corporate security boundaries. To address that gap, today we are announcing the External Red Team Alliance (EXTRA), a formalized global extension of Microsoft’s AI Red Team designed to support and encourage external expertise to advance AI safety and security testing.  We are proud to share we are funding the development of new AI safety assessments on six continents through unrestricted gifts. 

Building a global alliance

EXTRA is a two-part initiative focused on expanding AI safety research and strengthening external collaboration. 

The first component supports a global academic network focused on advancing AI safety and security research. Microsoft’s AI Red Team has provided unrestricted gifts to 18 university labs spanning six continents. The goal is intentionally broad: support researchers who are already investigating difficult, unresolved questions in AI safety and help them continue pushing that work forward independently. 

Some of the supporting institutions include: 

• Carnegie Mellon University Security and Privacy Institute (CyLab), United States 

• Georgetown University – Georgetown Security Lab (SecLab), United States 

• Harvard University Berkman Klein Center for Internet & Society (BKC), United States 

• Howard University Research Institute for Tactical Autonomy (RITA), United States 

• Indian Institute of Technology Madras – Centre for Responsible AI (CeRAI), India 

• Korea Advanced Institute of Science & Technology – KAIST Web Security & Privacy (WSP) Lab, Korea 

• New York University – NYU Alignment Research Group (ARG), United States 

• Northeastern University Network and Distributed Systems Security (NDS2) Lab, United States 

• University College London – UCL Information Security Research Group (UCL ISec), United Kingdom 

• University of Cagliari Pattern Recognition and Applications (PRA) Lab, Italy 

• University of California – Berkeley Risk and Security Lab; Center for Responsible, Decentralized Intelligence (CRDI), United States 

• University of Melbourne Artificial Intelligence Assurance Lab, Australia 

• University of Pretoria Data Science for Social Impact (DSFSI) Research Group, South Africa 

• University of São Paulo Center for Artificial Intelligence (C4AI), Brazil 

• University of Toronto CleverHans Lab, Canada 

• University of Washington Department of Human Centered Design & Engineering (HCDE), United States 

The second component of EXTRA focuses on operational collaboration. Microsoft is building a distributed network of specialists who can participate directly in red teaming highly specialized areas where deeper expertise is required. That includes researchers, practitioners, and regional experts who understand specific attack classes, languages, cultural contexts, or technical domains that internal teams may not fully cover alone. 

Beyond expanding participation, EXTRA is also intended to help advance the science of AI safety evaluation. By bringing together academic researchers, security practitioners, and domain experts from around the world, the initiative aims to contribute to the development of more robust methodologies and testing practices for increasingly capable AI systems. Today’s cybersecurity ecosystem depends on coordinated vulnerability research, responsible disclosure programs, academic inquiry, and global communities of independent security researchers who routinely identify risks that vendors alone would not find. Likewise, advancing AI safety will benefit from ongoing contributions from experts across institutions, disciplines, and geographies to identify emerging threats, strengthen safeguards, and improve evaluation practices. 

What the research focuses on

The research areas funded through EXTRA reflect several of the emerging areas Microsoft’s AI Red Team continues to encounter when evaluating advanced AI systems. 

Some universities are examining the cybersecurity implications of AI systems themselves — including how models can be attacked, manipulated, or abused in operational environments. Other labs are exploring the inverse problem: how AI systems can assist defenders and improve cyber operations. 

The structure of the program is intentional. The funding is unrestricted because the objective is not to direct research outcomes toward product requirements or predefined deliverables. The goal is to strengthen independent safety research capacity globally and create stronger long-term collaboration between academia and operational AI security teams. 

Why this matters

“Managing frontier AI risk requires more than internal safeguards. It requires continuous engagement with experts who understand how these systems behave across different technical, linguistic, and cultural contexts. EXTRA reflects Microsoft’s broader Frontier Governance Framework approach: combining rigorous internal governance with external support and collaboration to better identify, assess, and mitigate emerging risks as AI capabilities advance. By supporting independent research and building stronger connections with universities and specialists around the world, we are helping strengthen the broader ecosystem needed for trustworthy and secure AI development,” says Natasha Crampton, Chief Responsible AI Officer, Microsoft 

Governments too are increasingly focused on understanding the capabilities and security implications of frontier AI systems to strengthen resilience. But just as coordinated international research helped unlock the benefits of previous technological revolutions, diverse expertise from researchers and practitioners around the world is essential to identify emerging threats, improve defenses, and build greater confidence in AI systems.   

“Frontier AI is already shaping the future of both cybersecurity and national security. Understanding how these systems can be misused, and identifying risks before they become real-world threats, requires expertise that spans institutions, disciplines, and borders.” says Mike Yeh, VP & Deputy General Counsel, Customer Security and Trust, Microsoft 

AI red teaming is becoming more interdisciplinary, multilingual, and globally distributed. The expertise needed to identify meaningful failure modes increasingly lives across universities, independent research communities, and regional specialists. 

EXTRA reflects a practical shift in how AI security testing must operate going forward. External expertise is no longer supplemental to red teaming; in many cases, it is essential. 

Microsoft would like to thank these people for their important contributions with this project: Steph Ballard, Blake Bullwinkel, Nicholas Butts, Janelle Bryant, Kaja Ciglic, Hector de Rivoire, Eugenia Kim, Amanda Minnich, Shujaat Mirza, Jingxia Ni, Saphir Qi, Giorgio Severi, Hilary Solan, Hiwot Tesfaye, Sam Vaughan, Marguerita Wicklander, and the many teams at these schools around the world who helped coordinate 

The post Enhancing AI security through global AI red teaming appeared first on Microsoft Security Blog.

Why security needs a new Cyber Stack — Introducing Project Perception

The physics of cybersecurity are changing. Autonomous systems can now reason, adapt and operate continuously. At the same time, the cost of offense is falling, while the volume, velocity and complexity of what must be secured continues to grow. Attackers can generate exploits faster, scale campaigns further and operate with unprecedented efficiency. The approaches built for a world of human actors cannot keep pace with a world of AI, agents and machine-speed attacks.

Security needs a new Cyber Stack. A new Cyber Stack must continuously perceive risk across the entire digital estate, reason across vast amounts of context and take action at machine speed. It must learn and adapt as environments evolve, helping organizations stay ahead of threats. And because security is ultimately a human mission, it must amplify defenders with better insights and more powerful ways to act. The defining characteristic of the next generation of security systems will not be their ability to generate more alerts. It will be their ability to continuously perceive, reason and act.

That vision led us to build Project Perception. A new agentic security system designed for the realities of AI. It turns signals into real-time protections using AI to defend against AI.

Project Perception brings together signals, context, models and specialized agents into a continuously learning system of defense. It can reason, prioritize and act at machine speed while keeping humans firmly in control and empowering them with powerful new workflows.

Project Perception is based on a simple idea: effective defense requires continuous understanding of how an attacker sees the world, how a defender evaluates risk and how protections are improved over time. To accomplish this, Perception coordinates three classes of specialized agents. Red team agents identify potential paths to compromise before an attacker can exploit them. Blue team agents investigate, reason over context and determine what represents meaningful risk. Green team agents take corrective actions and strengthen defenses across the environment. Working together, these agents form a closed-loop system that continuously discovers, evaluates and improves an organization’s security posture.

A system like Project Perception is only as effective as the visibility it has, the actions it can take, the experience of the teams building it and the models it can use. Microsoft brings together all four.

We see across identities, endpoints, applications, data, clouds and AI systems, providing broad visibility across the digital estate. Equally important, we can help customers take action across those environments. Combined with decades of security research, threat intelligence and real-world operational experience defending organizations, these capabilities shape how Project Perception reasons, prioritizes and responds.

Security is a 24/7 mission. Organizations need protection that is highly effective, continuously available and affordable at scale. That requires more than access to the most capable model. It requires applying the right model to the right task. Project Perception adopts a multi-model architecture that combines frontier and specialized cyber models, optimizing for both quality and cost.

As part of this multi-model strategy, we are committed to bringing customers the best models for each security task, including innovating with our own specialized models. The first scenario is software vulnerability management, bringing MAI-Cyber-1-Flash inside MDASH, our software vulnerability multi-model team of agents. MDASH with MAI-Cyber-1-Flash delivers 96% on CyberGym, an industry leading benchmark, +12 points above Mythos. And this same configuration delivers almost 50% of cost savings vs. the current MDASH configuration in market today. That’s the power of a well-tuned, multi-model system with access to uniquely rich historical training data. Next, Project Perception will take advantage of MAI-Cyber-1-Flash for many more security workflows, beyond the software vulnerability scenario.

We are bringing this vision to customers around the world through Project Perception, which enters public preview on August 3.

A Cyber Stack built for agentic security

Delivering agentic security requires more than adding agents to existing workflows. It requires a new Cyber Stack, designed from the ground up.

The stack begins with signals and sensors that provide awareness across the digital estate. Security context transforms those signals into token-efficient understanding that agents can use. Models provide intelligence and reasoning. A harness coordinates models and agents across security workflows. Agents apply that intelligence across security workflows and actuators translate decisions into protection. Together, these layers create a continuous learning system that can understand risk, adapt to changing conditions and improve security outcomes over time.

While each layer provides important capabilities, the power of Project Perception comes from how they work together.

Security context built for AI

Effective reasoning requires more than raw signals. Agents need context.

Microsoft transforms its breadth of visibility, threat intelligence and security expertise into a security context that connects security data, knowledge and semantics across the digital estate. The result is a continuously updated representation of an organization’s assets, identities, relationships, risks and activities that gives agents a shared, near real-time, understanding of the environment they are helping to defend.

This shared understanding is foundational to how Project Perception operates. Rather than forcing agents to continuously gather, correlate and reconstruct context from raw signals, it provides them with immediate and token-efficient access to the information they need to reason over risk, prioritize actions and make decisions. By grounding every interaction in this rich security context, Project Perception improves the accuracy and consistency of reasoning while reducing the time, compute and cost required to operate at scale.

A multi-model architecture built for security

No single model will be optimal for every security task. Effective cyber defense requires applying the right model to the right problem at the right time.

For Project Perception, the right model is determined by the combination of quality, reliability, latency and cost. Rather than relying on a single model, Project Perception adopts a multi-model architecture that continuously selects the capabilities best suited to the task, optimizing for both effectiveness and economics. Because security is an always-on mission, sustainable economics are essential to operating protection at scale.

This approach is shaped by ongoing research, benchmarking and evaluation across frontier and specialized models. Our security researchers continuously assess models against real-world security workflows, enabling us to match each task with the model that delivers the best outcome. This allows customers to benefit from advances in AI without being tied to any single model.

Actuators — insights to actions

Security teams do not need more information. They need better outcomes.

That is why actuators are a critical part of the Cyber Stack. Project Perception is deeply integrated across Microsoft Security products, enabling agents to connect insights to actions. Organizations can continuously reduce risk rather than simply identify it, helping defenders strengthen security while remaining in control.

Built with safety first

Underpinning every layer of the Cyber Stack is a foundation of trust. Project Perception is built in alignment with Microsoft’s Responsible AI principles and inherits the security, compliance, governance and operational controls our customers already rely on. This ensures these capabilities are delivered with the same rigor, accountability and enterprise readiness that customers expect.

The future of security

Security has always been a race between attackers and defenders. AI changes the speed, scale and economics of that race. Defenders need systems that can continuously perceive, reason and act alongside them.

 Project Perception is how we begin to build that future.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

Other resources:

• Enhancing AI Security Through Global AI Red Teaming 
• From research to reality: An interview with Microsoft VP of Security Research Taesoo Kim

Hayete Gallot leads Microsoft’s work to help organizations operate securely in an AI-driven world. Her scope includes identity, threat protection, compliance and data security at global scale.

The post Rethinking security for the age of AI appeared first on The Official Microsoft Blog.