Codename MDASH is not just another scanner to switch on and forget. It brings agentic analysis to source code, which means the setup choices matter: who can run scans, where code is processed, what gets logged, which models are used, and whether findings are treated as review input or build-stopping truth. A safe rollout starts by making those boundaries explicit.

Start with the operating model, not the button

MDASH is enabled and configured from the Microsoft Defender portal, and participation requires access through an eligible Microsoft Defender XDR plan. Microsoft Defender XDR means Microsoft Defender Extended Detection and Response, the security suite that brings several Defender products together in one tenant.

Onboarding is intentionally an administrative act. The person setting it up needs to be a Global Administrator or Security Administrator in Microsoft Entra ID, and must have authority to accept the MDASH terms and conditions for the organization. That is more than a technical prerequisite; it is a governance checkpoint.

You also need an Azure subscription and resource group for a dedicated Microsoft Foundry resource used only for MDASH. The required models must be deployed there, and inference runs through the customer’s Microsoft Foundry endpoints. In plain terms, your tenant connects MDASH to your own model-serving surface rather than using an opaque scanner backend.

Onboarding MDASH is a governance act requiring admin rights and a dedicated Foundry resource. Onboarding Needs Onboardinggovernance act Admin roleGlobal or Security Accept termsorg-wide Foundry resourcededicated Deploy modelsyour endpoints
Onboarding MDASH is a governance act requiring admin rights and a dedicated Foundry resource.

Choose a scanning path that matches your risk and workflow

MDASH needs at least one way to reach code. The recommended first path is a remote scan through a GitHub connector, initiated from the Defender portal. Nothing has to be installed on a developer workstation for that path. To create the connector, the operator needs Global Administrator or Security Administrator rights in Microsoft Entra ID and Organization Owner rights in the GitHub organization.

The second path is the Defender command-line interface, or CLI, available for Windows, macOS, and Linux. The CLI is useful for local testing, scripted workflows, and continuous integration and continuous delivery pipelines, often shortened to CI/CD. You can start with one scanning path and add the other later.

After scans run, results appear in the Microsoft Security Exposure Management area of the Defender portal under Initiatives, specifically in the Codename MDASH - Agentic code scanner initiative. The point of that location is important: findings become part of exposure management, not a separate pile of scanner output.

  1. Accept the MDASH terms and conditions.
  2. Connect a Microsoft Foundry resource and deploy the required models.
  3. Enter the Foundry project endpoint and application programming interface key in the Defender portal, then validate and save the connection.
  4. Set up either the GitHub connector for remote scans or the Defender CLI for local and pipeline scans.
  5. Review recommendations in the Codename MDASH - Agentic code scanner initiative.
You can reach code through a remote GitHub connector or the local Defender CLI. Two Scan Paths GitHub connectorremote Defender CLIlocal Nothing to install Runs anywhere Portal-driven Scripts and CI
You can reach code through a remote GitHub connector or the local Defender CLI.

Use role-based access control as a safety rail

MDASH permissions are assigned through Microsoft Defender unified role-based access control, commonly called RBAC. RBAC is the practice of granting capabilities through roles rather than giving every operator broad administrative power.

The relevant permission group is Agentic code security, under AI Scan Security. Microsoft separates the ability to run scans, upload results, read findings, and manage findings. That separation is useful because the person who triggers a scan does not always need to dismiss or otherwise triage its results.

When assigning these roles, keep both Microsoft Defender for Cloud and Microsoft Security Exposure Management selected as data sources. If one is omitted, access may look correct on paper while failing in practice.

📌
Least privilege matters. A safe MDASH rollout gives scan runners, result viewers, and finding managers different rights unless one person truly needs all of them.
RBAC separates who can run scans, read findings, and manage them. RBAC Roles Run scanstrigger only Read findingsview results Manage findingstriage and dismiss
RBAC separates who can run scans, read findings, and manage them.

Plan network access before the first scan fails

MDASH depends on several outbound connections. In open network environments this may not be noticeable, but restricted enterprise networks need allow-listing before scans are reliable.

For Defender AI scan traffic, examples of required domains include *.cli.dfd.security.azure.com, *.blob.core.windows.net, *.azurefd.net, *.login.microsoftonline.com, and *.graph.microsoft.com. For identity federation in automation, GitHub Actions uses *.token.actions.githubusercontent.com for OpenID Connect, and Azure Pipelines uses *.dev.azure.com for OpenID Connect. Application Insights endpoints are used for telemetry, and container-registry domains may be needed for defender scan fs.

If the Microsoft Foundry resource is configured to allow only selected networks and private endpoints, additional work is required so MDASH can reach it. Treat this as part of the design, not a troubleshooting detail to discover after the security team has already promised scan coverage.

⚠️
Private networking. A locked-down Foundry resource may block MDASH until explicit access has been configured.

Treat CI/CD scans as review signals, not perfect gates

The Defender CLI can be used interactively on a local machine or non-interactively inside CI/CD. For unattended pipeline use, Microsoft supports authentication through a Microsoft Entra application registration and client secret.

A basic CLI scan uses defender scan ai-scan submit . from the repository root. The command archives the repository, submits it for analysis, and waits for results. Adding --severity high limits returned results to high and critical severity findings.

For longer scans, an asynchronous workflow is available. You can submit a scan to receive a job identifier, check progress with defender status ai-scan job-id, wait for completion and write results with defender status wait -o results.sarif, and list or cancel jobs with defender status and defender status cancel job-id. SARIF, the Static Analysis Results Interchange Format, is compatible with GitHub Advanced Security, Azure DevOps, and other security tooling.

The important caveat is that MDASH performs AI-based analysis, and scan times can be long. AI-based findings may also be non-deterministic. That makes MDASH well suited to asynchronous security review, backlog creation, and expert triage. It is a weaker fit for deterministic build-blocking rules where teams expect the same answer every time in a fixed number of minutes.

An async scan submits a job, checks progress, then writes SARIF results. Async Scan Submitget job id Check statusprogress Write resultsto SARIF
An async scan submits a job, checks progress, then writes SARIF results.

Know where code, results, and logs go

MDASH stores customer source code and scan results encrypted at rest within the customer’s Defender XDR tenant, in the same region as that tenant, and processes them in that region. Inference over source code runs in the region the customer specifies when connecting MDASH to Microsoft Foundry endpoints, subject to the applicable service terms.

Uploaded data is classified as Persistent. Microsoft’s Data Protection Addendum, often called the DPA, applies, including its deletion provisions. Specific retention and deletion timelines are addressed separately in Microsoft’s service documentation and terms.

MDASH also records an audit trail for privileged-user actions across the scan lifecycle. These include CLI onboarding, Foundry connection and disconnection, scan start, cancellation, upload, view, and export. The audit data includes timestamp, user, client internet protocol address, scan identifier, code target, source surface, and result. Source code itself is not logged. Audit events remain in the customer’s Microsoft Entra tenant log and can be queried through Microsoft Purview.

Read-only repository access is sufficient to perform an assessment. During the current validation phase, the scanned repository is cloned locally to the machine running the scanner. Both on-premises and cloud-hosted Git repositories are supported.

✅
What is not logged. MDASH audit events record privileged actions and scan metadata, but they do not log the source code itself.

Make rollout decisions with current limits in mind

MDASH has current scale limits that affect rollout design. Microsoft describes the repository size limit as approximately 256 megabytes per repository, subject to change. At this stage, one concurrent scan per tenant is supported, also subject to change and potentially variable by environment. Capacity is the primary constraint, and scans are deliberately rate-limited to protect quality.

There is no fixed scan duration. Time varies with codebase size, programming language, repository complexity, and number of findings. Scans run asynchronously, so teams should plan queues, expectations, and service-level objectives around variability rather than assuming scanner behavior will look like a fast compiler step.

Regional availability also matters. MDASH is available in the Azure commercial cloud in the United States, European Union, United Kingdom, Australia, India, Switzerland, and United Arab Emirates. The United Arab Emirates currently supports MDASH CLI scans only.

For leaders and practitioners, the decision is not simply whether MDASH can scan code. The practical decisions are which repositories are in scope first, who may run scans, who may suppress findings, which region is acceptable for inference, how results enter the vulnerability management process, and whether CI/CD usage is advisory or blocking. Those choices determine whether MDASH becomes a governed security capability or another noisy tool.

  • Start with a small set of representative repositories before broad rollout.
  • Define who can run scans separately from who can manage findings.
  • Document the chosen Foundry region and model profile for auditability.
  • Use asynchronous review until scan behavior is well understood by the engineering teams.
  • Require human approval before any code change is made in response to a finding.

Key takeaways

  • MDASH requires an eligible Microsoft Defender XDR plan, administrator approval, a dedicated Microsoft Foundry resource, and at least one scanning path.
  • Use Defender unified RBAC to separate scan execution, result upload, result viewing, and finding management.
  • Restricted networks need explicit allow-listing for Defender, identity, telemetry, storage, and pipeline endpoints.
  • MDASH stores code and results encrypted in the customer’s Defender XDR tenant region, while inference runs through the customer-selected Foundry endpoint region.
  • The audit trail records privileged actions and scan metadata, not the source code itself.
  • Because AI-based scans can be long-running and non-deterministic, CI/CD use is best treated as asynchronous review rather than a hard build gate.

Glossary

MDASH
Codename MDASH is a Microsoft Defender capability for agentic analysis of source code and related security findings.
Microsoft Defender XDR
Microsoft Defender Extended Detection and Response is Microsoft’s integrated security suite for detecting, investigating, and responding to threats across several domains.
Microsoft Entra ID
Microsoft Entra ID is Microsoft’s cloud identity and access management service, formerly known as Microsoft Entra ID.
Microsoft Foundry
Microsoft Foundry is the customer-connected model and inference environment used by MDASH to run required AI models through customer endpoints.
RBAC
Role-based access control is a permission model that grants users specific capabilities through assigned roles.
CLI
A command-line interface is a text-based tool used to run commands from a terminal or script.
CI/CD
Continuous integration and continuous delivery is the practice of automatically building, testing, and preparing software changes for release.
SARIF
The Static Analysis Results Interchange Format is a standard file format for exchanging static analysis and security scanning results.