Scan before Azure sees it
Security checks should run before deployment, not only after the Azure environment is already changed. Microsoft Security DevOps can scan IaC directly from a GitHub repository. That means a pull request can be rejected because a configuration pattern is not acceptable before it ever reaches Azure.
That is a strong control because it reduces the probability of insecure infrastructure reaching production at all. It complements cloud-side enforcement rather than replacing it.
The layered model works well:
Pre-deployment validation catches the risky configuration. Runtime signal catches the drift and the misconfiguration the static pipeline did not catch. You want both.
Security scanning and policy enforcement are different controls
There is an important difference between a scanner and policy enforcement. A scanner can tell you that a configuration looks risky. Policy can tell the platform that the configuration is not permitted.
That distinction matters in IaC. An AI assistant might generate a configuration that seems safe to a human reviewer but still violates a platform rule. Policy as code makes the enforcement boundary explicit, and Azure RBAC plus Entra workload identity keep the deployment path aligned to the correct security model:
Whether the code was authored by a human, Copilot or an agent, the deployment path should still be subject to the same policy rules.
Treat drift as a feedback loop
Microsoft’s architecture does not end the lifecycle at a successful deployment. Cloud environments keep changing. New vulnerabilities appear. Policies change. Drift happens. Manual changes happen. Defender for Cloud and Azure Policy can find those changes and feed them back into GitHub for reconciliation.
The resulting feedback loop is:
That is much closer to how cloud infrastructure actually behaves than the idea that a build pipeline is a one-way street.
When security findings are converted to GitHub issues or remediation PRs, you are effectively turning cloud drift and misconfiguration into a software maintenance problem. That is a good thing for repeatability and auditability.
AI can participate in remediation without being the trust boundary
Microsoft also points to a pattern where security findings can be handled with Security Copilot. That is exactly how I think AI should be introduced into the remediation loop.
It also matches the direction of agentic workflows. If an AI agent is allowed to investigate findings, propose a fix, and prepare a PR, that is useful. But it should not become the approval layer or the final policy boundary. Those remain deterministic controls, backed by Entra identity, Azure RBAC, and policy enforcement.
Record how each deployment was produced
For software supply chains, provenance is already a major topic. Artifact attestations can help answer what built a given artifact, which workflow produced it, which commit it came from, and which environment it was associated with.
For infrastructure delivery, the same principle applies. We should be able to answer:
- what changed this resource
- which deployment created it
- which workflow and commit were involved
- which pull request was approved
- which security checks passed
Provenance does not prevent every failure, but it helps create a more trustworthy chain of custody for infrastructure changes. It is especially helpful when a deployment must be explained during an audit or a security review.
Agentic workflows change the threat model
The original Copilot model was mostly a human prompt plus an AI suggestion. The newer pattern is more autonomous:
GitHub’s agentic workflow model shows that automation can now participate in repository tasks in a more active way. That changes the threat model. If AI can create or modify code, then the policy enforcement and approval boundaries matter even more.
Traditional DevOps gave humans the final code change. Agentic DevOps gives AI a larger role in the pipeline. That means the controls must be even more deterministic:
| Area | Human-led pattern | Agentic pattern |
|---|---|---|
| Code creation | Human writes IaC and reviews it | AI creates code and prepares PRs |
| Review | Human reviews and approves | Systematic policy and security control remains mandatory |
| Deployment | Human initiates workflow | Workflow retains a strong authorization boundary |
| Remediation | Human fixes issue | AI can investigate and propose, but not bypass approval |
Automation is not the same as trust. AI can speed up investigation and development, but it should not receive authority to approve the change by itself.
Deterministic workflows and agentic workflows are complementary
The split is practical. Agentic workflows are good for contextual reasoning, investigation and recommendation. Deterministic workflows are better for validation, authorization, approval and deployment.
The resulting division of responsibility is simple:
With this split, AI can accelerate investigation and implementation without receiving authority to approve or deploy the change.
A production pattern for Azure delivery
If I were implementing this in an enterprise, the design would include the following controls:
- GitHub branch protection and CODEOWNERS
- full-length SHA pinning for GitHub Actions
- Dependabot for GitHub Actions security updates
- OIDC with Microsoft Entra Workload Identity Federation
- least-privilege GitHub token permissions
- environment-level approvals and protected deployment paths
- policy as code as a required pull request gate
- Microsoft Security DevOps for IaC scanning
- Azure Policy and Defender for Cloud as cloud-side enforcement and detection
- drift reconciliation back to GitHub
- AI-assisted remediation with human review
That is the architecture I would add to Microsoft’s baseline. It makes the trust boundary explicit and keeps the system grounded in identity, policy and review.
What this means in production
This is not mainly a choice between Bicep, Terraform or Copilot. It is a decision to treat infrastructure delivery as a software supply chain with clearly defined trust boundaries.
Infrastructure starts as code. It goes through review. It is validated by security and policy. Identity authorizes the deployment. Azure enforces additional controls. Runtime detection catches drift and misconfiguration. Findings flow back to GitHub. AI can participate in the investigation and in remediation, but the final trust boundary remains identity, deterministic policy, and review.