Microsoft Agent Framework and AutoGen security guide: Identity, Tool Approval, Secrets and Telemetry Controls

Microsoft Agent Framework agents run tools, call MCP servers and reach Azure resources with whatever credential the hosting process holds, and teams migrating from AutoGen often carry over defaults that were acceptable in research code but not in production. AutoGen is now archived: its repository states that Microsoft provides no bug fixes, security fixes, new features or support, and points users to Microsoft Agent Framework as the successor. This guide covers the four controls that decide how risky an Agent Framework deployment is: the identity the agent runs as, which tools it may call and who approves them, where secrets live, and what telemetry records. It is written for engineers and security reviewers building on Agent Framework (Python or .NET) or still running AutoGen. The cross-framework picture, including code execution sandboxing, is in the Securing Agent Frameworks Guide; this page goes deeper on Microsoft's framework. Facts are from Microsoft Learn and the project repositories as checked on 28 October 2026.

Key takeaways

• Treat AutoGen as unsupported software. It receives no security fixes, so production AutoGen workloads need a migration date, pinned dependencies and compensating controls until then.
• Use a specific credential in production. Microsoft advises ManagedIdentityCredential or another specific credential instead of DefaultAzureCredential, whose fallback chain can probe credentials you did not intend to use.
• Mark sensitive tools always_require. Approval is opt-in per tool; the documentation's never_require examples are for brevity only.
• Keep approval response binding on. It stops a fabricated or replayed approval from authorising a privileged call; disabling it is documented as a risk.
• Leave ENABLE_SENSITIVE_DATA off in production. When on, traces carry prompts, responses, tool arguments, tool results and exception messages.

Status: what you are actually running

Check the repository's python/PACKAGE_STATUS.md when you upgrade, because packages move between alpha, beta, release candidate and released.

Identity: who the agent is

An Agent Framework agent has no identity of its own. Its model client, Foundry project client and Azure tools authenticate with the credential you pass in, so the agent's effective permissions are those of that credential, plus whatever each tool's own credential allows.

• Production credential: the samples use AzureCliCredential or DefaultAzureCredential for convenience. Microsoft's guidance is to use a specific credential such as ManagedIdentityCredential in production, avoiding latency, unintended credential probing and fallback risks.
• One identity per agent workload: give each deployed agent its own user-assigned managed identity, so role assignments, sign-in logs and revocation map to one agent. Sharing one identity across agents makes it impossible to tell which agent did what.
• Role assignments sized to the tools: the identity needs model access (for example, a data-plane role on the Foundry or Azure OpenAI resource) plus what each tool calls. Assign at resource scope, not subscription.
• Keys only where unavoidable: non-Azure providers take API keys. Load them from environment variables or a secret store; the migration guide notes AutoGen samples passing api_key inline and recommends credentials instead.
• Agent registries: for directory-level agent identities, see the Microsoft Entra Agent ID Guide and the Agent Identity and Access Guide.

Tool permissions and human approval

Agent Framework agents loop over tool calls until they produce a final answer, unlike AutoGen's AssistantAgent, which is single-turn unless max_tool_iterations is raised. More autonomy per run makes the approval model more important.

• Binding: by default a local approval authorises a call only if it matches a pending request recorded in the same AgentSession; unbound responses are ignored and logged. Microsoft warns that turning binding off can let a fabricated or replayed response approve a privileged call.
• Standing approvals persist in the session: rules are stored in AgentSession state, not tied to the tool instance, so a replacement tool with the same name, including an MCP tool, can match a saved rule. Scope sessions to one trust boundary and start a new session when the tool set changes.
• Middleware as a policy point: agent middleware can block a call by not invoking call_next(). Use it for argument validation and allowlists, but test that it covers every path, including agents wrapped with as_tool() and tools added at run time. The migration guide's string-matching example is illustrative only.
• Workflow human gates: in workflows, human input uses ctx.request_info(...) with a @response_handler. Write handlers that fail closed (anything other than an explicit approval is a rejection), and validate responses after a checkpoint resume, because pending requests are re-emitted.

For the threat model behind these controls, see the OWASP LLM Top 10 LLM06 Excessive Agency Guide and the AI Agent Tool and Plugin Security Guide.

MCP servers and hosted tools

• Local servers are processes: MCPStdioTool(command=..., args=[...]) launches a local process with the agent's operating system rights. Pin the server package, restrict its arguments (for example, one allowed directory) and run it in the same sandbox as the agent.
• Remote servers: use MCPStreamableHTTPTool. MCPWebsocketTool was removed in Python 1.23. Microsoft states it has not tested or verified third-party MCP servers and that prompt content may be sent to non-Microsoft services.
• Filter tools: set allowed_tools using raw remote tool names; ambiguous names raise ToolExecutionException. Put write-capable MCP tools on the approval list.
• Credentials for MCP: use static_headers for fixed credentials or header_provider for per-run tokens. Headers go only to the configured origin and are dropped on cross-origin redirects, and model-generated tool calls do not pass model-supplied arguments to the header provider. Never pass secrets through tool arguments.
• Hosted tools leave your boundary: code interpreter, web search, file search and hosted MCP run on the provider's service. Review data handling first, and note that local code executors from AutoGen have no Agent Framework equivalent yet.

See the MCP Security Guide.

Secrets and stored state

Agent Framework agents are stateless unless you pass a session, which limits accidental cross-user leakage, but sessions, checkpoints and observability exports all persist data that can contain secrets and personal data.

• Checkpoints: FileCheckpointStorage stores executor state, shared state, pending messages and workflow position. Protect the directory or store, set retention and encrypt at rest.
• Session state: session.state and external session stores (for example Redis) need access control per user or tenant. Scope sessions per user or task.
• Tool return values: a tool that returns a raw API response can hand a token to the model, which may then repeat it. Return only the fields the model needs.
• No .env auto-load: Agent Framework does not load .env files itself, so whatever loads them is part of your secret-handling path. Keep .env files out of images and repositories.

See the API Key Management Guide.

Logging and telemetry

Agent Framework has built-in OpenTelemetry. It emits invoke_agent <agent_name>, chat <model_name> and execute_tool <function_name> spans and metrics such as gen_ai.client.token.usage and agent_framework.function.invocation.duration (which never includes tool arguments or results).

With sensitive data off, failed Python operations keep an error status and error.type but omit exception messages, which also keeps secrets in error text out of traces. Microsoft notes that providers are process-wide, so configure them once and secure exporter endpoints and credentials. For investigation patterns, see the AI Agent Observability and Incident Response Guide.

Metrics to track: share of write-capable tools marked always_require; approval rejections per week; agents running on DefaultAzureCredential in production (target zero); environments with sensitive telemetry on (target zero outside test); AutoGen workloads remaining; MCP servers without a pinned version.

Migrating from AutoGen

1. Inventory: list AutoGen applications, their model keys, tools, code executors, MCP servers and any AutoGen Studio instances.
2. Contain while you migrate: pin AutoGen and dependency versions, remove AutoGen Studio from shared hosts, and move any local code execution into an isolated sandbox.
3. Map components: AssistantAgent to Agent, FunctionTool to @tool, group chats to WorkflowBuilder or the sequential, concurrent and Magentic builders. Swarm and SelectorGroupChat have no equivalent yet.
4. Add controls AutoGen lacked: approval modes, middleware and checkpointing do not exist in AutoGen, so design them in rather than porting behaviour one to one.
5. Test in a pilot: run both versions on the same tasks with telemetry on (sensitive data off), compare tool calls, then cut over. Rollback is the pinned AutoGen deployment, kept only for a dated window.

Common failure patterns

• Copying samples into production: never_require, DefaultAzureCredential and hard-coded approvals such as the Magentic plan-review APPROVE are sample shortcuts.
• Long-lived sessions with standing approvals: a later tool with the same name inherits an earlier approval.
• Sensitive telemetry left on: prompts and tool outputs, including tokens returned by APIs, flow into the tracing back end.
• Unpinned stdio MCP servers: uvx or npx pulls the latest package on each start, so a compromised release runs inside the agent.
• Unsupported AutoGen in production: with no security fixes, every new advisory becomes your problem to mitigate.

Framework mapping

Practitioner checklist

• Set a migration date for every AutoGen workload and pin versions until then.
• Run each production agent on its own managed identity with a specific credential class.
• Mark every write-capable or data-sensitive tool always_require; keep response binding on.
• Limit auto-approval rules and start new sessions when tools change.
• Pin, scope and allowlist MCP servers; pass credentials by header, never in tool arguments.
• Protect checkpoint and session stores with access control, retention and encryption.
• Keep ENABLE_SENSITIVE_DATA off in production and export spans to your SIEM.
• Re-check package status and advisories at every upgrade.

Standards and references

• Microsoft Learn: Agent Framework tool approval
• Microsoft Learn: Agent Framework observability
• Microsoft Learn: Agent Framework MCP tools
• Microsoft Learn: Migrate from AutoGen to Agent Framework
• Microsoft: Agent Framework repository
• Microsoft: AutoGen repository (archived)
• OWASP: Top 10 for LLM Applications 2025

Related NHI Mgmt Group resources: Securing Agent Frameworks Guide, LangChain and LangGraph Security Guide, Microsoft Entra Agent ID Guide, MCP Security Guide, AI Agent Sandboxing and Code Execution Guide.