Microsoft Agent Framework: Strong Tooling, Security Left to You

What happened

Microsoft's Agent Framework, now at version 1.0, is drawing two kinds of attention. One is an enthusiastic feature review that gives it a top grade 1. The other is a more cautious security reading that asks what happens once agents built on it start talking to the outside world 2. The two assessments mostly do not contradict each other. Together they describe a framework that is well equipped for building multi-agent systems but deliberately does not promise that what you build will be safe by default.

The feature story: MCP, workflows and orchestration

The positive case rests on how much of the agent-building stack ships in the box. The core package includes a Model Context Protocol (MCP) client that works over both stdio and streamable HTTP 1. That client comes with controls that matter in practice: a tool allow-list, per-tool approval, and optional progressive disclosure of tools 1. Those settings give developers a say over which external capabilities an agent can reach and when a human has to sign off.

Beyond tool access, the framework offers graph-based workflows with checkpointing. In-memory and file-based storage are included in the core 1. It also ships five orchestration patterns: sequential, concurrent, handoff, group chat, and Magentic 1. Teams moving from prototype to production usually have to assemble this kind of plumbing themselves. Shipping it natively is a large part of why the framework scores well on capability.

The feature review also credits Microsoft with publishing a dedicated safety page. It highlights FIDES, an information-flow control middleware meant to defend against prompt injection 1. The caveats are significant, though: FIDES is experimental and only available in Python 1.

The security story: primitives, not guarantees

The security assessment builds on the same foundations but draws a sharper conclusion. Researchers note that the framework's security posture depends on native support for MCP and Agent-to-Agent (A2A) protocols. It also depends on an explicit design principle: arguments and outputs that an LLM supplies to tools should be treated as untrusted input, not as a trusted internal component 2. In other words, Microsoft provides the building blocks for a secure system but does not claim the system is secure by default 2.

That distinction has consequences. Once an agent built with the framework connects to an external MCP server, it inherits the known MCP risks around trust boundaries and tool descriptors 2. The allow-lists and approval gates in the feature review are exactly the primitives meant to manage that exposure 1. They only help if developers actually configure them.

The security review ties this to a concrete precedent. According to that account, Microsoft's own security team found a chain of three vulnerabilities in the legacy AutoGen Studio in June 2026. The chain let a malicious webpage trigger arbitrary process execution on the host through an unauthenticated localhost MCP endpoint 2. That incident involved older tooling, not Agent Framework 1.0 itself. Still, it shows how an agent's protocol surface can become an attack path when trust assumptions are loose.

Where the two readings meet

The sources largely agree on the facts and differ in emphasis. The feature review treats the MCP controls, safety documentation, and FIDES as strengths, and they are 1. The security review asks who carries the burden of using those strengths correctly, and the answer is the developer 2.

The status of FIDES sits right at that seam. A prompt-injection defense built on information-flow control directly targets one of the hardest problems in agent security. Being experimental and Python-only, however, it cannot yet be treated as a baseline protection for every team using the framework 1. Teams working in other languages, or those unwilling to depend on experimental components, have to rely on the more basic controls and their own architecture.

Our reading

On this evidence, Microsoft Agent Framework 1.0 earns its strong marks as an engineering toolkit. Built-in MCP support, checkpointed workflows, and a varied set of orchestration patterns make it a serious option for teams building multi-agent systems 1.

The framework's honesty about trust is also its main warning. By framing LLM-generated tool calls as untrusted input and offering primitives instead of guarantees, Microsoft is telling developers that security is their job 2. That is a defensible stance, and arguably more truthful than a secure-by-default claim would be. But the AutoGen Studio episode shows the cost of getting it wrong 2.

Teams adopting the framework should treat tool allow-lists, per-tool approval, and careful vetting of external MCP servers as mandatory configuration, not optional extras 12. A grade of A for capability does not automatically mean an A for safety. That second grade depends on how each team uses the tools it has been given.