Agentic Developer Portal¶
The Agentic Developer Portal is a self-service web portal for the Azure environment of an organisation. It is built on Backstage and shows, in one place, which workloads exist, who owns them, what they cost, how secure and compliant they are and what the network layer blocks. AI agents in the portal answer questions about this data and prepare configuration changes as pull requests. The same actions are available to the developer's editor through the Model Context Protocol (MCP).
The portal runs inside the customer's own Azure environment. One shared code base is deployed once per customer environment, so every customer runs the same image and gets new features through releases. In the source repository the product has the working name Cloud Command; you may see that name in resource names, agent instructions and the repository.
Optional offering
The portal is not part of the core MCP hub and spoke. It is an add-on that sits next to the platform and reads from it. Whether it is available to you, which features are switched on and how it is contracted depends on your platform and your agreement. Ask your platform team. The pages here describe the reference design; your deployment may differ. Operators: start with Architecture and Onboarding a customer.
Who it is for¶
| Audience | What they use it for |
|---|---|
| Platform and DevOps engineers | Day-to-day questions about workloads, domains, network blocks, security recommendations and policy compliance, without filing a ticket. AI agents and the MCP server for repetitive configuration work. |
| Security and compliance officers, domain and department heads | The security score and compliance status of their teams, with summary views as the entry point and detail below. |
| FinOps and cost owners | Monthly Azure cost per subscription, workload, team and domain. |
| The platform team | Deploying, configuring and operating the portal for one or more customer environments. |
What you get¶
| Area | What it does | Page |
|---|---|---|
| Catalog | Workloads, domains, teams, organisations and their relations, built from Azure tags, Entra ID and repository files | Catalog and entity model |
| Cost insights | Azure cost per subscription, workload, team and domain, in the FOCUS schema | Insights |
| Network insights | Blocked firewall requests and Application Gateway WAF logs per workload | Insights |
| Security insights | Microsoft Defender for Cloud secure score and recommendations, rolled up per scope | Insights |
| Compliance insights | Regulatory compliance standards (Azure Policy) as a matrix per scope | Insights |
| AI agents | A commander agent plus skills for spoke and integration platform changes | AI agents |
| MCP server | The portal's actions for your IDE and for other agents, plus an inspector page | MCP server |
| Module registry | Browse and download Terraform modules from a connected registry | Module registry |
| Sign-in and access | Entra ID sign-in, ownership-based access to sensitive detail | Authentication and access |
For the full list of what is offered, its prerequisites and its boundaries, read the service description.
Scope¶
| In scope | Not in scope |
|---|---|
| Read-only insight in Azure resources, cost, security, compliance and network logs of the subscriptions the portal can read | Changing Azure resources directly. Agents prepare pull requests, people review and merge them. |
| Catalog of workloads, domains, teams and users from Azure tags, Entra ID and repository files | Replacing the platform's change process (Making a change safely) |
| AI agents and MCP actions on top of that data and on the spoke and integration configuration repositories | Customer-specific changes to the portal code. A customer-specific request is routed as separate work through the solution lead. |
| Processing all customer data inside the customer's Azure environment | Storing customer data in the provider's environment |
| A module registry view (browse, download, optionally upload and delete) | Running or building the registry itself |
How it relates to the platform¶
The portal is deployed into a spoke of the Managed Cloud Platform and reads the management group hierarchy above it.
- Each portal environment (for example acceptance and production) lives in its own spoke, built with the spoke canvas. It uses the spoke's network, Key Vault and Log Analytics workspace.
- It discovers workloads from the subscription tags of the platform (Naming and tags) and users and groups from Entra ID. See the identity and access model.
- The spoke agent reads and proposes changes to the spoke configuration of the platform (Spoke JSON reference). The platform's review and deployment steps stay as they are.
- The integration agent works on the configuration of the Integration Platform.
- The module registry view lists modules such as those of Managed Templates, if your registry holds them.
- The AI models are served by an Azure AI Foundry account in the customer's subscription. The separate AI Platform solution is a different offering.
The portal is an additional service in the sense of Service types: it has its own scope and is delivered next to the platform baseline.
Operating models¶
The platform team that deploys and runs the portal is XMMS under a managed-service contract, or the customer's own team when the platform is self-managed. See Operating models.
| Workload team | Platform team | |
|---|---|---|
| Use the portal, tag subscriptions and own workloads | Yes | |
| Review and merge pull requests that agents prepare | Where they own the repository | Yes, for platform configuration |
| Deploy, configure and update the portal | Yes | |
| Grant the portal read access to Azure and Entra ID | Yes, with the customer's cloud platform administrator and Entra ID administrator | |
| Approve private endpoint connections for deployment | Yes, on the customer side |
Code and pipelines are not handed over in the reference delivery
In the reference delivery the provider keeps the source code and deploys the image into the customer tenant from the provider's own pipeline. The customer receives the deployed product, not the code. How a self-managed team receives and runs the portal is not described in the sources of these pages. Agree this explicitly in your contract.
Documentation map¶
| Page | Content |
|---|---|
| Service description | What is offered, prerequisites per feature, boundaries |
| Catalog and entity model | Entity kinds, tags, merging |
| Insights | Cost, network, security and compliance |
| AI agents | The agents, what they can do, guardrails |
| MCP server | Use the portal from an IDE |
| Module registry | Browse and download Terraform modules |
| Authentication and access | Sign-in, ownership-based access |
| Architecture | Components, Azure resources, data flows, network |
| Prerequisites | What the customer provides before deployment |
| Onboarding a customer | Runbook for the platform team |
| Deployment and environments | Terraform roots, environment file, pipelines |
| Configuration | Feature flags, schedules, GitHub, theme, module registry |
| Cost insights setup | Cost export and ingestion resources |
| AI setup | Foundry, spoke agent, integration agent |
| WAF and custom domain | Application Gateway and WAF in front of the portal |
| Agent evaluation | How agents are tested and observed |
| Operations | Health, sync, alerting, troubleshooting |
| Decisions | The architecture decisions in short |