Why Provenance Is the Correct Unit of Analysis

Most AI code risk discussions anchor on the output — the code itself — rather than the chain of custody that produced it. That framing leads to bad policy.

Code provenance encompasses the model that generated it, the review process it passed through, the signing authority that attests to it, and the distribution channel that delivered it. Each of those variables changes the risk profile independently.

Microsoft 365 Copilot outputs that flow through Visual Studio Code, get committed to Azure DevOps, pass a pipeline with static analysis, and are packaged into a signed MSIX installer have a provenance chain you can verify at every step. An open-source LLM running locally on a developer workstation, producing a compiled executable that gets shared via Teams message, has no verifiable chain at any step.

Treating these two scenarios identically — either by allowing both or blocking both — is a governance failure. The first produces unnecessary friction against Microsoft's own tooling. The second exposes your fleet to genuinely unvetted execution paths.

---

A Three-Tier Risk Model for AI Code Origins

Before writing a single policy, you need a classification framework that your Intune and Defender configurations can actually enforce. The following three tiers reflect real-world origin patterns in enterprise fleets.

Tier 1 — Microsoft-Native AI Outputs

This includes code generated or assisted by Microsoft 365 Copilot, GitHub Copilot operating within an enterprise-licensed tenant, and Azure OpenAI Service integrations that your organization controls. Artifacts in this tier are typically distributed through Microsoft's own signing infrastructure. The risk profile is comparable to any other Microsoft-published software: not zero, but bounded by Microsoft's own security controls, SDL process, and the enterprise admin's ability to verify publisher certificates.

Tier 2 — Vetted Third-Party AI Outputs

This covers code produced by commercial AI coding tools outside the Microsoft stack — JetBrains AI, Amazon CodeWhisperer, Tabnine — where the vendor has a defined security posture, enterprise agreements exist, and outputs pass through your organization's own review pipeline before deployment. Risk is higher than Tier 1 because the signing chain is external to Microsoft, but manageable if your pipeline enforces code review and your Intune policies restrict execution to signed artifacts from approved publishers.

Tier 3 — Open-Source LLM Artifacts

This is the high-risk category: code generated by locally-run models (Ollama, LM Studio, unconfigured open-source deployments), outputs from consumer-grade web interfaces copied directly into scripts, and any compiled binary where the generation origin is unverifiable. These artifacts frequently arrive unsigned, bypass your standard software distribution channels, and may contain hallucinated API calls that interact with system resources in unexpected ways.

---

Intune Application Control Policy Architecture

Windows Defender Application Control (WDAC) is the enforcement layer. Intune is the delivery mechanism. The goal is a policy set that allows Tier 1 artifacts without friction, gates Tier 2 artifacts on signing verification, and blocks or audits Tier 3 artifacts by default.

Start with a base WDAC policy that allows Microsoft-signed code and your own internal signing certificate. This is standard practice. The AI-specific additions are the publisher rules that explicitly allow GitHub Copilot extension outputs distributed through the VS Code Marketplace signing chain, and the deny rules that catch unsigned executables dropped into user-writable paths.

The following PowerShell block generates a WDAC policy that enforces publisher-level trust for Tier 1 and Tier 2 origins while blocking unsigned binaries from user-writable directories:

$PolicyPath = "C:\WDAC\AICodePolicy.xml"
$AuditPolicyPath = "C:\WDAC\AICodePolicy_Audit.xml"

New-CIPolicy -Level Publisher -Fallback Hash `
    -FilePath $PolicyPath `
    -UserPEs `
    -MultiplePolicyFormat

$DenyRules = @(
    New-CIPolicyRule -FilePathRule "$env:USERPROFILE\Downloads\*" -Deny,
    New-CIPolicyRule -FilePathRule "$env:TEMP\*" -Deny,
    New-CIPolicyRule -FilePathRule "C:\Users\*\AppData\Local\Temp\*" -Deny
)

Merge-CIPolicy -PolicyPaths $PolicyPath `
    -OutputFilePath $PolicyPath `
    -Rules $DenyRules

ConvertFrom-CIPolicy -XmlFilePath $PolicyPath `
    -BinaryFilePath "C:\WDAC\AICodePolicy.p7b"

Write-Host "Policy binary ready for Intune OMA-URI deployment at C:\WDAC\AICodePolicy.p7b"

Deploy this binary via Intune's Custom OMA-URI profile using the path ./Vendor/MSFT/ApplicationControl/Policies/{PolicyGUID}/Policy. Set the data type to Base64 and upload the .p7b file.

For Tier 2 publishers, add explicit allow rules scoped to the vendor's signing certificate thumbprint. Pull the thumbprint from a known-good signed artifact:

$ArtifactPath = "C:\Staging\VettedAITool.exe"
$Cert = (Get-AuthenticodeSignature -FilePath $ArtifactPath).SignerCertificate

if ($Cert) {
    Write-Host "Publisher: $($Cert.Subject)"
    Write-Host "Thumbprint: $($Cert.Thumbprint)"
    Write-Host "Issuer: $($Cert.Issuer)"
    Write-Host "Valid Until: $($Cert.NotAfter)"

    # Generate a publisher-level WDAC rule for this certificate
    $PublisherRule = New-CIPolicyRule `
        -DriverFilePath $ArtifactPath `
        -Level Publisher `
        -Fallback Hash

    # Export rule for review before merging into production policy
    $PublisherRule | Export-Clixml -Path "C:\WDAC\Rules\Tier2_$(($Cert.Thumbprint).Substring(0,8)).xml"
    Write-Host "Rule exported. Review before merging into production WDAC policy."
} else {
    Write-Warning "Artifact is UNSIGNED. Do not add to allow list. Classify as Tier 3."
}

---

Defender for Cloud Detection Strategies

WDAC handles execution prevention. Microsoft Defender for Endpoint handles behavioral detection for cases where execution does occur — particularly important during the audit phase before you switch WDAC policies to enforce mode.

The detection strategy for AI-generated code risk focuses on three behavioral signals: unsigned binary execution from user-writable paths, anomalous process lineage (a code editor spawning a network-connected child process), and PowerShell execution of base64-encoded commands that match patterns common in LLM-generated automation scripts.

Use the following KQL query in Microsoft Sentinel or Defender XDR Advanced Hunting to surface Tier 3 risk indicators across your managed fleet:

// Detect unsigned binary execution from high-risk drop paths
// Targets Tier 3 LLM artifact deployment patterns
// Run in: Microsoft Defender XDR Advanced Hunting or Sentinel

let HighRiskPaths = dynamic([
    "\\Downloads\\",
    "\\AppData\\Local\\Temp\\",
    "\\AppData\\Roaming\\",
    "\\Users\\Public\\"
]);

let KnownAIEditors = dynamic([
    "code.exe",         // VS Code
    "devenv.exe",       // Visual Studio
    "cursor.exe",       // Cursor AI IDE
    "windsurf.exe"      // Windsurf IDE
]);

DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ (KnownAIEditors)
| where FolderPath has_any (HighRiskPaths)
| where not(isnotempty(InitiatingProcessSignatureStatus) 
    and InitiatingProcessSignatureStatus == "Valid")
| extend RiskIndicator = case(
    FolderPath has "\\Downloads\\", "Tier3-DownloadDrop",
    FolderPath has "\\Temp\\", "Tier3-TempExecution",
    FolderPath has "\\Public\\", "Tier3-PublicShare",
    "Tier3-UnknownPath"
)
| project Timestamp, DeviceName, AccountName, 
    FileName, FolderPath, ProcessCommandLine,
    InitiatingProcessFileName, RiskIndicator
| order by Timestamp desc

Schedule this query as a Sentinel Analytics Rule with a severity of High and map it to the MITRE ATT&CK technique T1204.002 (User Execution: Malicious File). The AI editor process names in the KnownAIEditors list are the key signal: a developer's IDE spawning an unsigned binary from a temp path is a strong indicator that LLM-generated code was executed without going through any review or signing pipeline.

---

Governance Policy Structure for AI Code Provenance

Detection and enforcement are technical controls. The governance layer defines what your organization has decided is acceptable and creates the audit trail that demonstrates compliance.

Your AI Code Provenance Policy should define three things: the approved AI code generation tools by tier, the required review and signing steps before deployment, and the enforcement mechanism that verifies compliance.

For Tier 1 tools, the policy should require that GitHub Copilot is used only within enterprise-licensed accounts (not personal accounts), that generated code passes your existing pipeline gates (linting, SAST, peer review), and that deployment artifacts are signed with your internal certificate or Microsoft's signing chain.

For Tier 2 tools, add a vendor security assessment requirement — at minimum, confirm the vendor has a published vulnerability disclosure policy and that their tool does not exfiltrate code to external training datasets without consent. Document the approved publisher certificate thumbprints in your WDAC policy and review them on a defined cadence.

For Tier 3 scenarios — which includes any developer experimenting with local LLMs — the policy should require that outputs are treated as untrusted code, submitted to your standard code review process, and never executed directly from generation context. The WDAC deny rules for user-writable paths enforce this technically, but the policy creates the accountability framework.

Intune's Compliance Policies can surface devices where WDAC is not in enforce mode, flagging them for remediation. Pair this with a Conditional Access policy that blocks access to production deployment pipelines from non-compliant devices.

---

Operational Rollout Without Breaking Developer Workflows

The failure mode for most WDAC deployments is moving to enforce mode too quickly and blocking legitimate developer tooling. AI code governance adds a new dimension to this risk because the tooling landscape is moving fast — new AI IDEs and extensions appear monthly, and your allow list will lag behind adoption.

Start with a 30-day audit phase. Deploy the WDAC policy in audit mode via Intune, run the KQL detection queries daily, and build a baseline of what your developers are actually executing. You will find Tier 2 and Tier 3 artifacts you did not know existed. Use that data to refine your allow list before switching to enforce mode.

During audit phase, send weekly reports to engineering leads showing the unsigned binary execution events on their teams' devices. This creates organizational awareness without blocking work, and it gives developers the opportunity to bring shadow AI tooling into the formal approval process before enforcement cuts them off.

When you move to enforce mode, do it in rings. Start with your highest-privilege users — domain admins, Azure subscription owners, DevOps pipeline service accounts. These are the accounts where a Tier 3 artifact executing with elevated privileges creates the most damage potential. Expand to the broader developer population after two weeks of clean enforcement on the high-privilege ring.

---