How to build long-running MCP tools on Azure Functions
Recently, a customer building servers with the Azure Functions MCP extension reached out and asked: How do I handle tools that take longer than the client is willing to wait? This becomes especially relevant when tool calls move beyond simple request/response into multi-step workflows and long-running operations. At the same time, MCP is evolving to address exactly this. The Tasks extension is introduced in the 2026-07-28 release candidate, defining a standard way to model long-running work. In this post, we’ll walk through how to build long-running MCP tools on Azure Functions using Durable Functions , a framework for authoring stateful, long-running workflows as ordinary code, with checkpointing, scaling, and recovery handled automatically. MCP tools today Today, MCP tools are fundamentally request/response: the client issues a tools/call the server returns a result This works well for fast operations, but breaks down when: workflows take minutes execution depends on multiple steps latency is unpredictable In practice, clients enforce their own tool-call timeouts. These aren't standardized by the MCP spec and vary per client, but they're often in the ~30–60 second range. If a tool exceeds that window: In practice, clients often enforce short timeouts. If a tool exceeds that window: the client times out the agent observes a failed call the underlying work may still be running So the core issue is that you have synchronous tool calls don’t naturally model long-running work. The MCP Tasks extension The Tasks extension to address this. With the extension, a server can respond to a tools/call with an asynchronous task handle instead of a final result, and the client drives the lifecycle from there: tasks/get: poll the task's status tasks/update: submit input back to the server if the task reaches input_required tasks/cancel: cancel an in-flight task A task carries a status ("working", "input_required", "completed", "failed", or "cancelled") and on completion, the final result. Task creation is server-directed: the client advertises support by including the extension in its per-request capabilities, and the server decides per request whether to return a task. A server won't return a task to a client that hasn't advertised support. It's important to note that Tasks rely on ecosystem support. Clients must advertise the extension, and MCP SDKs must implement the task lifecycle, before servers can use it. So while Tasks is now a defined extension, broad client and SDK support is still in progress. Implement long-runng tasks with Durable Functions today Until the Tasks extension is broadly supported across clients, we need a pattern that works with existing request/response clients and supports long-running execution. The following samples show how, using Durable Functions: Python NET The long-running work in this sample mines a short chain of blocks. Each block requires solving a computational puzzle where the system keeps trying different inputs until it finds one that produces a result matching a specific pattern (for example, starting with a certain number of zeros). Because this involves lots of trial and error, it naturally takes time, making it a good example of a long-running workflow. The server in the sample exposes two tools: start_mining Starts a Durable Functions orchestration to mine the blocks Waits briefly (within a configurable budget) Returns result inline if completed within budget OR returns workflow_id if still running get_mining_result Takes the workflow_id Returns the current state, e.g. "completed", "running", "failed", or "not_found" To ensure that the agent calls the tools in the right order, workflow_id is a required parameter of get_mining_result, so the agent can't poll without starting a mining run first. Also, the "running" response carries a poll_after_seconds and a next instruction, ensuring the agent to poll again if work is not done rather than give up or assume completion. Even so, the poll path still relies on the agent correctly remembering, and not hallucinating, the workflow_id it was handed. If it garbles or invents an id, the poll lands on the wrong instance or none at all (which is why get_mining_result returns "not_found" rather than guessing). What changes with the Tasks extension Once the Tasks extension is fully implemented across clients and SDKs, the model becomes simpler and more reliable: the server returns a Task handle, the client manages the polling and lifecyle calls, and the SDK tracks execution state. This removes a key limitation of today’s solution, which requires the agent to remember and correctly pass identifiers like workflow_id. Call to action Try out the sample and let us know whether it addresses your MCP needs around long-running or workflow type tools!Announcing Go support in Azure Functions (Preview)
We're excited to announce that Azure Functions now supports Go as a first-class language, available today in public preview on the Flex Consumption plan. Go developers can now build event-driven, serverless applications using idiomatic Go, the standard toolchain they already love, and the full breadth of Azure Functions triggers, bindings, and operational capabilities. TL;DR: Write Functions in Go using a new code-first programming model and SDK (azure-functions-golang-worker). Use triggers across HTTP, Timer, Service Bus, Event Hubs, Event Grid, Cosmos DB, and Blob Storage. Why Go on Azure Functions Go has become a default choice for cloud-native APIs, platform services, networking tools, and high-throughput integration workloads. Until now, teams that standardized on Go on Azure had to either: Use Azure Functions through the custom handlers protocol, missing out on a first-class developer experience, or Build and operate their own serving, scaling, and eventing infrastructure on containers or VMs. With first-class Go support, those teams get the productivity of Go plus the operational leverage of serverless: automatic scaling, pay-per-use billing, integrated triggers across the Azure ecosystem, and built-in observability, without leaving the Go ecosystem. What's in the preview A new Go programming model and SDK: a code-first, idiomatic way to register Functions and declare triggers using functional options. Support for popular triggers: HTTP, Timer, Service Bus (queues and topics), Event Hubs, Event Grid, Cosmos DB, and Blob Storage. More to come. Native Go build pipeline: go build produces a single static binary that the Functions host invokes directly. No function.json, no interop shims at request time. Integrated observability: Application Insights logging, metrics, and distributed tracing. End-to-end tooling: local development with a preview build of Azure Functions Core Tools. Deployment via Core Tools, zip deploy, or GitHub Actions. Flex Consumption: fast elastic scale, scale-to-zero, per-second billing, VNet integration, and always-ready instances. A quick look at the programming model The Go model is code-first: you register functions and declare triggers in Go, with compile-time checks and full IDE support. No separate JSON metadata to keep in sync. Here's a minimal HTTP-triggered Function: package main import ( "fmt" "net/http" "github.com/azure/azure-functions-golang-worker/sdk" "github.com/azure/azure-functions-golang-worker/worker" ) func main() { app := sdk.FunctionApp() app.HTTP("hello", hello, sdk.WithMethods("GET", "POST"), sdk.WithAuth("anonymous"), ) worker.Start(app) } func hello(w http.ResponseWriter, r *http.Request) { name := r.URL.Query().Get("name") if name == "" { name = "world" } fmt.Fprintf(w, "Hello, %s!", name) } Notice the HTTP handler is a plain http.HandlerFunc, the same signature you'd use with net/http or any Go web framework. There's nothing Functions-specific to learn at the handler level. Registering other triggers The same pattern works across triggers. Non-HTTP handlers take a context.Context plus a typed payload: import ( "context" "log" "github.com/azure/azure-functions-golang-worker/sdk" "github.com/azure/azure-functions-golang-worker/sdk/bindings" ) // Timer: runs every 10 seconds func onTimer(ctx context.Context, t bindings.TimerInfo) error { log.Printf("timer fired; past due=%v", t.IsPastDue) return nil } app.Timer("cleanup", onTimer, sdk.WithSchedule("*/10 * * * * *"), ) // Service Bus queue func onOrder(ctx context.Context, msg bindings.ServiceBusMessage) error { log.Printf("order %s: %s", msg.MessageId, string(msg.Body)) return nil } app.ServiceBusQueue("processOrder", onOrder, sdk.WithQueueName("orders"), sdk.WithConnection("ServiceBusConnection"), ) // Event Hubs func onEvent(ctx context.Context, e bindings.EventHubMessage) error { log.Printf("event seq=%d body=%s", e.SequenceNumber, string(e.Body)) return nil } app.EventHub("ingest", onEvent, sdk.WithEventHubName("telemetry"), sdk.WithConnection("EventHubConnection"), ) // Cosmos DB change feed func onChange(ctx context.Context, docs []bindings.CosmosDocument) error { for _, d := range docs { log.Printf("doc %s: %s", d.ID, string(d.Data)) } return nil } app.CosmosDB("onChange", onChange, sdk.WithDatabase("ToDoList"), sdk.WithContainer("Items"), sdk.WithConnection("CosmosDBConnection"), ) // Event Grid func onGridEvent(ctx context.Context, e bindings.EventGridEvent) error { log.Printf("%s: %s", e.EventType, e.Subject) return nil } app.EventGrid("onEvent", onGridEvent) Extension triggers: real Azure SDK clients For triggers like Blob Storage, the Go SDK injects a fully-typed Azure SDK client directly into your handler. You opt in with a blank import, so your binary only includes the extensions you actually use: import ( "context" "io" "log" "github.com/Azure/azure-sdk-for-go/sdk/storage/azblob/blob" "github.com/azure/azure-functions-golang-worker/sdk" _ "github.com/azure/azure-functions-golang-worker/triggers/blob" // registers blob trigger client factory "github.com/azure/azure-functions-golang-worker/worker" ) func onUpload(ctx context.Context, client *blob.Client) error { log.Printf("blob: %s", client.URL()) resp, err := client.DownloadStream(ctx, nil) if err != nil { return err } defer resp.Body.Close() data, err := io.ReadAll(resp.Body) if err != nil { return err } log.Printf("size=%d", len(data)) return nil } app.Blob("onUpload", onUpload, sdk.WithPath("uploads/{name}"), sdk.WithConnection("AzureWebJobsStorage"), sdk.WithSource("EventGrid"), ) The handler receives a *blob.Client from github.com/Azure/azure-sdk-for-go/sdk/storage/azblob/blob, the same client you'd use in any other Go app. Because it's a real SDK client, you can DownloadStream blobs of any size without buffering the whole payload through the worker. Dependencies stay isolated per extension, so apps that don't use Blob never pull in azblob or azidentity. Project layout A Go function app is just a regular Go module plus the standard Functions config files: my-function-app/ ├── host.json ├── local.settings.json ├── go.mod ├── go.sum └── main.go No function.json and no generated metadata. Triggers are declared in main.go. go build, go test, and go mod tidy all just work. Get started Quickstart Install the preview tooling, scaffold your first Go function app, run it locally, and deploy to Flex Consumption. We can't wait to see what you build. Welcome to Functions, Gophers.Introducing the Azure Functions serverless agents runtime (preview)
We're thrilled to announce the Azure Functions serverless agents runtime, now in public preview. It brings a new, markdown-first programming model for building AI agents as a first-class workload on Azure Functions, with the event-driven triggers, scale-to-zero economics, and operational integrations you know and love from the platform. A few things you could build in a matter of minutes: A daily briefing agent that wakes up on a timer, scours the web, and drops a summary in your Outlook inbox every morning. A Teams chat agent that triggers on every message and answers your team's questions, looking up data across your connected systems. An on-call troubleshooting agent that investigates incidents by querying logs in Azure Data Explorer and reports back what it found. Each one is a single markdown file with instructions plus a trigger, and deployed like any other function app and running on the Flex Consumption plan. Why a serverless agents runtime Building production agents today usually means stitching together a framework, a hosting layer, message queues, identity, secrets, observability, and a long list of per-service integrations. Most of that work is plumbing, not the agent. Azure Functions has spent years making event-driven compute simple: declare a trigger, write the handler, get autoscale and managed identity for free. The serverless agents runtime applies that same model to agents: Agents are the unit of work. You define behavior in natural language, not boilerplate. Trigger agents from almost any event. HTTP requests, timers, queues, database changes, Teams messages, Outlook mail, and more. Tools, MCP servers, connectors, and sandboxed execution are declared, not coded. Deploy and operate like any function app. Flex Consumption for scale-to-zero and per-second billing, managed identity, VNet integration, Application Insights, and the same deployment tools you already use. Markdown-first: what an agent looks like An agent is a .agent.md file. Your app can have multiple agents, each with its own metadata that declares the trigger. The markdown body becomes the agent's instructions. Here's a timer-triggered agent that summarizes the day's tech news and emails it: --- name: Daily Tech News Email description: Fetches top tech news and emails a summary daily. trigger: type: timer_trigger args: schedule: "0 0 15 * * *" --- You are a news assistant. When triggered, do the following: 1. Scour the web for today's top tech news headlines. Use reputable sources; Include links to the original articles. 2. Summarize the top stories in a concise, well-formatted HTML email body. 3. Email the summary to $TO_EMAIL with the subject "Daily Tech News Summary" followed by today's date. That's the whole function. Drop the file into your app, deploy, and it runs on the schedule. No framework wiring, no service-specific integration code. Your agents can share configuration and capabilities through a few files alongside the agent definitions. agents.config.yaml declares system tools and the default model. mcp.json lists the MCP servers your agents can call, including MCP-enabled Azure connections. A /tools folder holds custom Python tools and a /skills folder holds reusable prompt fragments. Everything here is optional and available to every agent automatically when present. In this example, the agent uses a Container Apps dynamic session to browse the web with Playwright, and a Microsoft Office 365 connection (exposed as an MCP server) to send the email: # agents.config.yaml system_tools: dynamic_sessions_code_interpreter: endpoint: $ACA_SESSION_POOL_ENDPOINT model: $AZURE_OPENAI_DEPLOYMENT // mcp.json { "servers": { "office365": { "type": "http", "url": "$MICROSOFT_365_CONNECTION_MCP_ENDPOINT", "auth": { "scope": "https://apihub.azure.com/.default" } } } } The function app's managed identity authenticates to the connection's MCP endpoint, so there are no secrets to manage. Any Azure connector that supports MCP, or any remote MCP server, can be added the same way. Any of these global settings can be overridden per agent in the agent's metadata. What you get in the preview Triggers across the Azure Functions catalog. HTTP, Timer, Queue, Service Bus, Event Hubs, Cosmos DB, Blob, Event Grid, plus new connection-backed triggers like Teams messages, Outlook mail, and calendar events. 1,400+ Azure connectors as tools. Create a connection, enable its MCP endpoint, and an agent can send mail, post to Teams, create records, query data, all without integration code or auth plumbing. Any remote MCP server as tools. Use any remote MCP server. Sandboxed code and browser automation. Run code or a Playwright-powered browser in Azure Container Apps dynamic sessions, isolated per agent session. Built-in chat UI, HTTP API, and MCP server endpoint with no extra code. Custom Python tools in a tools/ folder and reusable skills in a skills/ folder, shared across agents. Pluggable model providers. Microsoft Foundry, Azure OpenAI, and OpenAI out of the box. Where this fits The serverless agents runtime is designed for the agents most enterprises actually need to build: Scheduled background agents that summarize, monitor, or reconcile on a timer. Event-driven assistants that react to messages, emails, alerts, and database changes. Cross-system agents that tie multiple SaaS and enterprise apps together through connections. Trigger with a Teams message, look up the customer in Salesforce, send an email, and update a database record, all from one agent. Conversational front-ends that pair an HTTP or chat-UI entry point with the same agents your event triggers invoke. Agents as MCP servers that other agents and MCP clients can integrate with directly. We want your feedback The serverless agents runtime is in public preview, and we're actively building it out with input from real customer workloads. Tell us what you build, what's missing, and where the model should go next. Get started Docs: aka.ms/azure-functions-agents-docs Building agents on Azure Functions has never been easier. We can't wait to see what you create with the serverless agents runtime!Azure Functions MCP Extension: What's New at Build 2026
The Azure Functions MCP extension has had a breakout year! Since its initial preview, the extension has grown from a single trigger type into a full-featured platform for building remote MCP servers: with tool, resource, and prompt triggers across multiple languages, MCP Apps for interactive UIs, built-in MCP authentication, and feature enhancements. Here's what's new and what it means for developers building MCP servers on Azure Functions. The full MCP primitive set: Tools, resources, and prompts When the MCP extension first shipped, it supported tool triggers. Declare a function as an MCP tool, and any MCP client can discover and call it. That was the starting point. Since then, we've shipped the remaining MCP primitives: Resource triggers: expose a function as an MCP resource. Prompt triggers: expose a function as an MCP prompt, letting clients request structured prompt templates from your server. Like tool triggers, resource and prompt triggers are supported in multiple languages including .NET, Java, Python, TypeScript, and JavaScript. MCP Apps: interactive UI from your MCP server MCP Apps let your tools return interactive user interfaces instead of plain text. Combine tool triggers with resource triggers, and your MCP server can serve rich, rendered experiences to MCP-aware clients. The Azure Functions MCP extension supports MCP Apps natively, meaning the same function app that exposes tools and resources can also serve UI components. The launch blog post on the Azure Apps Blog walked through the pattern in detail. For .NET developers, the new fluent builder API (available in the latest NuGet release) makes it easier to compose MCP Apps by chaining tool and resource definitions in a declarative style. MCP authentication The extension supports built-in MCP authentication, implementing the requirements of the MCP auth spec. All samples in the aka.ms/remote-mcp repo enable built-in MCP auth by default with Microsoft Entra ID as the identity provider. Samples have also been updated to demonstrate how to exchange tokens in the On-Behalf-Of (OBO) flow, so your MCP tools can access downstream APIs using the invoking user's identity. Auth configuration in the Azure portal: Preview at Build is a one-click experience in the Azure portal for configuring built-in MCP auth. No more manual app registration creating, configuration and wiring to the server. Just open your server app on the portal and click to enable MCP auth. Try it out! Feature enhancements Beyond the headline primitives and auth, the extension has shipped a steady stream of capabilities the past few months. The following are the notable additions. Structured content Structured content lets you return machine-readable JSON metadata alongside your tool's response via the `structuredContent` field. Clients that support it can programmatically consume the data (e.g. parse fields, render tables, drive downstream logic) rather than just displaying text. Clients that don't support it still get the regular content blocks as a fallback. Rich content types Tools aren't limited to returning plain text. The extension supports the full set of MCP content block types, e.g. `TextContent`, `ImageContent`, `AudioContent`, `ResourceLink`, and `EmbeddedResource`, so your tools can return images, audio clips, references to resources, and inline file content alongside text. Input and output schemas `WithInputSchema` and `WithOutputSchema` give you explicit control over the JSON schemas advertised for your tools. This is especially useful when the auto-generated schema from function parameters doesn't capture the full contract. For example, when your tool accepts a complex nested object or returns a specific shape that clients depend on. Input and output schemas are currently supported in .NET, with support for other languages coming soon. builder.ConfigureMcpTool("SearchDocs") .WithOutputSchema(""" { "type": "object", "properties": { "results": { "type": "array", "items": { "type": "string" } }, "query": { "type": "string" } }, "required": ["results", "query"] } """); Fluent configuration APIs in .NET A set of fluent builder APIs that let you configure MCP primitives declaratively in `Program.cs`: ConfigureMcpTool: add properties, metadata, input/output schemas, or promote a tool to an MCP App ConfigureMcpResource: attach metadata to resources ConfigureMcpPrompt: define prompt arguments and metadata builder.ConfigureMcpTool("sayhello") .WithProperty("name", McpToolPropertyType.String, "Name of the user", required: true) .WithMetadata("ui", new { resourceUri = "ui://index.html" }); What's next Usage of the MCP extension has grown steadily since its preview launch. Tool execution volume has increased 15x over the past several months as more customers move from experimentation to production. As adoption grows, so do the expectations. Developers building production MCP servers are hitting real friction around auth complexity, client configuration, and observability. We're continuing to invest in the extension to address these gaps and help customers be more successful building and hosting MCP servers on Azure Functions. Here's where we're focusing next. Continued auth simplification Auth remains the biggest barrier to getting an MCP server into production. We'll work on: Smoother client setup: making it easier to connect any MCP client to an authenticated Azure Functions MCP server, not just VS Code. Simplified OBO flow: streamlining the experience of On-Behalf-Of authentication so developers can delegate user identity to downstream services with less configuration. Our goal: the secure path should be the easy path. Deeper integration with Microsoft Foundry We'll build tighter integration between Azure Functions MCP servers and Microsoft Foundry. This includes surfacing MCP servers in Foundry Toolbox, a new feature introduced to help Foundry agents discover and consume tools from a single endpoint. Developers will be able to publish an MCP server from Functions and have it available to Foundry agents through Toolbox without manual endpoint configuration. Continued feature enhancement We prioritize based on feedback from the community raised in our GitHub repo. For example, support for streaming output and pagination are top items in our backlog today based on user demand. We also track the MCP spec's evolution closely and will continue shipping support for strategic features as they land. Examples of proposals we're following: MCP Tasks: the Tasks extension (SEP-2663) defines a standard pattern for async, long-running tool calls with durable task handles. This replaces hand-rolled polling patterns and aligns well with Functions' execute-and-return model. Stateless MCP: SEP-2575 proposes removing the mandatory initialization handshake, which is a natural fit for serverless platforms like Azure Functions where fresh instances can handle any request. Have something you'd like us to prioritize? Let us know by filing a request on GitHub. Get started Samples: Samples showcasing most up-to-date features: aka.ms/remote-mcp Documentation: Model Context Protocol for Azure Functions MCP Extension GitHub repo: Azure Functions MCP ExtensionAnnouncing managed connectors for Azure Functions (Preview)
Azure Functions now includes managed connectors in public preview - the same 1,400+ connector ecosystem behind Logic Apps and Power Platform - as first-class triggers in your Functions code, plus typed SDKs for invoking connector actions from your function body. Build event-driven integrations with Microsoft 365, Salesforce, ServiceNow, SAP, Dynamics 365, and 1,400+ other systems using familiar Functions syntax. This release is the result of close collaboration between the Azure Functions team and the Connectors team, the same team that builds and maintains the connector ecosystem behind Logic Apps and Power Platform. Triggers, SDKs, and the connection runtime were designed together so that connectors feel native to Functions, and so that the connector library that already powers thousands of Logic Apps workflows in production is available to Functions developers. The integration is built on the new Connector Namespace service, which brings the Logic Apps/Power Platform connector runtime to developers as a programmable integration layer. A quick look: new Outlook email → post to Teams Here's a function example (adapted from the sample app): the Office 365 trigger fires on every new email in the watched inbox, and the function posts a notification to a Teams channel using the Teams connector SDK. using Microsoft.Azure.Functions.Worker; using Microsoft.Azure.Functions.Worker.Extensions.Connector; using Azure.Connectors.Sdk.Office365.Models; using Azure.Connectors.Sdk.Teams; using Azure.Connectors.Sdk.Teams.Models; public class ProcessEmail(TeamsClient teams) { private readonly string _teamId = Environment.GetEnvironmentVariable("TEAMS_TEAM_ID")!; private readonly string _channelId = Environment.GetEnvironmentVariable("TEAMS_CHANNEL_ID")!; [Function("OnNewEmail")] public async Task Run([ConnectorTrigger] Office365OnNewEmailTriggerPayload payload) { foreach (var email in payload.Body?.Value ?? []) { var message = new PostMessageRequest { Recipient = new() { GroupId = _teamId, ChannelId = _channelId }, MessageBody = $"<b>📧 New email</b><br/><b>From:</b> {email.From}<br/><b>Subject:</b> {email.Subject}" }; await teams.PostMessageToConversationAsync("Flow bot", "Channel", message); } } private sealed class PostMessageRequest : DynamicPostMessageRequest { public RecipientInfo Recipient { get; set; } = new(); public string MessageBody { get; set; } = ""; } private sealed class RecipientInfo { public string GroupId { get; set; } = ""; public string ChannelId { get; set; } = ""; } } The TeamsClient is registered with DI at startup against the Teams connection's runtime URL — the same managed identity the trigger uses authenticates the outbound call. No OAuth code in the function. No HTTP client. No token handling. For the complete end-to-end samples see the Functions Connectors Samples repo. What's shipping in preview Connector triggers. First-class Functions triggers backed by Connector Namespace connections - Office 365 new-email, Teams message-posted, SharePoint item-created/updated, Dataverse row-changed, Salesforce record-updated, calendar events, and more. Configured via the [ConnectorTrigger] attribute (C#) and equivalent decorators as language SDKs roll out. Typed connector SDKs. Strongly-typed client libraries for invoking connector actions from inside your function — OutlookClient, TeamsClient, Office365UsersClient, DataverseClient, SalesforceClient, and growing. Built jointly by the Connectors and Functions teams. Auth via managed identity and built-in authentication. Configure the function app with built-in authentication to allow only the Connector Namespace to trigger the function. See .NET sample: built-in authentication with managed identity. Observability. Every connector trigger run is recorded with information about the run. End to end tracing into the Function App is on the roadmap. Typed SDKs are rolling out incrementally. Not all 1,400+ connectors have strongly-typed SDKs today, and language coverage will expand over time. You can see the ones supported in the different SDK repos for .NET, Python, and Node.js. The connector catalog The full catalog is the Logic Apps connector library is in scope. Below are the categories most relevant to enterprise integrations: Microsoft 365 Outlook (Office 365) — send email, create drafts, search mailbox, read calendar, manage events Microsoft Teams — post messages, create channels, list team members, manage meetings and tabs SharePoint — read and write lists and document libraries, subscribe to item-created/updated events OneDrive for Business — upload and download files, manage folders, track changes Excel Online (Business) — read and write worksheets, add rows, call named functions in workbooks CRM and operations Dataverse / Dynamics 365 — full entity CRUD across all standard and custom tables; use ODATA filters Salesforce — query and write contacts, leads, opportunities, and cases via SOQL ServiceNow — create and update incidents, change requests, and CMDB records Workday — read worker, position, and organization data ERP and data SAP — call BAPIs and read tables (uses on-premises data gateway for SAP behind a firewall) SQL Server — execute queries, stored procedures, and table operations Oracle Database — same surface as SQL Server PostgreSQL — query and write via the generic SQL connector Developer and platform Azure DevOps — read and write work items, pipelines, repositories, and pull requests GitHub — manage issues, PRs, and repository content. More trigger examples // Office 365 — new email [Function("OnNewEmail")] public Task OnNewEmail([ConnectorTrigger] Office365OnNewEmailTriggerPayload payload) { /* ... */ } // Teams — new channel message [Function("OnTeamsMessage")] public Task OnTeamsMessage([ConnectorTrigger] TeamsOnNewChannelMessageTriggerPayload payload) { /* ... */ } // SharePoint — list item created [Function("OnTicketCreated")] public Task OnTicketCreated([ConnectorTrigger] SharePointOnNewListItemTriggerPayload payload) { /* ... */ } // Salesforce — record updated [Function("OnOpportunityUpdated")] public Task OnOpportunityUpdated([ConnectorTrigger] SalesforceOnRecordUpdatedTriggerPayload payload) { /* ... */ } The connection that backs each trigger is configured on the Connector Namespace as part of deployment, so trigger declarations stay focused on the event payload, not on auth or connection wiring. Pricing There is no extra cost for the integration itself. You pay: Existing Azure Functions pricing for execution (Flex Consumption per-second billing). Existing Logic Apps connector pricing for connector calls, billed at the same per-action rates Logic Apps customers pay today. See the Logic Apps pricing page for current connector rates and standard/enterprise connector tiers. Preview restrictions Language and runtime support: typed SDKs and the [ConnectorTrigger] attribute ship first for C# (.NET 10 isolated worker), followed closely by Python and Node.js. Java, and PowerShell are on the roadmap. Typed SDK coverage: not every connector in the 1,400+ catalog has a typed SDK yet but coverage is expanding. Regional availability: connector triggers are enabled per region as Connector Namespace rolls out. Check the documentation for the current region list. Calls to action Developers building integrations with SaaS or enterprise systems should explore managed connectors in Azure Functions to reduce integration complexity and accelerate delivery. Partners can position this for customers migrating from on-premises integration platforms or looking to modernize custom integration code into a serverless, event-driven architecture. Customers running both Logic Apps and Functions today can consolidate integration logic: keep workflow-style orchestrations in Logic Apps, and move code-first event-driven integrations into Functions with the same connector library. Get started Documentation: Azure Functions integration with managed connectors Samples: Azure Functions integration with managed connectors in Azure Functions samples Looking for connectors as tools for AI agents? That's covered in the serverless agents Azure Functions runtime, which builds on this same Connector Namespace integration to expose connections as MCP tool servers for the agents runtime.Azure Functions at Build 2026 Update
Azure Functions took another big leap at Build 2026. It is now the best programming model for event-driven apps and agents, on the best infrastructure to write secure code that scales. The headline features: serverless agents, connectors to M365, Teams, and more, Go, MCP, and Durable Tasks. Microsoft Copilot scales AI workflows to hundreds of millions with Durable Task Scheduler Before we start with all the announcements, we want to highlight a new case study. As Microsoft Copilot scaled to support complex, long-running AI workflows, engineering teams needed a more reliable and consistent orchestration model. By standardizing on Durable Task Scheduler in Azure Functions, Copilot unified state management, retries, and recovery across services, helping run hundreds of millions of executions weekly while improving resilience and delivery speed. Read the customer story: https://aka.ms/microsoft-copilot-dts Serverless agents runtime (Preview) → Full post Azure Functions now has a first-class programming model for AI agents. Define an agent in a .agent.md file with markdown instructions plus metadata that declares the trigger and tools, and deploy it exactly like any other Function. No framework to wire up, no hosting infrastructure to manage. Any Azure Functions trigger can run an agent: HTTP, Timer, Service Bus, Event Hubs, SQL Database, Cosmos DB, or the new connection-backed triggers (Teams message, Outlook mail, calendar events, SharePoint item). Agents get access to MCP tool servers, sandboxed code and browser execution via Azure Container Apps dynamic sessions, and the full 1,400+ connector catalog. Built-in surfaces like chat UI, HTTP chat API, and MCP server endpoint are opt-in with no extra code. The operational model is exactly what you already know: Flex Consumption for scale-to-zero and per-second billing, managed identity for auth, Application Insights for traces, azd for deployment. Here's a timer-triggered agent that summarizes the day's tech news and emails it: --- name: Daily Tech News Email description: Fetches top tech news and emails a summary daily. trigger: type: timer_trigger args: schedule: "0 0 15 * * *" --- You are a news assistant. When triggered, do the following: 1. Scour the web for today's top tech news headlines. Use reputable sources; Include links to the original articles. 2. Summarize the top stories in a concise, well-formatted HTML email body. 3. Email the summary to $TO_EMAIL with the subject "Daily Tech News Summary" followed by today's date. That's the whole function! Managed connectors (Preview) → Full post Azure Functions now includes the same 1,400+ managed connectors behind Logic Apps and Power Platform as first-class triggers in your Functions code, plus typed SDKs for invoking connector actions from your function body. Built jointly with the Connectors team on the new Connector Namespace service, so connectors feel native to Functions and the library that already powers thousands of Logic Apps workflows is now available to Functions developers. React to SaaS events with first-class triggers like Office 365 new-email, Teams message-posted, SharePoint item-created, Dataverse row-changed, Salesforce record-updated, calendar events, and more using the [ConnectorTrigger] attribute. Call connector actions from your code via strongly-typed clients like OutlookClient, TeamsClient, Office365UsersClient, DataverseClient, and SalesforceClient. public class ProcessEmail(TeamsClient teams) { [Function("OnNewEmail")] public async Task Run([ConnectorTrigger] Office365OnNewEmailTriggerPayload payload) { foreach (var email in payload.Body?.Value ?? []) { await teams.PostMessageToConversationAsync("Flow bot", "Channel", new PostMessageRequest { Recipient = new() { GroupId = _teamId, ChannelId = _channelId }, MessageBody = $"<b>New email</b> from {email.From}: {email.Subject}" }); } } } MCP updates → Full MCP extension post The Azure Functions MCP extension now covers all the MCP primitives like tool, resource, and prompt triggers are supported in .NET, Java, Python, TypeScript, and JavaScript. The extension also supports MCP Apps for interactive UI, where your tools can return rendered widgets instead of plain text. And for .NET developers, a new fluent builder API makes it easier to compose MCP servers by chaining tool and resource definitions in a declarative style: builder.ConfigureMcpTool("sayhello") .WithProperty("name", McpToolPropertyType.String, "Name of the user", required: true) .WithMetadata("ui", new { resourceUri = "ui://index.html" }); Finally, Built-in MCP authentication now offers a one-click configuration experience in the Azure portal, and a new AI tab in your function app lets you enable MCP auth without manual app registration or wiring. New Azure Functions CLI (Preview) V5 is here! A ground-up, next-gen build of the Azure Functions CLI. Now in public preview this release gives local Functions development a refresh. Configuration profiles let you define your deployment targets up front, so func init can scaffold a project with full‑fidelity host settings in a single command. That means no more surprises when you deploy, earlier access to new platform capabilities, and improved reliability across environments. New func setup preps your machine for .NET, Node, Python, or Go in one command. The func quickstart command scaffolds complete, ready-to-run apps from a curated catalog. And a new interactive func run dashboard gives you a live TTY UI with a function browser, log navigation, and keyboard shortcuts. Existing func workflows for create, run, publish, and deploy carry forward unchanged, so you can try v5 alongside your current projects. Give it a spin and let us know what you think. Full command reference: Azure Functions local runtime and tools reference (v5) Azure Functions VS Code Template Gallery (Preview) The latest version of the Azure Functions extension for VS Code introduces a new Template Gallery, giving you single-click access to complete, ready-to-deploy templates. The gallery is hand-curated and maintained by the Functions team to keep every template aligned with the latest releases and best practices, including Azure Developer CLI (AZD) enablement and recommended settings. It already covers the majority of supported languages and triggers, and will continue to expand with the newest Azure Functions features. The same templates are available across both VS Code and the new Functions CLI (func quickstart). Go language support (Preview) → Full post Azure Functions now supports Go as a first-class language, available on Flex Consumption. The programming model is code-first and idiomatic: HTTP handlers are plain http.HandlerFunc, non-HTTP triggers take a context.Context and a typed payload, and the project layout is a standard Go module. Go build, go test, and go mod tidy just work. package main import ( "fmt" "net/http" "github.com/azure/azure-functions-golang-worker/sdk" "github.com/azure/azure-functions-golang-worker/worker" ) func main() { app := sdk.FunctionApp() app.HTTP("hello", hello, sdk.WithMethods("GET", "POST"), sdk.WithAuth("anonymous"), ) worker.Start(app) } func hello(w http.ResponseWriter, r *http.Request) { name := r.URL.Query().Get("name") if name == "" { name = "world" } fmt.Fprintf(w, "Hello, %s!", name) } Triggers in preview: HTTP, Timer, Service Bus, Event Hubs, Event Grid, Cosmos DB, and Blob Storage. No function.json, no interop shims, no generated metadata to keep in sync. On-demand Sandboxes for Durable Task Scheduler (Private Preview) → Full post Move individual orchestration steps to managed, isolated compute while your orchestrator stays exactly where it is. Declare which activities should run as serverless, point at a container image, and DTS handles provisioning, scaling, and teardown. No infrastructure to manage, no idle costs, no orchestrator changes. Each execution runs in a clean, microVM-backed sandbox with per-activity or per-invocation isolation, ideal for native toolchains (ffmpeg, LibreOffice, Pandoc), CPU-heavy preprocessing (OCR, image work), cross-runtime steps (a Python inference activity called from a .NET orchestrator), sandboxed execution of customer plugins or LLM-generated code, and bursty workloads that can't justify always-on infrastructure. Sign up for On-demand Sandboxes Private Preview Today → Azure Functions Skills for coding agents (Preview) → Full post Bring Azure Functions expertise to your coding agent. Azure Functions Skills equips GitHub Copilot CLI, Claude Code, and Codex with Functions-specific knowledge like trigger and binding patterns, language anti-patterns, runtime versions, and deployment best practices, so your agent gives accurate guidance instead of generic advice. One command installs guided workflows to create, deploy, diagnose, and review Functions apps. The standout is the doctor command: it uses LLM-powered semantic analysis to catch configuration mistakes and code issues like missing error handling, blocking I/O, hardcoded secrets, durable-orchestrator non-determinism, and supply-chain risks before you deploy, available as both a local CLI command and a GitHub Actions pre-deploy gate. Try it now! npx @azure/functions-skills install Built-in Grafana dashboards (Generally available) Every function app now has a single pane of glass for operations with zero setup. A new Grafana dashboards entry in the function app's portal TOC opens a prebuilt dashboard purpose-built for Functions: execution count, success/failure rates, p50/p95/p99 duration, resource utilization, scale activity, and recent errors linked to Application Insights logs all in one view, scoped to your app. It's powered by Azure Monitor managed Grafana, so there's nothing to provision, wire up, or pay extra for. Duplicate and customize it to make it your own, save it to your subscription, and share it with your team. Start using built-in Grafana Dashboards today! TLS/SSL certificate support Flex Consumption (Preview) Azure Functions Flex Consumption now supports TLS/SSL certificates through a new site-scoped certificate model in public preview. Each function app can hold up to 3 private (.pfx) and 3 public (.cer) certificates uploaded directly, imported from Azure Key Vault, or issued as free App Service Managed Certificates to enable custom domains, client-certificate authentication, and mutual TLS scenarios on Flex Consumption. See Configure site-scoped certificates, infrastructure as code instructions, and the cross-plan certificate comparison for details. Rolling Updates for Flex Consumption (Generally Available) Rolling updates are now generally available in the Flex Consumption plan, delivering zero-downtime deployments with a simple configuration change. Instead of forcefully restarting all instances during code or configuration updates, the platform gracefully replaces live instances by draining batches every few seconds while dynamically scaling out the latest version to meet demand. This approach ensures uninterrupted execution and resilient throughput across HTTP, non-HTTP, and Durable workloads - even during intensive scale-out scenarios. Learn more at Site update strategies in Flex Consumption. OS-level dependencies with containers on Flex Consumption (coming soon) Bring your own OS-level dependencies to Flex Consumption without giving up serverless. Package your Functions worker and app code as a container image with a standard Dockerfile (Chromium for Playwright, native toolchains, custom system libraries, whatever your app needs) and run it on the Flex Consumption plan. You get the things that make Flex valuable: dynamic, event-driven scaling across all triggers and the pay-per-execution billing model. This is expected in the next couple of months. Sign up to get early access and updates → How to engage Everything announced this week is being actively shaped by real workloads. We want to hear from you. X (Twitter): http://x.com/azurefunctions Microsoft Q&A: file issues and track progress at https://learn.microsoft.com/en-us/answers/questions/ask/Private Plugins with Azure SRE Agent
SRE's and platform teams are building operational skills specific to their infrastructure: investigation runbooks, compliance checks, cost analysis playbooks, deployment verification procedures. The next step is making that work reusable across every agent in the organization without exposing it publicly. Today, SRE Agent supports plugin marketplaces hosted in private GitHub repositories, including GitHub Enterprise. This is part of the Azure SRE Agent announcements at Build 2026. You can now point SRE Agent at a private repo when adding a marketplace or installing a plugin. Authentication is handled per-marketplace, and supports OAuth, GitHub PATs, and GitHub Apps for GHE tenants. From one agent to an organization’s plugin catalog Most teams start with a single SRE Agent connected to their services. The agent learns their infrastructure, runs their runbooks, and handles their incidents. It works well. Then adoption grows. A second team stands up their own agent. Then a third. Platform engineering wants every agent to run the same compliance checks. Security needs approval hooks enforced consistently. FinOps has cost governance skills that should be standard across the organization. Suddenly the question isn’t “how do I set up my agent,” it’s “how do we share operational knowledge across all of them.” Without a distribution model, teams end up copying skill files between agents manually. A platform team writes a runbook, shares it over email or a wiki link, and each service team pastes it into their agent individually. When the runbook improves, some agents get updated, some don’t. There’s no version tracking, no central catalog, and no way to know which agent is running which version of which skill. Private marketplace support solves this. How Private Plugin marketplace meet enterprise needs A platform team publishes once, every agent installs. Codify best practices as plugins in a private GitHub repo. Service teams add that repo as a marketplace in their agents and install what they need. Compliance checks, cost governance thresholds, incident playbooks, deployment verification procedures all distributed through versioned plugins. Each team retains ownership. Security controls which plugins enforce approval hooks. FinOps locks cost thresholds into parameter values. Platform engineering governs infrastructure investigation patterns. The marketplace is the distribution layer for organizational standards. Versions are pinned, updates are explicit. Each installation locks to the commit at install time. A merged PR upstream does not change any agent’s behavior. Teams promote new versions on their own schedule: validate in dev, promote to staging, then production. Different agents can run different versions simultaneously. Reuse across environments and tools. The same plugin works across dev, staging, and production agents, and can be reused by local coding agents and other services that support plugins. One source of truth, not separate copies per environment. Accessing Private Plugin marketplaces Private repo support adds authentication to the SRE Agent's plugin workflow so your agent can clone and install from repos that require credentials. Authentication is configured once per marketplace. Every plugin within it inherits the credentials. Auth method When to use Setup OAuth github.com repos your agent can already access Uses your existing GitHub connection. One click. Personal access token Private repos in other orgs on github.com Per-marketplace PAT. Scoped to just that marketplace. GitHub App GitHub Enterprise (*.ghe.com) BYO App with private key in Azure Key Vault. Short-lived tokens minted at runtime. Getting started In SRE Agent, navigate to Builder > Plugins, then click Add Marketplace and enter the URL of the private marketplace you want to connect to. Then click Connect to GitHub to complete the OAuth sign-in. Click Add and you will see the plugins available from your connected marketplace. Click on the plugin to install and in the detail view you can browse the skills packaged with the plugin. click Install to install this plugin. You can now see the skills imported from plugins from Capabilities > Skills > Custom Skills The bottom line Private repo support turns the Plugin Marketplace from a public skill catalog into your organization’s internal distribution platform for operational automation. Your team writes the plugins. Your agents install them. Your GitHub permissions control who has access. Try it yourself: create a private repo with a marketplace.json and a few skills, add it as a marketplace in your agent, and install a plugin. Resources SRE Agent documentation — https://aka.ms/sreagent/newdocs SRE Agent overview — https://aka.ms/sreagent/newdocsoverview Plugin Marketplace capability page — https://aka.ms/sreagent/newdocs/capabilities/plugin-marketplace Build 2026 SRE Agent announcements - https://aka.ms/Build26/blog/SREAgentVNet integration for Azure SRE Agent (preview)
For many production systems, the logs, databases, private endpoints, repositories, and runbooks an SRE Agent needs to do its job are behind network boundaries your security team already governs. VNet integration for Azure SRE Agent, now in preview, puts the agent's outbound traffic under those same controls - your virtual network, your NSG rules, your private DNS - so it reaches only what your network allows. The principle is one your security team already applies to every other workload: a component's network access shouldn't depend on the component behaving correctly. Identity governs what the agent can reach. Permissions and hooks shape what it does within reach. The network sits beneath both: it blocks any request to a destination you haven't allowed no matter what the agent decides. Why egress control matters Two reasons. First, the agent reads sensitive things by design. Inspecting logs, code, configuration, and internal systems is the whole point during an incident, which means you have to decide where that data can go. Open egress gives that data a path out of your network - a risk you wouldn't accept for any other production-adjacent workload. Second, it reasons over text it didn't write - logs, issue descriptions, tool output — which is how prompt injection gets in. Handling that is partly model safety, and Azure SRE Agent runs under Microsoft's Responsible AI standard with safety work from OpenAI and Anthropic. Network controls add another layer: an instruction that tries to reach a destination you haven't allowed can't run, because the network blocks it. For example, an agent investigating an outage might query Log Analytics, read deployment configuration, and call an internal runbook - all private resources. With VNet integration, those calls follow the routes, DNS, and firewall rules your workloads already use. A request to an external endpoint you haven't allowed fails at the network boundary. It doesn't depend on the model recognizing the risk and refusing; the network stops it either way. Choose an egress mode Azure SRE Agent has three egress modes, and you don't have to start at the strongest. Unrestricted - all outbound traffic allowed Limited - deny all outbound, allow an explicit list of hosts. Gives you host-level control without setting up a full VNet Azure VNet - outbound traffic goes through a delegated subnet in your network, with your NSG rules and private DNS applied. The recommended mode for production and regulated workloads. How Azure VNet mode works Outbound traffic takes one of two paths, and every call takes exactly one. Your VNet. Everything not placed on the managed path goes through a delegated subnet in your own network, where your NSG rules, private DNS, and firewall all apply. The agent is just another workload on that subnet, so it can reach what the subnet can reach: databases behind private endpoints, internal services, monitoring stores, and key vaults -the parts of production that aren't reachable from the public internet. The resources that matter most during an incident are usually the private ones. If your network connects to on-premises over ExpressRoute or VPN, the agent can reach those systems too, as long as your existing routes and rules allow it. The managed infra path. Some destinations go through Azure SRE Agent's managed infrastructure network instead - platform services the agent needs, plus optional categories you turn on: package registries, code repositories, and remote MCP servers. This path skips your VNet, so your NSG rules and Firewall Policies don't apply to it. Treat it as a deliberate exception, used only where you need it. Why public services start on the managed path Public services are hard to allow by IP address. GitHub, PyPI, npm, NuGet, apt, and the container registries run on large, changing IP ranges, and they don't map to a single Azure service tag. If your NSG filters by IP and port, keeping those lists up to date is constant work, and when a list falls behind, the agent can't pull a package or read a repository - and an investigation stalls on a networking problem that has nothing to do with the incident. Each category has a toggle: package registries (PyPI, npm, NuGet, apt), code repositories (GitHub, GitHub Enterprise, Azure DevOps), remote MCP servers, and a list of additional hostnames. Starting with these on the managed path keeps the agent working reliably without maintaining an IP allowlist. For build-time dependencies, that's usually fine. If you want this traffic inspected too, the next step is name-based (FQDN) egress filtering in your own network. Once your firewall can allow github.com and pypi.org by name, you can move these categories off the managed path and route them through your VNet instead Configure it Two decisions: the subnet, and what (if anything) uses the bypass. Navigate to Settings > Workspace Configuration > Network Choose Azure VNet as the egress mode. Select a subnet that is /27 or larger and delegated to `Microsoft.App/environments`. Decide which categories, if any, use the bypass. Restrict who can change the egress mode and bypass toggles. These settings widen or narrow the agent's reach, so govern them like any production network control. Test the outbound behavior before using the agent with production data. A reasonable setup for most enterprises during preview: use Azure VNet mode, keep package registries and code repositories on the bypass if you need reliable access to them, and route everything else through your VNet. Stricter environments can turn those categories off and rely on their own name-based firewall rules. What it doesn't cover yet VNet integration is in preview, with two limitations to know. It covers outbound traffic only - reaching the agent privately from inside your network isn't part of this preview. And connector traffic still routes over the public internet; the governance and credential isolation in Connectors V2 still apply. Use VNet integration for outbound control of the agent workspace, and combine it with identity, RBAC, tool permissions, hooks, and connector governance for a complete set of controls. Where it fits VNet integration doesn't replace identity, RBAC, tool permissions, or connector governance. It controls where traffic can go. The agent still needs the right identity and permissions to access a resource in the first place. Identity is the foundation: your RBAC assignments decide what the agent can reach. Permissions and hooks shape what it does within reach: allow/ask/deny rules control what runs, and hooks let you inspect or change a tool call before it runs. VNet integration sits underneath, controlling where traffic can go no matter what the agent tries to do. You want the agent to be capable. You also want a boundary that holds whether or not it is. Get started Create an SRE Agent - https://aka.ms/sreagent Documentation - https://aka.ms/sreagent/newdocs Recipes - https://aka.ms/sreagent/recipes Build 2026 Announcement - https://aka.ms/Build26/blog/SREAgentManaged Connectors for SRE Agent (preview)- Govern what your agent can do
Giving an agent access to a tool is the easy part. The harder question is what it's allowed to do with that access. "Can the agent copy a file in OneDrive?" mostly answers itself. "Can it copy any file, to any destination, over one that's already there?" is the one that decides whether the integration has a governance layer. Managed Connectors is built around that second question. It expands the catalog of tools the agent can reach - OneDrive, SharePoint, Google Drive, GitLab, Power BI, Microsoft Security Copilot, with more being added regularly - and pairs it with a governance model that keeps the policy for those tools outside the agent's control. This is part of the Azure SRE Agent announcements at Build 2026 What's new Managed Connectors is the next generation of our connector experience. It significantly expands the catalog of third-party and first-party SaaS integrations available to SRE Agent and surfaces each one to the agent as a curated set of operations through the Model Context Protocol (MCP) - the same standard the agent already uses for every other tool source. Governance: the agent gets capability, you keep control The governance model is the headline of this release, so it's worth being concrete about it. When you add a connector, you walk through a short wizard - Set up connector, Configure tools, Review & Save - and the "Configure tools" step is where the policy is set. Three things make it different from "just wire the API up to the LLM": You choose what's exposed - it isn't automatic. A connector might offer 40+ operations; in the wizard you pick the ones the agent can use. The rest aren't shown to the model, so it can't call them. Parameter policy lives outside the agent. For each selected operation you can mark parameters as user-defined (pinned to a value you specify) or agent-defined (the agent fills it in). On the Microsoft Planner “Create a task” tool, for example, you can choose the group ID from a list of your joined groups – this means that the agent provides the task details but can’t assign it to any arbitrary group, because that isn’t a parameter it sees when invoking the tool. Per-tool approval is built in. Each operation has an Allow/Ask toggle integrated directly into the creation and edit wizards. "Ask" routes the call through the agent runtime human-in-the-loop approval flow before it executes. On that same Microsoft Planner connector, you might leave read-only tools like “List tasks” or "Get plan details” on Allow, but flip “Delete a task” to Ask so a human must confirm before anything is removed. This is enforced on the agent's runtime; it is not a prompt instruction the model can be talked out of following. Credential Isolation No long-lived secrets in the agent. No API keys, no client secrets, no certificates, no OAuth tokens. All service credentials are encrypted at rest and stored outside of the agent’s trust boundary Automatic token refreshed. Once you consent, the internal connector resource keeps your tokens valid. You won't be asked to re-authenticate unless your service itself requires it. You consent once, in your own browser, with your own service. SRE Agent never proxies your password or the sign-in flow. Per-connection authorization. Each connection is bound to the specific SRE Agent instance you set up on and cannot be used by external threat actors. How it fits together All of this is stored and evaluated outside the agent loop. Each configured connector becomes an MCP server that the SRE Agent runtime registers as a tool source, the same standard wire format the agent uses for everything else, so adoption on the model side is trivial. Each layer does one job, and the trust boundary between "what the model decided" and "what was actually sent" is explicit and inspectable: the agent never sees the operations you didn't select, never sees the parameter slots you pinned, and cannot bypass approval on operations you marked Ask. How to try it Open the SRE Agent portal and go to Builder > Connectors. Pick a connector from the catalog with the “Preview” label and go through the creation wizard steps. At the “Set up connector” step, choose how the connector authenticates. Start with “OAuth” if you just want to sign-in and see it working against your own account. At “Configure tools”, select the operations you want to expose, pin any parameters that shouldn't be agent-controlled, and mark sensitive operations as “Ask.” Review & Save. The connector is registered with the runtime and immediately available to your agent. You can enable/disable specific tools or connectors in the “Capabilities” section. Edit connector – after creating the new connector, at any point you can go back and authenticate it with a different account, add or remove operations, update tool parameters and configure approval policies Resources Create new SRE Agent — https://aka.ms/sreagent SRE Agent Documentation — https://aka.ms/sreagent/newdocs SRE Agent recipes — https://aka.ms/sreagent/recipes Build 2026 SRE Agent announcements - https://aka.ms/Build26/blog/SREAgentShaping what Azure SRE Agent does: Tool Permissions and Hooks
When an AI agent runs against production, the first question every security team asks is "What can it do, who decided it could, and what stops it from doing something it should not." Azure SRE Agent reached general availability in March. Since then, teams inside Microsoft and customers running it against real production workloads have asked for the same thing: finer-grained controls over what the agent can do on its own and a clear answer to who governs each call that reaches a tool. Today at Build 2026, we are releasing global tool access policies as one of a set of new governance controls. This post covers how they work. Tool access policies give security and platform teams a single place to define which tools the agent can invoke, under what conditions, and what requires human approval before it runs. Underneath those policies sits the identity the agent runs as the bedrock that every other control layer depends on. It is defense in depth applied to agent behavior: layers of control, each one holding on its own, so that governing the agent is something you can read, audit, and reason about as you scale it across production. Identity is the bedrock: managed identity today, agent identity next Start here, because nothing else matters if you skip it. The identity the SRE Agent runs as, and the Azure RBAC role assignments on that identity, are the most powerful boundary the agent works inside of. If your role assignments do not grant the agent access to a resource, none of the controls below come into play, because the agent cannot reach the resource to begin with. Network rules, tool permissions, hooks, and connector contracts all sit on top of an RBAC story that you write. The features in this post add layers above that floor. They do not replace it. Today the SRE Agent operates as a managed identity, and your RBAC role assignments on that identity govern what it can do. This is the bedrock, and it is the same model your other Azure workloads already use. You assign roles, you scope them, and the agent inherits exactly what you granted and nothing more. Everything that follows assumes the bedrock is in place. With identity settled, the next question is the obvious one: where is the agent allowed to send its traffic? Permissions: govern what the agent does with a tool Identity decides what the agent can reach. Permissions decide what the agent does with the access it has, down to the individual tool. Two levels cover the range: a point-and-click grid for the common cases, and hooks when a decision needs your own code. The grid is the easy mode. Every tool the agent can use, built-in tools along with MCP servers, services, and custom tools, shows up in one searchable list with two switches. On/Off sets whether the tool is available at all; turn it off and the agent cannot use it. Allow/Ask sets what happens when it is on: Allow lets the agent run the tool automatically, Ask requires a human to approve every time, except in Autonomous mode. Select tools in bulk to flip a whole category at once, filter by category or permission, and use the Advanced permissions tab when you want rules that apply at global, per-agent, or per-thread scope instead of tool by tool. Defaults stay put until you touch them, and the engine is fail-closed: if a rule cannot be evaluated, the call is blocked rather than allowed. That covers most of what teams need. Underneath those switches are three rules, allow, ask, and deny, and the Advanced tab is where you set them by scope. Global rules apply to every agent and thread, Agent rules to one custom agent, Thread rules to a single conversation. Deny is the hard one: it blocks the tool outright no matter the run mode, and a deny at a higher scope always wins, so an Allow at thread scope cannot reopen something denied globally. That split is deliberate. A platform team sets the Global guardrails that should never be crossed and the Asks that always need a human, and service teams add their own Allow rules at Agent scope for routine work, without being able to override the guardrails above them. Platform team, Global scope: deny: bash(az * delete *) - never delete, on any agent or thread deny: bash(kubectl delete *) ask: bash(az webapp restart *) - always confirm, even in Autonomous allow: bash(az monitor *) - auto-approve monitoring queries Service team, Agent scope: allow: bash(kubectl get *) - routine read-only work allow: bash(kubectl describe *) Two details make this safe to lean on. Rules match the canonicalized tool invocation rather than the raw text, so enforcement holds no matter how the command was assembled. And fail-closed has a softer edge than a hard stop: a cached last-known-good policy covers transient failures, so a blip in the policy store blocks the call rather than silently widening access. You can find these under Capabilities > Tools missions. The layer worth spending time on is hooks. Allow and Ask answer "should this tool run." Hooks answer "should this specific call run, given exactly what it is about to do." A hook fires before the agent runs a tool and receives the actual call, parameters and all. Your code then decides the outcome and can reshape it: rewrite parameters before they are sent, inject extra context into the pipeline as a user message so the agent reconsiders before its next step, block the call outright, or redirect the agent toward a safer path. Because your code sees the real parameters, the decision can depend on anything you can express in code: which resource the call targets, whether a value falls outside an allowed range, the time of day, the result of an external policy lookup. This is where you write the rule the grid cannot. Two kinds of hook, mixable on the same agent. Command hooks are a script you write; reach for these when code is enough. Prompt hooks put a separate LLM in the loop as a judge that evaluates the call in context; reach for these when the decision needs reasoning rather than a fixed rule. A real example from our own internal test agent: when the agent tries to list files through the shell with ls or dir, a hook blocks the call. The agent absorbs the signal, reconsiders, and reaches for the ListDir tool instead. The hook did not argue with a human. It shaped what happened next. As with the grid, configure nothing and the agent behaves exactly as it does today. Both are additive. Authoring one is a short form. You name the hook, pick the event (Pre Tool Use, so it runs before the call), and set a tool matcher, either picked from the tool menu or written as a regex like (FetchWebpage|SearchMemory) with anchors and lookaheads when you need them, so the hook fires only on the calls you care about. You set a timeout and a fail mode (Block, so a hook that errors or hangs stops the call rather than waving it through), and you write the body in Bash or Python. A command hook reads the call as JSON on stdin, the event name, the tool name, its parameters, and the call id, and answers on stdout. Print nothing and exit zero to allow. Return a block decision with a reason to stop the call, and that reason is what the agent reads back. You can also substitute: run a cheaper or safer version yourself, block the real call, and hand your own output back as the result, so the agent never runs the expensive or risky original. #!/bin/bash input=$(cat) tool=$(echo "$input" | jq -r '.tool_name') # Block one tool, with a reason the agent will read if [ "$tool" = "ExampleToolName" ]; then echo '{"decision":"block","reason":"Blocked ExampleToolName by hook policy."}' exit 0 fi # Otherwise allow: print nothing and exit 0 exit 0 You can find these under Builder > Hooks Each layer holds on its own The layers stack. Identity is the floor: your RBAC assignments decide what the agent can reach at all. Permissions, the grid and hooks together, decide what it does with a tool. You author each layer, each one holds whether or not the layer above it behaves as expected, and all of it configures through the same ARM and Bicep surface your platform team already uses, reproducible the way the rest of your Azure estate is. The upgrade path is additive and non-breaking. Existing agents keep working. Turn on each control when you are ready, in the order your governance requires. There is more coming. We run Azure SRE Agent inside Microsoft on our own production workloads, so we feel the same gaps you do, and the next round is shaped by what we hear from teams running it in production today. Which control is doing the most for you, and which one are you still waiting on? Let us know and thank you! Getting started Create new SRE Agent — https://aka.ms/sreagent SRE Agent Documentation — https://aka.ms/sreagent/newdocs SRE Agent recipes — https://aka.ms/sreagent/recipes Build 2026 Announcement - https://aka.ms/Build26/blog/SREAgent
