The goal was simple: create a CloudOps assistant that can look at a live Azure environment, find operational issues, explain them clearly, use policy and runbook knowledge, generate safe remediation drafts, and still keep a human in control.

That last part matters. In CloudOps, a clever AI answer is not enough. A bad automation decision can delete data, open a network path, break monitoring, or create a change nobody approved. So the design principle for this project was:

AI can supervise and explain, but deterministic tools produce the facts and humans approve the changes.

This article describes the current working version of the lab: a Microsoft Foundry Agent connected to an Azure Function control plane through an OpenAPI tool.

The problem I wanted to solve

Cloud environments collect small problems over time.

Some resources are missing diagnostic settings. Some storage accounts do not have lifecycle policies. Some resources are missing ownership tags. App Services may still have FTP publishing enabled. Key Vaults may not have purge protection enabled. None of these issues always looks urgent on its own, but together they create weak visibility, weak governance, recovery gaps, and avoidable operational risk.

The manual review process is repetitive:

• collect inventory
• inspect resource configuration
• compare settings against expected policy
• create a report
• prepare remediation steps
• keep evidence
• ask for approval
• verify after changes

That is exactly the kind of workflow where AI can help, but only if the design is safe.

The main design decision

I did not want the model to directly inspect Azure or make infrastructure decisions by itself.

The architecture separates responsibilities:

• Microsoft Foundry Agent is the user-facing supervisor.
• Azure Function is the trusted tool backend.
• Deterministic analyzers create the findings.
• Policy and runbook documents ground the explanation.
• Azure OpenAI writes the summary and change-plan narrative.
• Evaluator Agent checks the final answer.
• Blob Storage keeps inventory, reports, remediation drafts, and responses.

The model explains and organizes the result, but the facts come from deterministic code.

High-level architecture

The current flow looks like this:

Microsoft Foundry Agent
→ OpenAPI tool call
→ Azure Function /api/tools/run-cloudops-review
→ Managed Identity
→ Azure Resource Manager REST API
→ Live Azure inventory
→ Deterministic analyzers
→ Blob-backed policy/runbook retrieval
→ Azure OpenAI grounded summary
→ Evaluator Agent
→ Blob artifacts

The Foundry Agent does not directly query Azure. It calls one safe tool:

run_cloudops_review

That tool is exposed by the Azure Function as an OpenAPI endpoint.

Why Azure Functions

Azure Functions worked well for this lab because the control plane needed to be small, serverless, and easy to expose as an HTTP tool.

The Function App handles:

• managed identity token acquisition
• Azure Resource Manager REST calls
• Blob Storage REST calls
• inventory collection
• analyzer orchestration
• policy/runbook retrieval
• Azure OpenAI calls
• response evaluation
• artifact upload

I kept the deployed control-plane path lightweight. Instead of packaging many Azure SDK dependencies into the Function, the Function uses REST APIs and the Python standard library for the main cloud calls. That made deployment simpler and reduced runtime issues.

Live Azure inventory collection

The Function App uses its managed identity to collect inventory from Azure Resource Manager.

The inventory is saved as JSON into Blob Storage. The current implementation reviews resource types such as:

• storage accounts
• Key Vaults
• App Services
• diagnostic-related resource settings
• public IPs
• network security groups
• managed disks
• virtual machines

The important point is that the review uses live Azure data. The Foundry Agent is not guessing from memory or from a static file.

Deterministic analyzers

The LLM does not create the findings.

The analyzer code inspects the inventory and creates structured findings. Current finding types include:

• MissingDiagnosticSettings
• MissingRequiredTags
• StorageWithoutLifecyclePolicy
• StorageBlobSoftDeleteDisabled
• KeyVaultPurgeProtectionDisabled
• AppServiceFtpEnabled

Each finding includes resource details, severity, domain, remediation action, and approval requirement.

This is one of the most important parts of the design. The model can summarize the findings, but the findings themselves come from deterministic logic.

Policy and runbook grounding

The project uses a simple Blob-backed knowledge layer.

Policy and runbook Markdown files are stored in the rules container. Examples include:

• diagnostic-settings-policy.md
• key-vault-protection-policy.md
• app-service-security-policy.md
• storage-soft-delete-policy.md
• storage-lifecycle-policy.md
• tagging-policy.md
• remediation-safety-policy.md
• cost_optimization.md

The Knowledge Agent retrieves relevant documents based on the finding types and analysis domains. Those retrieved policy snippets are included in the Azure OpenAI prompt.

This is intentionally simple for the current version. Blob keyword retrieval is easy to understand, cheap, and good enough for a lab. A future version can replace it with Azure AI Search for hybrid or vector retrieval.

Azure OpenAI summary

Azure OpenAI is used to turn structured results into a useful human-readable review.

The model receives:

• the user request
• the deterministic finding summary
• compact findings
• retrieved policy/runbook knowledge
• report path
• safety instructions

It produces a summary that explains what was found, which items matter most, what policies apply, and what should happen next.

The model does not execute remediation. It does not create findings. It does not bypass approval.

Evaluator Agent

After the summary is generated, the Evaluator Agent checks the response.

The evaluator verifies that:

• the total finding count is present
• approval language is present
• the answer does not claim remediation was executed
• the answer does not include unsafe destructive commands
• retrieved policy/runbook knowledge is referenced
• major finding types are mentioned

A passing result looks like this:

{
  "agent": "EvaluatorAgent",
  "overall_status": "pass",
  "failed_checks": 0,
  "warning_checks": 0
}

This gives the project a safety gate between model output and the final response.

Safe workflow

The review workflow is designed around human approval.

The system can generate remediation drafts, but those drafts stay in PendingApproval.

The workflow is:

User request
→ Foundry Agent
→ run_cloudops_review tool
→ Live Azure inventory
→ Deterministic findings
→ Policy-grounded AI summary
→ Evaluator checks
→ Draft remediation scripts
→ PendingApproval
→ Human review
→ Manual execution
→ Verification

This keeps the system useful without making it reckless.

Foundry Agent integration

The final step was connecting the control plane to Microsoft Foundry Agent Service.

The Foundry Agent is configured with:

• instructions
• an OpenAPI tool definition
• a custom key connection for the Azure Function key
• the run_cloudops_review tool

One practical note: model and tool compatibility matters. The model that worked well for direct Azure OpenAI summaries was not the best choice for OpenAPI tool calling in Foundry. I used a model compatible with custom tools for the Foundry Agent.

Once configured, the user can ask:

Run a safe CloudOps review of my Azure subscription.
Use live inventory, policy/runbook knowledge, and evaluator checks.
Do not execute remediation.

The Foundry Agent calls the tool, receives the compact result, and presents the final review.

Example result

In one test run, the tool returned:

Total findings: 25
By type:
- AppServiceFtpEnabled: 1
- KeyVaultPurgeProtectionDisabled: 1
- MissingDiagnosticSettings: 8
- MissingRequiredTags: 6
- StorageBlobSoftDeleteDisabled: 4
- StorageWithoutLifecyclePolicy: 5
EvaluatorAgent: pass
Remediation executed: false
Approval required: true

The answer also referenced the retrieved policy/runbook sources and kept all changes in PendingApproval.

Artifacts and auditability

The system saves artifacts to Blob Storage:

• inventory JSON
• Markdown CloudOps report
• remediation draft scripts
• agent response JSON
• final answer text

This is important because CloudOps work should be auditable. A chat answer by itself is not enough. The review needs evidence, repeatability, and a trail from request to recommendation.

Lessons learned

A few lessons stood out while building this:

1. Agentic does not mean uncontrolled.
2. Deterministic analyzers should produce the facts.
3. LLMs are useful for explanation, prioritization, and narrative.
4. Simple policy grounding is already valuable.
5. Evaluating the model response is worth the extra step.
6. Foundry Agents are useful as supervisors when the tool boundary is clear.
7. Managed identity is better than putting Azure credentials in code.
8. Tool/model compatibility in Foundry should be checked early.

What I would improve next

The current version works, but there are several natural next steps:

• Add Azure AI Search for stronger policy/runbook retrieval.
• Store proposed actions as structured approval records.
• Add a lightweight approval dashboard.
• Add before/after verification as an Azure-hosted endpoint.
• Add scheduled CloudOps reviews.
• Add Teams or email notification for completed reviews.
• Add more analyzers for networking, cost, backup, and reliability.
• Replace Function key authentication with Entra ID protected API and managed identity.
• Add GitHub Actions deployment.

Final thoughts

This project started as a practical experiment: can an AI agent help with CloudOps without becoming unsafe?

The answer is yes, if the architecture is designed correctly.

The model should not be the source of truth. The model should not directly execute infrastructure changes. The safe pattern is to put deterministic tools behind a controlled API, use managed identity for Azure access, ground the explanation in policy, evaluate the final response, and keep a human approval step for remediation.

That is the pattern I used here:

Microsoft Foundry Agent
→ OpenAPI tool
→ Azure Function control plane
→ Managed Identity live inventory
→ deterministic analyzers
→ policy/runbook grounding
→ Azure OpenAI summary
→ Evaluator Agent
→ auditable artifacts

It is not a production product yet, but it is a solid foundation for a real AI-assisted CloudOps workflow.

View project on GitHub