Microsoft Agent Framework 1.3.0 Pulls AutoGen Lessons Into a Security-First Python Runtime

Microsoft Agent Framework 1.3.0 for Python reads like a release from a team that has stopped trying to prove agents are possible and started asking what happens when they are allowed near enterprise data. That shift matters. AutoGen made multi-agent systems feel approachable; Agent Framework is increasingly where those ideas are being rebuilt with policy, workflow structure, approvals, MCP, and security middleware in mind.

The May 8 release is broad: information-flow control prompt-injection defense, class-based skills, experimental session, todo, and memory harness context providers, allowed-tool controls for OpenAI and Gemini, approval enforcement for Claude and GitHub Copilot agents, declarative workflow support for MCP and HTTP actions, and fixes around unreachable MCP servers and hosted MCP replay. The important thread is not the number of bullets. It is the direction of travel. Microsoft is pulling agent development out of the research playground and into a runtime that can express who may see what, which tool may run, and where human approval is required.

Prompt injection defense is finally being treated like data-flow security

The headline addition is information-flow control prompt-injection defense in agent-framework-core, implemented through PR #5331. That PR merged on May 5 and changed 15 files with 7,978 additions and 31 deletions. Its description says it adds the FIDES information-flow control security model for tracking integrity and confidentiality through agent execution, along with secure-agent middleware, secure tools, context-provider-based configuration, policy enforcement, and hidden-content handling.

That is the right level of ambition. Too much prompt-injection defense has been sold as prompt etiquette: tell the model to ignore malicious instructions, add a few warnings, classify something as untrusted, then hope the model behaves. Information-flow control starts from a better premise. Agent execution is data movement across trust boundaries. A web page, an email, a ticket comment, a retrieved document, a tool result, and a system instruction are not equivalent just because they are all text by the time they reach the model.

The practical questions are architectural: which inputs are high-integrity, which are low-integrity, which contain secrets, which can influence tool choice, and which must never be surfaced back to the user? A runtime that can track those labels and enforce policy has a chance of defending real systems. A prompt that says “do not leak secrets” does not.

FIDES will need scrutiny before anyone treats it as solved security. The hard part is not inventing labels; it is preserving them across model calls, tool outputs, streaming responses, memory writes, summaries, and human-in-the-loop edges. But putting the model inside a policy-aware execution graph is the correct shape of the solution. It moves prompt injection from vibes to runtime semantics.

ClassSkill is supply-chain surface, not just ergonomics

The other major addition is ClassSkill, added through PR #5678, which merged on May 7 after changing 8 files with 1,584 additions and 85 deletions. It supports class-based skill definitions with declarative metadata, automatic method discovery, @ClassSkill.resource and @ClassSkill.script, method and property resources, lazy per-instance discovery, duplicate-name detection, content caching, constructor injection, and runtime kwargs.

That sounds like developer experience work, and it is. But skills are becoming package-like units of agent capability: instructions, resources, scripts, metadata, and executable affordances bundled together. Once skills are portable, discoverable, and reusable, they become part of the agent supply chain. The framework needs to know what a skill exposes, what it can run, which resources it brings into context, and whether names collide with something already registered.

Duplicate-name detection is not glamour work. Neither is lazy discovery. But these are the edges that matter when skills stop being hand-wired examples and start being internal packages shared across teams. The security posture of agent frameworks will increasingly depend on whether capabilities are inspectable before they are invoked. Class-based skill definitions can help there if the metadata is treated as governance surface rather than decoration.

The AutoGen migration story is now explicit

Microsoft’s own migration guide says Agent Framework is “developed by the core AutoGen and Semantic Kernel teams” and is “designed to be a new foundation for building AI applications going forward.” That sentence deserves more attention than the release bullets. It makes clear that Agent Framework is not a side experiment next to AutoGen. It is the enterprise-runtime path for ideas that AutoGen helped popularize.

The programming model reflects that. AutoGen’s high-level Team abstractions and event-driven style were useful for exploration. Agent Framework centers on typed, graph-based Workflow, request-response human-in-the-loop patterns, checkpointing, hosted tools, middleware, MCP integration, and observability. That is what happens when a lab framework grows up and has to answer procurement-adjacent questions: how do approvals work, how do we replay state, how do we prevent a tool from running, how do we know what happened, and how do we shut it down safely?

Version 1.3.0 adds allowed-tool controls for OpenAI and Gemini, GPT-5 verbosity options, function approval flow in Foundry hosted agents, approval-mode enforcement in Claude and GitHub Copilot agents, and Python declarative workflow support for InvokeMcpTool and HttpRequestAction. Those are not random integrations. They are the outline of a runtime that assumes agents will span providers, tools, hosted environments, and enterprise approval workflows.

For builders currently using AutoGen, the action is not to panic-rewrite. It is to inventory the system. Which parts are orchestration logic? Which are reusable skills? Which are tool policies? Which rely on implicit human judgment? Which need checkpointing or replay? Those concerns map differently in Agent Framework than in AutoGen. A direct port that only preserves agent roles will miss the point.

For teams already on Agent Framework, 1.3.0 is a release to test carefully. Try the security middleware against actual prompt-injection fixtures, not toy strings. Verify approval enforcement across provider agents. Exercise unreachable MCP servers and hosted MCP replay. The interesting feature is not that the agent can do more. It is that the runtime is beginning to say no, preserve context, and explain why.

Microsoft’s agent stack is becoming less fun to demo and more useful to operate. That is a compliment. The next phase of agent frameworks will not be won by the prettiest autonomous loop; it will be won by the runtime that can constrain the loop when the data, tool, or instruction is untrusted.

Sources: Microsoft Agent Framework Python 1.3.0 release, PR #5331, PR #5678, Microsoft AutoGen migration guide