# Agentic DevOps with GitHub Actions and Microsoft Foundry

> Source: <https://dev.to/balop3e/agentic-devops-with-github-actions-and-microsoft-foundry-1f4h>
> Published: 2026-09-25 11:38:13+00:00

As AI agents become a bigger part of the conversation around software development, I started thinking about what they could mean for my own role as a DevOps engineer. Where could they help in a delivery pipeline? What decisions could they support? And where would I still want myself or someone else to firmly be in control?

For sure we know DevOps already involves a great deal of automation. We build pipelines to test code, check for problems, and move changes between environments. But deciding whether a release should proceed requires context. Passing tests are useful evidence; but they do not answer every question about the risk of a change.

That made release review an interesting place to experiment. Could an agent help explain the evidence, highlight concerns, and prepare better questions for the person approving a deployment? I mean I already interact with agents like they are colleagues and it's been real so far.

I built a small proof of concept with GitHub Actions and Microsoft Foundry to explore that question. I wanted to understand the moving parts for myself, how evidence reaches a reviewer, how a recommendation affects the workflow, and how approval remains under human control.

This article shares that experiment with other DevOps and platform engineers asking similar questions about their roles. It walks through what I built, what it demonstrates, and what would still need to change before using the approach in production.

The implementation has two parts. GitHub Actions runs a **deterministic release review** and demonstrates an environment approval gate. Separately, a Microsoft Foundry agent reviews the same sample evidence in the playground. The workflow does not yet call Foundry, and its staging and production jobs simulate deployment.

That boundary matters. This is a practical foundation for an agent-assisted release process, with a clear path to integration.

**Repository:** [balop3e/agentic-devops-poc](https://github.com/balop3e/agentic-devops-poc)

The question I wanted to explore was straightforward, how can an AI recommendation fit into a release process without becoming the authority that approves production?

| Component | What happens in this demo | 
|---|---|
| GitHub Actions | Runs tests, generates sample evidence, executes the review, and sequences the jobs. | 
| Python review script | Applies fixed rules to produce a risk score and recommendation. It does not call an AI model. | 
| Microsoft Foundry agent | Reviews the same evidence through a separate, manual playground interaction. | 
| GitHub production environment | Pauses the production job for a configured reviewer. | 
| Deployment jobs | Print demonstration messages; they do not deploy an application. | 

The actual unit tests run before evidence generation. However, the release evidence uses preset low-risk and high-risk scenarios. Its test counts, coverage changes, and vulnerability counts are predefined inputs for exercising the review logic.

*Figure 1. The implemented workflow and the separate Foundry experiment. The AI response does not feed back into the workflow in this version.*

A push to `main` or a manual workflow run starts the build and test job. When that job succeeds, the workflow generates a JSON evidence file and stores it as an artifact. The review job reads that artifact and publishes a Markdown report.

The staging simulation runs when the review exposes a `proceed` decision. The production simulation additionally requires a manual run with `deploy_production=true`, successful staging, and satisfaction of the production environment's protection rules.

Alongside this flow, I pasted the evidence into Foundry to explore the quality of an AI-generated explanation. This kept the workflow demonstration repeatable while letting me inspect the model's response separately.

An AI reviewer needs a defined input. Asking whether a release is safe without supplying evidence encourages assumptions.

The demo uses fields for the commit, workflow run, target environment, tests, change size, coverage, vulnerabilities, database migrations, and dependency changes. Here is an illustrative low-risk input, with placeholder identifiers:

```
{
  "commit_sha": "example-commit",
  "workflow_run": "example-run",
  "deployment_target": "production",
  "total_tests": 24,
  "failed_tests": 0,
  "changed_files": 6,
  "coverage_delta": -1.1,
  "high_vulnerabilities": 0,
  "critical_vulnerabilities": 0,
  "database_migration": false,
  "external_dependency_change": false
}
```

Note that these numbers are sample data, not measured results. The schema defines `coverage_delta` as a percentage-point change, a fall from 80% to 78.9% is a change of -1.1 percentage points. The original demo report displays a percent sign, which is less precise.

In a real pipeline, I would populate these fields from the test runner, coverage report, vulnerability scanners, and deployment metadata. I would also include evidence timestamps and an artifact digest so the review can be tied to the exact release candidate.

The repository includes `schemas/release-evidence.schema.json`. Having that file does not enforce the contract automatically, the current review script loads JSON into a Python dataclass without invoking a JSON Schema validator. Runtime schema validation and consistency checks, such as ensuring failed tests cannot exceed total tests, are next steps.

The Python review applies fixed scoring rules. Failed tests or critical vulnerabilities produce a `block` recommendation regardless of the final risk label. Other signals add points, including high-severity findings, larger changes, coverage drops, migrations, and dependency changes.

The low-risk fixture produces `proceed`, a low risk level, and a score of zero. These are outputs of an illustrative scoring model. A zero score is not a guarantee that a release is safe, and the score is not a probability of failure.

One implementation detail deserves attention, `assess_release()` can return `proceed_with_extra_review`, but `write_github_output()` maps every non-blocking recommendation to `proceed`. The production approval gate still applies, but the workflow does not enforce a separate extra-review process for that middle state.

Before extending this pattern, I would preserve that state explicitly and define the additional review it requires. More generally, policy should make mandatory decisions in code; the model should explain the evidence and surface questions.

Writing “human approval required” in a prompt or report does not enforce approval. The relevant control in this demo is the GitHub environment configuration.

The workflow's production job references `production`. A required-reviewer rule configured on that environment makes the job wait. The following simplified excerpt illustrates that relationship; it is not a complete workflow:

```
deploy_production:
  runs-on: ubuntu-latest
  needs: [agent_review, deploy_staging]
  if: >-
    github.event_name == 'workflow_dispatch' &&
    github.event.inputs.deploy_production == 'true' &&
    needs.agent_review.outputs.decision == 'proceed'
  environment:
    name: production
  steps:
    - name: Simulate deployment
      run: echo "Protected job released to run."
```

**The YAML reference alone does not create a reviewer requirement.** I still need to configure the environment protection rule separately. For independent review, I enabled prevention of self-review and select another eligible reviewer. Also review administrator bypass settings and restrict permitted deployment branches or tags. GitHub's current documentation says required reviewers on Free, Pro, and Team plans are available only for public repositories. See [deployment protection rules](https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments).

*Figure 2. The production simulation waits for environment review after the deterministic review and staging simulation finish.*

As you can see in the demonstration, the workflow waited at this gate and then completed after approval. This shows the gate operating in that run, but does not establish independent approval by a second person or prove that bypass was disabled. A printed log message saying a human approved is not, by itself, evidence that a gate was enforced.

For a production implementation, protect workflow changes and deployment credentials too. A job that omits the protected environment must not have another route to the same production permissions.

Azure Pipelines supports a related pattern through [approvals and checks](https://learn.microsoft.com/en-us/azure/devops/pipelines/process/approvals?view=azure-devops) on resources such as environments. That offers another way to keep the approval control outside the AI response.

The Foundry portion gives the reviewer a specific job, interpret the supplied release evidence and prepare useful context for an approver.

The main concepts are a Foundry resource, a project, a model deployment, and an agent. The resource provides the service boundary; the project organises the work; the model deployment supplies inference; and the agent adds instructions and, when configured, tools. The playground provides an interactive place to test the behaviour. Microsoft describes the platform in its [Foundry overview](https://learn.microsoft.com/en-us/azure/foundry/what-is-foundry).

For this experiment I used `gpt-4o-mini` and an agent called `devops-release-review-agent`. That records the demo configuration, rather than recommending a particular model for every release process.

The instructions asked for a risk level, recommendation, reasons, questions for the human reviewer, and a concise approval summary. They also told the agent not to claim production was approved and to recommend blocking when tests failed or critical vulnerabilities were present.

*Figure 3. The Foundry agent reviews evidence pasted into the playground. This is separate from the GitHub Actions execution.*

For the supplied low-risk evidence, the response recommended proceeding and raised questions for the approver. This is a useful example of explanation, but one favourable response does not establish reliability. The experiment does not demonstrate autonomous remediation, deployment tools, or a multi-agent system.

Prompts describe intended behaviour, they are not access controls. A release-review agent should have no permission to approve its own deployment or alter the approval configuration.

During setup, I encountered an important distinction between managing an Azure resource and using the AI service inside it.

The Azure **control plane** covers management tasks such as creating resources and assigning roles. The **data plane** covers service operations such as invoking models and working with agents. Subscription Owner does not itself grant all Foundry data-plane permissions, portal setup can add separate role assignments.

Check the specific operations and scope your identity needs in the [Foundry RBAC documentation](https://learn.microsoft.com/en-us/azure/foundry/concepts/rbac-foundry). Current documentation uses names such as Foundry User and Foundry Agent Consumer, older interfaces may still show Azure AI role names. An identity that only invokes an agent should not receive broad management privileges unnecessarily.

For a future GitHub-to-Foundry integration, I would use [OpenID Connect with Azure](https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-azure) and Microsoft Entra workload identity federation instead of a stored long-lived client secret. The workflow needs `id-token: write` to request an OIDC token, Azure role assignments determine what the resulting identity can do. Its trust configuration must match the intended repository and workflow context.

The agent-review identity and production deployment identity should have separate responsibilities and permissions.

The repository contains a reusable review workflow and a `Team Scaling Demo` caller. Two illustrative teams invoke the same implementation with different evidence profiles:

| Caller | Evidence profile | Expected review outcome | 
|---|---|---|
| Payments team | Low risk | Proceed | 
| Identity team | High risk | Block | 

*Figure 4. Team-specific jobs reuse the same review implementation within the demo repository.*

A successful review job means the analysis completed. It does not necessarily mean deployment is permitted the script can successfully produce a `block` decision. A caller must consume that output in its deployment conditions. The scaling demonstration itself has no deployment jobs.

This shows reuse within one repository. Extending it to separate repositories needs additional work. In particular, `actions/checkout` inside a called workflow normally checks out the caller's repository. The shared review code must be distributed deliberately, for example as a versioned action or package, rather than assuming its scripts exist in every caller. GitHub documents the execution context in [reusing workflows](https://docs.github.com/en/actions/concepts/workflows-and-actions/reusing-workflow-configurations).

I would make the platform team responsible for the evidence contract, review implementation, prompt versions, and evaluation cases. Product teams would supply release evidence and retain ownership of their deployment and approval configuration.

The next iteration should address several concrete gaps:

These are proposed enhancements, not capabilities already demonstrated by this repository.

It was very important for me to be able to prove or have a first hand experience on how infusing agents into the process will be. This allows me prepare for governance requirements not only for carrying out my work but also when it comes to making business decisions. The most useful result was a clearer separation of responsibilities. GitHub Actions executes the workflow. Deterministic rules evaluate explicit policy. Foundry can help explain the evidence. Environment protection rules control when the protected job may run.

This PoC demonstrates those pieces without claiming a complete AI-operated delivery platform. Connecting the agent is the next technical step; validating its usefulness and keeping the approval boundary intact are the next engineering responsibilities.

If you are exploring this approach, start with a release decision your team already makes. Define the evidence, make the policy explicit, and then test whether an AI reviewer helps people understand that decision better.

*Implementation and documentation reviewed on 25 September 2026. Screenshots show the original demonstration; product interfaces and access requirements can change.*