Preview features: This article uses generally available Microsoft Agent 365 together with capabilities that are currently in preview, including Microsoft Entra Tenant Governance, multitenant agent management, and the Azure API Management dedicated AI Gateway tier. Preview capabilities are provided under their applicable preview terms and might have limited regional availability or service-level commitments. For more information, see Supplemental Terms of Use for Microsoft Azure Previews.

Why this architecture exists

Enterprises want more people building AI agents, not fewer. Business users understand the processes that should be automated. Makers need low-code tools. Developers need complete control over orchestration, tools, identity, deployment, and runtime behavior.

The difficult part is not creating the first agent.

The difficult part is operating hundreds or thousands of agents safely across business units that may have different Microsoft Entra tenants, different data stores, different regulatory obligations, different budgets, and different levels of autonomy.

A parent organization might want common standards for identity, security, evaluation, observability, and cost while its subsidiaries retain local control of data and runtime operations. In some organizations, those subsidiaries even compete with one another. In that environment, copying all data and agent state into one central tenant would weaken the very boundaries the organization created.

This architecture therefore uses a federated agent factory:

• Centralize standards, deployment patterns, governance views, and operational oversight.
• Keep agent identities, business data, detailed telemetry, and runtime enforcement local to the owning tenant unless there is a documented reason to centralize them.
• Use the Microsoft service that fits each layer instead of assuming one product is the "control plane" for everything.
• Govern both Microsoft-managed agents and custom/pro-code agents, but use different enforcement mechanisms where the runtime model differs.

The result is a common enterprise operating model without collapsing tenant boundaries.

Five architectural principles

1. Centralize governance, not tenant data

The governing tenant should own shared standards, templates, cross-tenant administrative relationships, and consolidated operational views.

Each subsidiary should continue to own:

• its Microsoft Entra identities,
• its production agents,
• its business data,
• its tenant-specific permissions,
• its detailed prompt/response telemetry where required,
• its local audit evidence,
• and its runtime policy enforcement.

This minimizes the chance that a central governance failure becomes a cross-subsidiary data leak or a runtime outage.

2. Give every governed agent a clear identity and owner

AI agents are nonhuman actors. They should not operate through shared secrets or generic service accounts.

Where the platform provides one, use Microsoft Entra Agent ID so that each agent has a first-class identity, sponsor, permissions, sign-in history, and lifecycle.

Agent identities are single-tenant. A multitenant agent identity blueprint can be published to other tenants, where it creates tenant-local agent identities. This is exactly the pattern needed for a federated organization: one security blueprint, many locally owned identities.

3. Treat tools as governed enterprise capabilities

Agents should not receive broad database credentials and unrestricted query access.

Developers should expose narrow, typed capabilities such as:

invoice.lookup invoice.process approval.request order.status customer.lookup case.create sop.search

Those capabilities should be versioned and published through governed APIs or Model Context Protocol (MCP) servers.

This separates responsibilities cleanly:

• Business experts define what the agent is allowed to do.
• Developers implement how tools work.
• Security and platform teams enforce who may call them and under what conditions.

4. Make governance a runtime property

Design-time reviews are necessary but insufficient.

The platform must still check sensitive actions when the agent runs:

• Who is calling?
• Which agent is acting?
• What action is being attempted?
• Which resource is targeted?
• What is the data classification?
• Which policy version applies?
• Is a human approval required?
• Is the action allowed right now?

This requires a chain of runtime enforcement points, not a single "AI policy" checkbox.

5. Observe quality, security, reliability, and value together

A production agent is not healthy merely because the endpoint returns HTTP 200.

The organization needs to know:

• Did the agent complete the business task?
• Did it choose the correct tool?
• Did it follow the SOP?
• Did it expose restricted data?
• Did the model or tool fail?
• What did the invocation cost?
• How much human work did the agent avoid?
• Did quality regress after a new release?

The architecture therefore treats observability and evaluation as part of the runtime operating model, not as optional debugging tools.

Architecture

The platform has four parts: authoring surfaces, a control plane, runtime enforcement, and operations. People author agents across three surfaces, from no-code to pro-code. One control plane, Microsoft Agent 365, provides the central inventory and governance view for supported registered agents and connected platforms, and depending on agent type, integration, licensing, and discovery coverage it can also surface unmanaged or shadow-agent activity for investigation and onboarding. Platform-specific runtime controls enforce governance as agents operate, and an operations plane provides visibility. The following diagram shows the platform at a glance.

The detailed architecture shows the same platform as three planes over a shared data foundation, with the shared services and the federated deployment. Some services, such as Microsoft Purview, appear in more than one plane because a plane shows where a control is configured and where its effect is enforced or observed, not a single owning product. The customer-controlled gateway applies only to pro-code paths that are explicitly configured and network-restricted to use it; Microsoft-managed agent runtimes use their native governance controls, and custom authorization can still apply where those agents call customer-controlled tools or APIs.

Workflow

The reference implementation uses the following workflow, and the numbers match the numbered markers on the detailed diagram. Each marker sits on the capability that performs the step, so a step can appear in the plane that hosts its capability rather than in strict left-to-right order. For example, evaluation (step 5) is a design-time release gate but runs on the operations-plane observability capability. Steps 1 through 6 define, govern, and validate the agent before release. Steps 7 through 10 enforce controls on every action at runtime. Steps 11 through 14 observe, measure, deploy, and federate.

1. Catalog governed data and knowledge. A business owner registers the approved data sources and knowledge that an agent can use in a governed catalog. Each entry is versioned, owned, and classified. The catalog keeps bidirectional links between a data source and the agents that use it, so a later change to a source flags the affected agents for review.

2. Author the specification. A business user or maker uses a no-code or low-code authoring studio to define the agent from a template. The specification declares intent, typed inputs and outputs with classification labels, permitted tools, permitted data sources, escalation and checkpoint rules, the allowed collaboration graph, a budget, and a value baseline for ROI. No code is required to define behavior.

3. Register the agent and capability. The specification registers in an agent and capability registry. In this architecture, the platform's registration workflow requires a valid approved specification and governed data references before an agent can promote to production. Where the platform provides an agent identity, registration associates the agent with a scoped identity.

4. Build tools with typed contracts. Developers implement tools behind typed, versioned Model Context Protocol (MCP) contracts and register them in a capability catalog. Developers supply tools, not agent behavior. Each tool has least-privilege scope, so no single tool has broad, unrestricted access.

5. Evaluate before release. An evaluation and simulation stage runs the agent against golden test sets, runs it in shadow mode, and checks for behavioral drift. This stage is a release toll-gate. An agent that regresses or that doesn't meet its approved specification doesn't promote.

6. Promote through governance. A stage-gated governance workflow moves the capability through review, approval, and promotion. Higher data classification adds more gates. Every approval is recorded as immutable evidence, and production is pinned to an exact immutable artifact version so that rollback is a pointer change.

7. Route custom-agent invocations through the gateway. For pro-code agents on Microsoft Foundry, the runtime calls a routing and orchestration gateway that's the enforcement point for that path. The gateway performs a policy pre-check, authenticates the caller, enforces token and rate limits, applies content safety, and routes to the model. The platform makes the gateway mandatory by configuring each Foundry agent's model and tool endpoints to target the gateway and blocking direct network egress, so an agent can't bypass the enforcement point. Agents built in Copilot Studio or Microsoft 365 Copilot run on Microsoft-managed runtime and are governed by the control plane (Agent 365 and Microsoft Purview, plus a Microsoft Entra Agent ID where the platform provides one) rather than this gateway.

8. Enforce policy at runtime. For the customer-controlled path, the architecture requires every in-scope sensitive action to traverse a policy enforcement point that calls the policy decision point. An in-scope sensitive action is one that the specification or policy designates as consequential, such as writing to a system of record, reaching higher-classification data, or spending budget. In this architecture, the decision point sits on the mandatory customer-controlled execution path. During a brief control-plane outage, the enforcer evaluates against cached policy so that transient unreachability doesn't block legitimate actions; cached decisions expire after a defined time-to-live, and the highest-risk actions are excluded from caching and always require a fresh decision. A request that still can't obtain an applicable decision fails closed, and every denial produces an audit event.

9. Reach data only through governed tools. The architecture requires production agents to reach governed external systems through approved MCP tools or equivalent governed interfaces. A classification-aware data access layer compares the caller's clearance to the data classification before it returns results, so the access layer prevents data from being returned to a caller or destination that isn't authorized for the data's classification. Source-system controls remain authoritative, and the tool returns governed results rather than bulk extracts.

10. Apply guardrails and human checkpoints. A guardrails engine validates input for prompt-injection attempts, authorizes tool calls, and checks output for sensitive-data exposure and format compliance. Human-in-the-loop checkpoints that the spec declares pause high-risk actions for approval.

11. Record evidence. Each invocation emits OpenTelemetry-compatible traces with correlation IDs and writes tamper-evident records to an immutable audit store. Telemetry captures cost and latency. Classification-aware redaction keeps sensitive content out of the central views.

12. Measure value. A business value and ROI capability quantifies value from execution telemetry against a documented manual baseline, attributes value per capability, rolls up to the business-unit level, and forecasts trends.

13. Deploy and roll back safely. A deployment and rollback capability pins production to an exact immutable artifact version, so rollback is a pointer change to the prior artifact. Foundry hosted agents serve one active version at a time; to run blue-green or canary releases, implement weighted routing across separate agent endpoints through the gateway rather than relying on native traffic splitting. Automated triggers include evaluation regression, a policy-violation spike, and an error-rate breach of the service-level agreement.

14. Deploy build-once across the federation. An infrastructure-as-code factory stamps the identical customer-controlled governance and enforcement infrastructure into each participating tenant. The Microsoft-managed services (Agent 365, Copilot Studio, Agent Builder, and Foundry-hosted runtime) are Microsoft-managed platform capabilities that the factory configures rather than deploys. A governing tenant receives delegated operational and identity views through consented, least-privileged relationships. In this architecture, agents, business data, detailed telemetry, and audit records remain in their source tenants; the governing tenant receives delegated administrative access and aggregated operational views rather than a replicated central data store.

Components

The components are grouped by the plane they serve. Most capabilities use Microsoft or Azure services. Where no single Microsoft product provides the required capability, the architecture composes multiple services or uses a standard open-source component hosted on Azure.

Data foundation and control plane

• Microsoft Dataverse and SharePoint in Microsoft 365 provide governed, versioned stores. In this architecture, either one holds the data and knowledge catalog with ownership, classification, approval workflow, and links to the agents that use each source.

• Azure AI Search provides retrieval over enterprise content. In this architecture, it grounds agents in governed knowledge so that answers come from approved sources, and indexed permission and classification metadata, together with application-supplied security filters, restrict retrieval to content the caller is authorized to access.

• Agent Builder in Microsoft 365 Copilot builds declarative agents. In this architecture, it's the no-code authoring surface for business users, and declarative agents inherit Microsoft 365 security and compliance controls.

• Microsoft Copilot Studio is a low-code studio for building and managing agents. In this architecture, it's the low-code authoring surface for makers, and an agent built here participates in the same governance model through the Microsoft-managed runtime.

• Microsoft Entra Agent ID gives each agent a first-class identity in Microsoft Entra ID. An agent identity is a specialized service principal created from an agent identity blueprint. The agent identity doesn't hold credentials itself; the blueprint authenticates and acquires tokens on its behalf. In this architecture, the registry associates each registered agent with a scoped agent identity that has least-privilege permissions, conditional access, sign-in logs, and lifecycle controls. Agent identities are tenant-local, and for a federated organization a multitenant blueprint creates a corresponding identity in each business-unit tenant.

• Agent 365 is the control plane for agents across the Microsoft 365 admin center, Microsoft Entra, and Microsoft Purview. In this architecture, it provides the authoritative agent inventory and governance view, and it shows each supported agent's owner, permissions, activity, risk state, and certification. It governs supported agents whatever surface built them, including agents that carry a Microsoft Entra Agent ID and Agent Builder agents that don't, and depending on agent type, integration, licensing, and discovery coverage it surfaces unmanaged ones as shadow agents for investigation and onboarding. A platform-owned capability registry, implemented with Microsoft Dataverse or SharePoint and integrated with Agent 365, stores the approved specification, governed data references, typed tool contracts, evaluation evidence, promotion state, and ROI baseline; those are platform extensions rather than native Agent 365 features. Microsoft Agent 365 is generally available and licensed per user. It is included with Microsoft 365 E7 and is also available as a standalone subscription for eligible Microsoft 365 plans. Licensing and prerequisite requirements vary by capability.

• Azure API Center inventories APIs, and its Model Context Protocol support catalogs agent tools. In this architecture, it's the capability catalog that registers vetted tools with typed contracts and classification-aware visibility.

• Azure Container Registry is an Open Container Initiative-compliant registry. In this architecture, it's the immutable, content-addressable artifact repository for tool and runtime images, so production pins to exact version hashes.

• Azure Logic Apps automates workflows across services with connectors and approval steps. In this architecture, it orchestrates the stage-gated governance workflow that moves a capability through review, approval, and promotion, and the workflow writes approval evidence and release metadata to the platform's immutable evidence store at each gate.

• Azure Policy evaluates and enforces resource configuration standards. In this architecture, it governs how the platform infrastructure is built across every tenant, such as approved regions, encryption, private networking, required diagnostics, and required tags, and business units can add more restrictive controls. Azure Policy governs resource configuration. It's distinct from the runtime policy decision point, which authorizes individual agent actions.

• A policy decision point authorizes individual agent actions from declarative, version-controlled rules. In this architecture, it evaluates a hierarchical policy namespace in which the enterprise level is non-overridable and each lower level (business unit, team, agent) can only add restrictions. There's no single Microsoft product for per-action agent authorization, so this component uses a declarative policy-as-code engine such as Open Policy Agent, which runs as a container on Azure compute and returns an allow-or-deny decision on every sensitive call.

Execution plane

• Microsoft Foundry is a platform for building and running AI agents, models, and tools with built-in identity, role-based access control, content filtering, and Azure Policy support. In this architecture, it hosts agents and provides the per-invocation agent runtime with isolation and resource limits.

• Azure API Management provides AI gateway capabilities for language model APIs, agents, and tools. In this architecture, it's the routing and orchestration gateway and the runtime enforcement point for the customer-controlled path, where pro-code agents on Microsoft Foundry run. It authenticates callers, enforces token and rate limits, applies content safety, routes to models, and governs tool access as the primary entry point for that path. These AI gateway capabilities extend the existing API Management gateway; some newer capabilities, and the dedicated AI Gateway tier, are in preview. Agents built in Copilot Studio and Microsoft 365 Copilot run on Microsoft-managed runtime and are governed by Agent 365 and Microsoft Purview, plus a Microsoft Entra Agent ID where the platform provides one, instead.

• Model Context Protocol tools in Azure API Management expose governed tools to agents. In this architecture, the platform routes agent access to systems through governed MCP tools, and the gateway governs them. Each tool exposes one narrow, typed capability rather than open query access.

• Azure Container Apps runs containerized microservices without managing the underlying infrastructure. In this architecture, it hosts custom MCP tools and the policy decision point in each tenant, using consumption-based scaling for tool hosts and, for the policy decision point, minimum replicas and scaling behavior chosen for latency and availability rather than scale-to-zero.

• Azure AI Content Safety provides harmful-content detection and supported prompt-attack detection in text and images. In this architecture, the gateway or guardrails service invokes the configured safety checks for applicable prompts and responses, which is one layer of the guardrails engine.

• Azure OpenAI in Foundry Models provides the language models that agents call. In this architecture, the gateway fronts the model so that token limits and policy apply to every request.

• Microsoft Purview provides data security, governance, and compliance, including classification, sensitivity labels, data loss prevention, insider risk management, and audit. In this architecture, it classifies and labels supported source data and applies applicable data-security and compliance controls, and a custom classification-aware access layer consumes that approved classification metadata and combines it with source-system permissions and policy rules before returning data. Its data security and compliance protections for AI extend these controls to agent prompts and responses.

• Azure Key Vault stores and manages secrets, keys, and certificates. In this architecture, agents and tools authenticate primarily with managed identities and short-lived Microsoft Entra tokens, so no sensitive value lives in code; Key Vault holds the secrets, keys, and certificates for cases that still require secret-based authentication. An enterprise can integrate an external vault where one is already the standard.

Operations plane

• Azure Monitor provides metrics, logs, alerts, and workbooks. In this architecture, each tenant keeps its own telemetry, and operators read activity, cost, latency, and posture through cross-workspace queries and workbooks without copying data to a central workspace.

• Azure Blob Storage configured with an appropriate immutable, write-once, read-many (WORM) retention policy provides the audit evidence store. In this architecture, it holds decision records and run receipts traceable to a specific artifact version as tamper-evident evidence.

• Foundry observability provides evaluation, monitoring, and tracing for agents. In this architecture, evaluations score agent quality and safety before release and in shadow mode, and the signals gate promotion and feed the central dashboards.

• Azure Managed Grafana provides shared operational dashboards over authorized data sources. In this architecture, it presents fleet-wide operational and ROI views for the governing tenant.

• Azure Event Hubs is a highly scalable event-streaming service that preserves ordering within a partition. In this architecture, it's the asynchronous backbone for event-driven agent triggers, collaboration messages, and telemetry streaming.

Shared services and federation

• Microsoft Entra ID is a cloud-based identity and access management service. In this architecture, it provides unified identity for people, applications, workload identities, and agents, and it's the boundary that keeps each business unit autonomous.

• Microsoft Entra multitenant organizations lets an organization operate several tenants as one federated organization. In this architecture, it's the identity foundation for treating acquired tenants as one enterprise.

• Microsoft Entra Tenant Governance (preview) provides consented, least-privileged administrative relationships between a governing tenant and its governed tenants, using granular delegated administration (GDAP). In this architecture, it grants the governing tenant scoped roles to administer agent identities without holding broad tenant administrator rights.

• Azure Lighthouse delegates Azure resource management across Microsoft Entra tenants. In this architecture, it grants the governing tenant read-only visibility into selected Azure scopes through the Reader and Monitoring Reader roles.

• Terraform on Azure with Azure Verified Modules provides the infrastructure-as-code factory. In this architecture, one versioned definition stamps the identical customer-controlled governance and enforcement infrastructure into each tenant, so a change to the definition changes every future deployment. Terraform provisions the Azure resources and configuration, such as the gateway, policy engine, tool hosts, and telemetry; it doesn't deploy the Microsoft-managed services (Agent 365, Copilot Studio, Agent Builder, and Foundry-hosted runtime), which are Microsoft-managed platform capabilities. Where applicable, Azure Verified Modules provide reusable, Microsoft-maintained baselines for supported Azure resources, and the platform supplements them with organization-specific policy, security, networking, observability, and configuration requirements; Terraform also reaches non-Azure providers, which suits a multicloud estate. This factory pattern uses Terraform and Azure Verified Modules and can adopt the Azure AI Gateway Landing Zone accelerator for the gateway.

Scenario details

A governed agent platform addresses a specific tension. Business users and makers, not only developers, understand the work worth automating, but an enterprise can't let arbitrary agents reach data and take actions without governance. This tension grows across the multiple tenants that many enterprises operate. The platform resolves the tension by separating three concerns and enforcing the separation in the platform rather than in a review process.

• Business users and makers define what an agent does. They author a specification that references approved, classified data sources. They select permitted tools and data domains from a catalog, and they declare escalation and checkpoint rules.
• Developers define how tools work. They build typed, versioned tool contracts and register them. They don't define agent behavior.
• Security and platform enforce both. Security authors the classification taxonomy and policy rules. The platform enforces those rules at runtime.

Assumptions

How completely the control plane governs each agent depends on these conditions being in place:

• Agents have a platform-issued identity where the platform provides one. Newly created agents built with Microsoft Copilot Studio and custom agents hosted on Microsoft Foundry receive a Microsoft Entra Agent ID. Agent Builder agents in Microsoft 365 Copilot don't currently use an Entra Agent ID, but Agent 365 still discovers and governs them. An agent identity is a specialized, tenant-local service principal; the agent identity blueprint holds the credentials and acquires tokens on the identity's behalf. An agent that discovery surfaces but that isn't brought under approved management appears as an unmanaged or shadow agent rather than a governed entry; an agent outside available discovery coverage might remain undetected.
• Each production agent is registered and has an owner. Registration brings the agent into the platform's approved production lifecycle and associates it with ownership, governance metadata, and applicable controls. Agent 365 can also discover agents that haven't completed this approved registration workflow and surface them for governance.
• The tenant is licensed and enrolled. Microsoft Agent 365 requires per-user Agent 365 licensing, which the tenant has assigned to the relevant users. In a federated organization, each business-unit tenant is enrolled in the registry, and central administration uses a Microsoft Entra Tenant Governance (preview) relationship.
• Several platform dependencies are in preview. Microsoft Entra Tenant Governance, multitenant agent management in the Microsoft 365 admin center, and the Azure API Management dedicated AI Gateway tier are in preview at the time of writing. The AI Gateway tier has no service-level agreement and is available in limited regions. Confirm current status, service-level agreements, and regional availability before you depend on these capabilities in production.
• Cross-tenant governance uses multitenant blueprints. Because an agent identity receives tokens only in the tenant where it's created, a federated organization publishes multitenant agent identity blueprints that create tenant-local identities, and the governing tenant administers them through consented, least-privileged relationships rather than a central copy.

Potential use cases

• A business operations team in retail or distribution automates documented procedures, such as order status, warranty returns, or pricing lookups, with agents that can't exceed the procedure's scope.
• A parent company in manufacturing or consumer goods lets independently operated subsidiaries build their own agents while it keeps consistent, central oversight of posture, cost, and evaluation results.
• A regulated organization in finance, healthcare, or government needs every agent action traced to a policy set and an artifact version, with tamper-evident audit evidence held under local custody.
• A platform team in a large enterprise industrializes agent delivery, so business experts self-serve within guardrails instead of filing tickets for a central team to build each agent.
• An organization in energy or telecommunications with a multicloud data estate lets agents interact with data where it already resides, without moving it into a central store.

When not to use this pattern

• A single team runs a handful of agents in one tenant, with no federation, delegation, or cross-business-unit oversight requirement. The control plane and delegated-governance machinery add overhead that a small, single-owner deployment doesn't need.
• Agents don't reach sensitive or classified data and don't take consequential actions, so runtime policy enforcement and classification-aware data access add cost without reducing meaningful risk.
• Orchestration is fully deterministic and hard-coded, with no business-user or maker authoring, so the no-code and low-code surfaces and the specification-driven registry provide little value.
• Data-residency or regulatory rules require a single, centrally controlled tenant. Use the single-tenant form of this pattern and skip the cross-tenant federation.

Data-grounded, spec-driven design

Every agent is grounded in governed data and a reviewed specification, which the platform's registration workflow enforces. This constraint delivers several benefits at once. It gives each agent a documented justification. It bounds each agent's scope to the data sources and actions that its specification approves, which prevents scope creep. It inherits the classification and compliance context of the data it uses. It ties change management to the data catalog, so a change to a source flags the agents to review. It also makes coverage visible, because the catalog shows which data is in use, by which agents, and at what classification.

Authoring across no-code, low-code, and pro-code

People build agents in the surface that fits them, and the platform applies one governance model with platform-specific enforcement paths and centralized visibility. Business users build no-code declarative agents with Agent Builder in Microsoft 365 Copilot. Makers build low-code agents with Microsoft Copilot Studio. Developers build pro-code agents with Microsoft Foundry. The architecture requires each production agent to be discoverable and governed through Agent 365, with a registry entry, and it constrains enterprise data and tool access to approved governed paths. The authoring surface changes, and the enforcement mechanism differs per surface, but the governance objectives, the audit trail, and the visibility stay consistent.

Governance as a runtime property

The platform enforces governance while an agent runs, not only when a human reviews a design. A runtime policy enforcer calls a policy decision point for every sensitive action on the customer-controlled path. The decision point sits on the mandatory execution path for that lane, and a request that can't obtain a decision fails closed. This split of decision from enforcement lets security change rules without touching the enforcement plumbing, and it lets one decision service serve many enforcement points. The enforcement points form a defense-in-depth chain: the gateway checks identity and request validity, tool invocation checks permission and classification, data access checks clearance and domain boundaries, collaboration checks the allowed call graph, output emission checks for sensitive-data exposure, and checkpoints pause for human review. Each check has a defined failure mode, and each denial generates an immutable audit record.

The policy decision point fills a specific gap. Without it, authorization falls back to controls that decide at the identity, content, or data level rather than per action with full context. Microsoft Entra ID with Conditional Access authorizes at token time, and Continuous Access Evaluation can revoke a session, but only on identity and security events. Azure API Management enforces rate and token limits. Azure AI Content Safety screens harmful content. Microsoft Purview applies classification and data loss prevention. These are real controls, but none of them evaluate whether a specific action is allowed at the moment it's attempted, given the caller, the target, the data classification, and the current context. Azure Policy governs resource configuration, not runtime agent decisions. Microsoft doesn't currently ship a first-party engine for per-action agent authorization, so the platform externalizes that decision as policy-as-code. Without a decision point, this authorization logic tends to be hardcoded into each agent and tool, where it becomes scattered, inconsistent, hard to audit, and not centrally fail-closed.

The decision point governs the customer-controlled, pro-code path. Microsoft-managed agents in Copilot Studio and Microsoft 365 Copilot don't call it for their model reasoning, because that runtime isn't a point where you can insert a custom decision service. Those agents still reach governed tools and data through the same enforcement points, so you can authorize their tool actions at the tool boundary, but their internal reasoning is governed by the managed runtime's built-in controls. Removing the decision point therefore weakens per-action authorization mainly for custom, pro-code agents. The managed runtime never applied that layer to its reasoning, which is a limitation inherent to a software-as-a-service runtime rather than a control that you add and then remove.

Make registration mandatory for governed enterprise access

The platform makes registration the only workable path by combining preventive gates, detective controls, and a reconciliation loop, rather than relying on any single check.

Within the boundary this architecture controls, preventive gates make an unregistered agent unable to reach governed enterprise resources:

• Identity is the choke point. Where the platform issues one, each agent runs under a Microsoft Entra Agent ID from an approved blueprint, and conditional access applies to that identity; agents on managed surfaces that don't issue an Agent ID act with the signed-in user's delegated permissions instead.
• Credentials are centrally managed. Approved production endpoints authorize only identities that are mapped to an approved registry entry. Long-lived personal keys are prohibited, managed identities and short-lived tokens are preferred, and exceptions are managed through the vault and approval process.
• Creation surfaces are governed. Managed environments and data loss prevention policies constrain where and by whom agents are authored in Copilot Studio and Power Platform, role-based access control constrains Microsoft Foundry, and ungoverned surfaces are disabled.
• The runtime rejects unknown callers. Gateway policy allows model and tool access only for identities associated with approved registry entries, and governed tools require a registered identity, so an unregistered agent has no route to a model, a tool, or data.
• Promotion requires registration. A capability can't promote to production without a registry entry, an owner, an approved specification, and a passing evaluation, enforced as policy-as-code in the pipeline and by Azure Policy on the underlying resources.
• Third-party agents come from an approved catalog. Only vetted partner agents deploy from the catalog, and unsanctioned agent services are blocked at network egress.

Detective controls find what the gates miss. Microsoft Agent 365 shadow-agent detection, Microsoft Entra workload-identity discovery, Microsoft Purview data security posture management for AI, and Microsoft Defender surface agents and AI usage that aren't in the registry.

A reconciliation loop closes the gap. The platform inventories every creation surface, compares it against the registry, and quarantines, alerts on, or assigns an owner to anything unregistered, unowned, or unmapped. Every agent has an accountable owner, periodic access reviews recertify it, and unowned or unused agents expire automatically.

Within the managed Microsoft identity, Azure, Microsoft 365, endpoint, and network boundary covered by this architecture, production access to approved corporate models, tools, and data requires a registered identity or supported managed-agent context. Agents outside that boundary, such as an unsanctioned software-as-a-service agent or code that uses a personal model key, require separate endpoint, network, SaaS, and data-security controls and might not be fully discoverable.

Contract-first integration and immutable versioning

Agents reach tools and other agents only through typed, versioned contracts. Tool access uses MCP, and agent-to-agent collaboration is mediated through the gateway with a declared call graph and correlation IDs, so there's no direct, unaudited agent-to-agent path. Every spec, policy, prompt, and contract is versioned and immutable once released. Production pins to exact version hashes, and rollback is a pointer change to a prior immutable artifact rather than a redeployment.

Federated hub-and-spoke deployment

The platform deploys build-once into a hub-and-spoke organization. The governing tenant holds the factory (the infrastructure-as-code definition and pipeline) and the shared oversight surfaces. Each business unit runs its own copy of the governed runtime in its own tenant. Only delegated views and delegated administration cross the tenant boundary. Azure Lighthouse and Microsoft Entra Tenant Governance address different layers: Lighthouse delegates Azure resource management, while Tenant Governance delegates Microsoft Entra and supported Microsoft 365 administration. Use both together rather than treating them as interchangeable.

Considerations

These considerations implement the pillars of the Azure Well-Architected Framework, which is a set of guiding tenets that you can use to improve the quality of a workload. For more information, see Well-Architected Framework.

Reliability

Reliability helps ensure that your application can meet the commitments that you make to your customers. For more information, see Design review checklist for Reliability.

• Keep runtime enforcement local to each tenant so that a loss of connectivity to the governing tenant doesn't create an authorization bypass. Use cached policy to ride out brief control-plane outages, and fail closed when no applicable decision is available.
• Treat the central dashboards as an operational view, not as a runtime dependency of any agent.
• Use immutable artifacts and pointer-based rollback so that a promotion problem reverts quickly, and wire automated rollback triggers to evaluation regression, policy-violation spikes, and error-rate breaches.
• Monitor delegation health, cross-workspace query failures, agent identity health, and missing telemetry as separate signals.

Security

Security provides assurances against deliberate attacks and the misuse of your valuable data and systems. For more information, see Design review checklist for Security.

• Enforce least privilege everywhere. Scope every agent, tool, and data access to the minimum required, and prefer managed identities and short-lived Microsoft Entra tokens over long-lived secrets. Store any required secrets, keys, or certificates in a vault.
• Give each agent a governed identity. Use Microsoft Entra Agent ID where the platform provides one, require an owner for every agent, review agent permissions and risk, and retire unused or unowned agents.
• Keep the data access path classification-aware so that data isn't returned to a caller or destination that isn't authorized for the data's classification, and keep source-system permissions authoritative.
• Generate an immutable audit record for every policy decision, and retain tamper-evident evidence according to your regulatory requirements.
• Keep source prompts, responses, audit records, and business data in the owning tenant unless a documented requirement justifies replication.
• Screen prompts and responses with content safety and prompt-injection detection, and validate output for sensitive-data exposure before an agent emits it.

Cost Optimization

Cost Optimization focuses on ways to reduce unnecessary expenses and improve operational efficiencies. For more information, see Design review checklist for Cost Optimization.

• Put token and rate limits, a per-spec budget, and a cost circuit breaker at the gateway so that model spend can't run away, and choose the model tier per capability.
• Measure ROI from a documented manual baseline so that each automated capability shows value against a real cost, not an estimate.
• Query tenant-local telemetry on demand when retention, data residency, and query volume make central ingestion unnecessary, and return aggregates rather than full content for operational views.
• Use consumption-based scaling for tool hosts; for the policy decision point, select minimum replicas and scaling behavior based on latency, availability, and outage requirements, and scale to zero only where cold-start latency and temporary unavailability are acceptable. Estimate the cost of gateways, telemetry retention, dashboards, and alerts for the number of tenants.
• Account for per-user Agent 365 licensing. Agent 365 is licensed per user, so include that recurring subscription cost in the platform's total cost of ownership alongside Azure consumption.

Operational Excellence

Operational Excellence covers the operations processes that deploy an application and keep it running in production. For more information, see Design review checklist for Operational Excellence.

• Deploy the runtime through versioned infrastructure as code, and allow tenant-specific parameters without creating divergent control implementations. Use published modules, such as Azure Verified Modules, so that every deployment meets the same baseline.
• Gate promotion on evaluation, and keep golden test sets, shadow-mode results, and drift detection as first-class release signals.
• Define an onboarding contract for each tenant that identifies delegation scopes, roles, telemetry tables, data owners, retention, and revocation steps. Test offboarding so that revoking a relationship removes central access without interrupting the runtime.
• Track coverage separately for the data catalog, identity signals, Azure telemetry, runtime controls, and data governance, because a tenant might complete one before another.

Performance Efficiency

Performance Efficiency refers to your workload's ability to scale to meet user demands efficiently. For more information, see Design review checklist for Performance Efficiency.

• Keep latency-sensitive policy evaluation and data access local to the agent runtime, and keep the guardrails budget within the platform's latency target.
• Cache policy decisions only when they're bound to the full decision context, including subject or agent identity, action, resource, data classification, policy version, and expiration, and honor revocation. Don't serve cached allow decisions for privilege elevation, destructive actions, high-risk data, or actions that require human approval. Caching stable decisions keeps agents working during brief decision-service outages, within the cache's time-to-live.
• Filter cross-workspace queries at the source, and return aggregates when operators don't need event-level data.
• Partition dashboards by time range and tenant to avoid unbounded fan-out as the number of tenants grows.

Contributors

Microsoft maintains this article. The following contributors wrote this article.

Principal authors:

• Rebekah Midkiff | Senior Cloud Solution Architect
• Gaurav Bhardwaj | Senior Cloud Solution Architect

Other contributors:

• Tyler Durham | Director, Cloud Solution Architecture
• Jaseem Hamsa | Principal Cloud Solution Architect
• Eric LaValley | Senior Cloud Solution Architect
• Dave Newman | Cloud Solution Architect

To see nonpublic LinkedIn profiles, sign in to LinkedIn.

Next steps

• What is Microsoft Foundry?
• Microsoft Agent 365 overview
• AI gateway capabilities in Azure API Management

Related resources

• Architect multitenant solutions on Azure
• Governance approaches for multitenant solutions
• Baseline OpenAI end-to-end chat reference architecture

We are excited to announce the general availability (GA) of network security perimeter metrics, a capability that helps administrators monitor network access patterns, understand the impact of the access rules, and identify unexpected traffic behaviour across protected resources. These metrics are available through Azure Monitor and can be used to create dashboards, alerts, and operational monitoring experiences.

Why use network security perimeter metrics?

Network security perimeter metrics capture access requests evaluated by the data plane and provide visibility into network activity associated with the perimeter-protected resources. Metrics enable monitoring scenarios such as:

• Tracking approved and denied access requests.
• Monitoring inbound and outbound access activity.
• Understanding traffic patterns across protected resources, profiles, access modes and access rule versions.
• Detecting unexpected access attempts.
• Validating the impact of access rules’ changes.
• Establishing a baseline before moving a perimeter from Transition mode to Enforced mode.

Network security perimeter metrics render aggregated time-series data that is optimized for monitoring, alerting, and trend analysis.

Accessing network security perimeter metrics

Network security perimeter metrics are available through Azure Monitor.

1. In the Azure portal, navigate to your network security perimeter resource.
2. Select Metrics under the Monitoring section.
3. ‘Add Metric’
4. Choose the ‘NSP access metrics’ namespace.
5. Select a metric and configure filters, splitting as needed.
6. Use Azure Monitor features to build charts, dashboards, workbooks, and metric alerts.
7. Multiple charts may be created for different metrics that are intended to be monitored.

Regular Azure Monitor features like drilling into the logs, saving the chart as a dashboard or exporting it to a workbook can also be performed.

Metrics vs diagnostic logs

While metrics and diagnostic logs are complementary monitoring tools, metrics provide a high-level operational view and support alerting, while diagnostic logs provide detailed event data for troubleshooting and investigation. Table below gives a high-level differentiation view of one over the other.

Reach-out to mailto:nsppmvteam@microsoft.com for any questions.

We have been evolving Azure Functions from the bottom up: first the infrastructure with Flex Consumption, then the way you write an app, and now the tools you use to build it.

We're introducing a new developer experience for event-driven apps: the Azure Functions Hosted Skills canvas in the GitHub Copilot app. Your Function App, plain-English instructions, trigger controls, and live logs sit beside your conversation. From choosing an event to reading the result, the development loop stays in one window, with Copilot there when you need a hand.

Let's walk through a daily digest for the Azure Functions host repository on GitHub.

Start in the canvas

Open Azure Functions Hosted Skills and choose Local Function App. Use the generated daily repository digest starter for this walkthrough. The app's source lives in your repo or worktree; you do not need an Azure deployment to test it locally.

Choose the event, then the instructions

First pick the event that starts the work. For this daily digest, choose Timer and set its schedule. HTTP or Queue are other options when a request or message should start the task.

Then use or edit Skill instructions. A hosted skill is a set of instructions for an AI task, written in a Markdown .agent.md file. They describe what the app should do when the event arrives. Here, we ask the app to inspect recent repository activity and write a digest with links to the evidence.

With the Functions host running, the runtime listens for the configured event and starts the skill automatically. You do not write a polling loop. Hosted Skills is in preview.

Invoke and read the result

Click Invoke Trigger to run the hosted skill now, without waiting for the next scheduled event. You can change the model or adjust Parameters to try another repository or reporting window.

Click Invoke Trigger to run the hosted skill now, without waiting for its next scheduled event.

That runs the hosted skill. It uses your signed-in GitHub identity to make OAuth-authenticated calls to the GitHub MCP server for issues, pull requests, and workflow activity. The model follows the skill's instructions to reason over that evidence and write the digest.

The starter also uses middleware to trim large tool responses before they reach the model. This run reduced about 181 KB of GitHub results to 2.6 KB.

Read the output in Agent digest and the run status in Trigger activity. The instructions ask for evidence links and a clear note when access or data is missing, rather than made-up activity.

If the result needs work, the canvas gives you the evidence to debug it. The instructions and input stay visible, while Trigger activity, Commands, and the local Functions host log show what ran, when it ran, and any errors. You can check what happened against your instructions, see where the run went wrong, and either debug it yourself or give the coding agent the same inputs, commands, and error messages to work from.

The event selector, model picker, logs, and editor handoff run directly in code. They do not need another model call to interpret a choice you already made. Those routine controls are fast and deterministic; the hosted skill's AI-generated response can still vary.

Copilot stays available to help with instructions, errors, and code changes.

Where to take it next

You now have a local app you can inspect and change. Keep working in the canvas, or take it in one of these directions.

Open in VS Code

When you want to edit Python tools, review configuration, or work in your usual editor, select Open in VS Code.

The source stays in your repo or worktree, where you can review and commit it. In REDACTED mode, the editor handoff uses a scrubbed copy so credentials are not exposed; the real project stays unchanged.

You can extend the starter with reusable SKILL.md guidance, other MCP servers, and Python tools for the parts that need code. The generated project uses regular files, not a format owned by the canvas.

Deploy to Azure

To run beyond your laptop, Deploy to Azure uses Azure Developer CLI (azd) from an isolated copy. Your working source and local host stay unchanged.

Select Deploy to Azure to deploy your hosted skill from an isolated copy.

The supported Timer/HTTP template configures the Function App's managed identity, required RBAC roles, and remote model and app settings. The deployed app uses its identity for Azure access, not your laptop's CLI session. Gateway credentials, when needed, pass through secure deployment parameters rather than source files.

Deployment needs a subscription, an Azure-backed Foundry or AI Gateway model, and permission to create resources and assign roles. Copilot is local-only; Queue testing remains local. Reuse a model or explicitly approve model creation. Deployment starts only when you choose it, can incur charges, and reports progress and errors in Deployment output.

Expose the Hosted Skill as an MCP tool

The same digest can become a building block for developer tools and other agents, rather than only a task on your own schedule. Add one line to the skill's front matter:

That enables a standard MCP HTTP endpoint at /runtime/webhooks/mcp for debugging and agent-to-agent use. Connected MCP clients, including Microsoft Foundry and Microsoft Agent 365 (A365) agents, can call the skill with the required mcp_extension system-key authentication.

Other developers and agents get the same capability as a callable tool. Its event trigger still works; you do not write a separate MCP server.

Doctor is there if you need help

Doctor is optional, not a gate before invoking. Use it for initial setup help or if you encounter an issue. Its readiness report shows which tools are ready, what is missing, and what to fix for the selected workflow.

We recommend uv for Python and the isolated environment. Azure-backed workflows use your Azure CLI sign-in; local Copilot testing does not need an Azure deployment or Azure sign-in.

Shared pieces in canvas-toolkit

Building this meant solving Azure sign-in, environment checks, command activity, and styling that fits the host.

We put the reusable parts back into Microsoft​/canvas-toolkit: Azure authentication, redaction-safe command logs, and shared UI and theme support. Doctor remains app-specific and uses those shared pieces alongside its Functions checks.

Find the toolkit setup and starter examples in the Azure Dev Tools repo.

Install the tools

Install the tools from the marketplace: open Customize > Plugins, select Awesome Copilot, and install Azure Functions Hosted Skills.

Pro tip: install it directly.

Start a new session so the canvas and its launcher skills are available, then ask:

Open Azure Functions Hosted Skills canvas.

Give it a try, and tell us what you think. For resource queries and cost checks, take a look at the other Azure canvases.

Watch the demo

See the Azure Functions Hosted Skills canvas in action in the GitHub Copilot app.