Microsoft Agent Framework Security: Tool Permissions, Approval Gates and the Semantic Kernel Migration

Yes, and the safety documentation is one of the more candid in this category. Microsoft names its own boundary rather than implying the framework has you covered. The useful question is not whether controls exist but who writes them, how far each reaches, and what remains true after the engineer who wrote it changes teams.

Read the "who writes it" column down the page. Seven of eight rows end at a person on your team, working inside one service, shipping policy as code alongside the feature. That is a reasonable framework design and an entirely normal governance problem, and it arrives at a predictable moment: the second agent.

With one agent, in-process controls are excellent. The person who wrote the tool wrote the approval flag, review caught both, and reading one file tells you the policy. With nine agents across four repositories, the policy is the union of nine files nobody reads together, and no artifact states it. We have now written the same finding about Microsoft Foundry, Bedrock AgentCore, Snowflake Cortex and the OpenAI Agents SDK. Every serious platform governs which data an agent may reach. None decides whether the action it just proposed should happen, because that is a business question and the platform does not know your business.

This is the part of the migration that almost nobody writes about, and it is the one a security reviewer should care about most.

In Semantic Kernel, exposing a method to the model took four deliberate steps. Decorate the method with a KernelFunction attribute in .NET or a kernel_function decorator in Python. Wrap it in a plugin class or build one with the plugin factory. Add the plugin to a Kernel. Pass the Kernel to the agent. The attribute was doing real work beyond registration: it was a marker you could search for. Ask "what can our agents call" and the answer was a grep across the solution.

In Agent Framework the attribute is gone. Microsoft's own migration guide states the change directly, under the heading Tool Function Signatures: Semantic Kernel plugin methods need the attribute, and the solution is that "Agent Framework can use methods directly without attributes". You write a plain function, pass it to the tools parameter, and the function name becomes the tool name while the docstring becomes the description. It is a genuine developer experience improvement and it removes real boilerplate.

It also moves the gate. Exposure is no longer a property of the method, visible where the method is defined. It is a property of the argument list at the call site where the agent is constructed. Both are perfectly auditable in a small codebase. Only one of them survives eleven services and three teams, and it is not the one Agent Framework uses.

If that sounds theoretical, Microsoft has already published the incident that proves the attribute mattered. In May 2026 its security researchers disclosed that a method in the Semantic Kernel SessionsPythonPlugin, DownloadFileAsync, "was accidentally marked with a [KernelFunction] attribute, which officially advertised it to the AI model as a callable tool". An attacker who could land a prompt injection could then have the agent write a payload to the Windows Startup folder and reach full remote code execution. One attribute, applied by accident, on one method, was the entire difference between a private helper and an exposed capability.

Two practical things to do during the port. Build the tool inventory while you are already in the code, as a list of every method passed to a tools parameter and what it can reach, because you will never have a cheaper moment to write it. Then decide which of those need an approval gate before the action runs, and mark them, rather than discovering the list from a postmortem.

On May 7, 2026 the Microsoft Security Blog published research on remote code execution paths in AI agent frameworks, with Semantic Kernel as the named case study. Microsoft describes the library as having over 27,000 stars on GitHub, which is the point: this is not an obscure dependency. Two CVEs came out of it, and both turn a prompt injection into code running on the host.

Microsoft's remediation advice is worth quoting in full because of what it implies: "Our primary recommendation is to upgrade immediately. You don't need to rewrite your agent's architecture; the security updates simply remove the AI model's ability to trigger these functions autonomously."

The fix was not to make the functions safer. The fix was to take away the model's permission to call them. That is tool permissioning, applied by the vendor, after the fact, in a patch. Every team running agents makes that same decision continuously, about their own functions, and most of them make it implicitly by never writing it down.

If you are still on Semantic Kernel while you plan the migration, the version check is the urgent item and the port is the important one. Do not let the second delay the first. Prompt injection reaching a shell is the failure mode we built prompt injection blocking on untrusted input for, and the reason it inspects tool results and retrieved documents rather than only the user's message.

The day before Agent Framework 1.0 shipped, Microsoft released something else that belongs in this conversation and that most vendor pages in our category will not mention, because it competes with them. On April 2, 2026 the Microsoft Open Source Blog introduced the Agent Governance Toolkit, described as "an open-source project released under the Microsoft organization and MIT license that brings runtime security governance to autonomous AI agents".

It is not a Microsoft-only tool. It ships seven packages covering policy enforcement, cryptographic identity, execution rings, SRE practices, compliance verification, plugin management and reinforcement learning governance, in Python, TypeScript, Rust, Go and .NET, and it integrates with LangChain, CrewAI, Microsoft Agent Framework, Google ADK, Dify, LlamaIndex, the OpenAI Agents SDK, Haystack, LangGraph and PydanticAI. Microsoft claims it is "the first toolkit to address all 10 OWASP agentic AI risks with deterministic, sub-millisecond policy enforcement", and is explicit that "it is designed to work with the frameworks developers already use, not replace them".

If you have engineers, an appetite for running your own control plane, and a policy that does not change often, that is a serious answer and it costs nothing in license fees. We would rather tell you that than have you find out after signing something. Microsoft's own caveat applies here as much as anywhere: "No security layer is a silver bullet; defense in depth and ongoing monitoring remain essential."

Separately, for teams already deep in the Microsoft stack, the safety docs point to Agent Security with FIDES for "deterministic, label-based defense against prompt injection and data exfiltration", built as information-flow control middleware that enforces policies before sensitive tools run. That is a stronger primitive than heuristic filtering and worth reading before you buy anything.

So here is the honest split, written the way we would say it on a call.

Five of those eight rows tell you to buy nothing from us. That is not modesty, it is the only way a comparison page is worth reading. If your situation is one of the first five, the rest of this page is background and you should go upgrade a package.