Azure FinOps Agent
Plain answers on AI governance, AI costs and your Azure spend.
Azure FinOps Agent is an open-source AI agent for Azure. Ask it in plain words how to govern your AI agents, how to budget and cap AI spend, or what an Azure setup will cost. It answers from current Microsoft documentation and live Azure prices, and shows every call behind the answer. Connect your Azure tenant and it works with your own costs, budgets and resources: it finds savings, scores your FinOps maturity and drafts the fix, using only your own permissions. It never deletes Azure resources.
Try it now · Deploy to your Azure · Slides
See it in action
The panel on the right lists every call behind an answer, so you can check where each figure came from; on a phone, the call count under an answer opens it. The screenshots are real answers; prices and guidance change over time.
What you can ask
Without signing in
The start page offers the questions customers ask most:
| Govern AI agents | Control AI spending | Compare Azure prices |
|---|
| How do I find all our AI agents? | How do we budget and justify AI? | What will my 3-tier app cost? |
| What does E7 add for AI agents? | Which AI model is best value? | Which region is cheapest for a VM? |
| How do we audit what agents do? | Who is spending what on AI? | Which database is cheapest? |
| Agent 365, Foundry or API Center? | Can we cap AI spending? | Which storage tier is cheapest? |
| Can we allow only approved models? | Why don't costs match my invoice? | Reservation or savings plan? |
You can also ask your own question about Azure prices or service health, or upload a CSV, TSV, JSON, Excel, PDF, Parquet, text or image file and ask about it. The demo data has samples to try.
After you connect Azure
- Spend: costs by service, subscription, resource group, tag and region, with forecasts and budgets.
- Savings: Azure Advisor, reservations and savings plans, and idle or orphaned resources.
- Maturity: a Crawl, Walk and Run FinOps score, with the evidence behind each rating.
- More data, with your consent: Microsoft 365 licenses and Copilot usage (Microsoft Graph), Log Analytics and Application Insights queries, and cost exports in Azure Storage. Each needs its own consent.
- Scheduled jobs: rerun a check on a schedule, such as a daily cost digest, a budget guard or an anomaly watch.
- Deliverables: charts, Excel and CSV reports, HTML presentations, and Azure CLI, PowerShell, Bicep or ARM scripts for you to review.
- Approved changes: for a change such as a tag or a budget, you see the exact request and approve it before it runs.
The agent acts with your own delegated permissions, so your Azure roles and the consents you grant set the limit. Deletes and other destructive actions are blocked in code; for those, it writes a script that you review and run yourself.
Answers you can check
- Sources and freshness: figures come from calls you can see, with their source and retrieval time. Billed costs, budget snapshots, list prices and estimates are kept apart.
- Unknown is not zero: missing data, failed calls and partial coverage are stated, never shown as zero.
- Activity is not savings: a Copilot license with no reported activity, for example, is not proof that removing it saves money.
- Real files: scripts and reports are real downloads tied to your session, kept for 24 hours.
- Done is not solved: a finished answer is not proof the problem is fixed; proposed changes still need your approval.
The tool and prompt catalog documents the agent's 16 tools, the two Microsoft Learn documentation tools it uses, and their limits, and reliability contracts describe how answers are verified.
Feedback
Have feedback? in the top bar, the link under the message box and the Feedback button under every answer open one form: a type (bug, idea, answer quality, other), a summary and optional details. Feedback about an answer can include the question it answered, and only when the user ticks the box. After a Poor answer rating the button asks what went wrong.
The form posts a public GitHub issue labelled feedback, so it refuses secrets, IDs, email addresses and IP addresses before anything is sent, and it stops @mentions from notifying anyone. Each browser can create 3 issues in 10 minutes and 10 a day. The server creates issues through a GitHub App. It signs a short-lived token with the app's private key and exchanges it for an installation token limited to Issues: write on one repository. Neither the key nor a token reaches the browser. Without a GitHub App, the form opens the repository's feedback issue form with the feedback filled in, and users post it with their own GitHub account.
To create issues directly in your deployment:
- Register a GitHub App with the repository permission Issues: Read and write, no webhook, and generate a private key.
- Install it on the repository that should receive the issues.
- Run
azd env set GITHUB_FEEDBACK_APP_ID <client-id>, azd env set GITHUB_FEEDBACK_PRIVATE_KEY <base64 of the .pem> and, for a repository other than this sample, azd env set GITHUB_FEEDBACK_REPOSITORY <owner/name>, then run azd provision. Locally, set GitHubFeedback:AppId, GitHubFeedback:PrivateKey and GitHubFeedback:Repository with dotnet user-secrets.
A repository other than this sample needs a copy of .github/ISSUE_TEMPLATE/feedback.yml and a feedback label, so the fallback link can fill in the form and label the issue.
Graded before it ships
Every deployment is blocked until 23 live AI scenarios all pass: real model calls through the same chat handler and tools users reach, against real Azure APIs, each answer graded by a separate judge model and by hard checks (the right tools, no unrecovered tool failures, time and call budgets). A report of the ten most important evals beyond it runs weekly and on demand and shows each one red or green: the start-page questions customers ask most, the cost questions closest to a FinOps team's day, safety guarantees (it never deletes anything, treats instructions hidden in pasted text as data and never reveals tokens) and another language. The run graph is the picture (a plan, four stage boxes and a scoreboard, each green or red), and every result says what the eval checks, what happened, what the judge scored and why. Open the latest run's summary for the heatmap, or download its HTML dashboard from the run's artifacts. See live evaluations.
How it works
flowchart LR
User --> UI[Vue 3 SPA]
UI --> API[.NET 10 API]
API --> Agent[Microsoft Agent Framework]
API --> Jobs[Job scheduler]
Jobs --> Agent
Agent --> Model[Foundry project Responses API]
Agent --> Tools[Host tools]
Tools --> ARM[ARM and Cost Management]
Tools --> Graph[Microsoft Graph]
Tools --> Logs[Log Analytics]
Tools --> Public[Retail Prices and Microsoft Learn]
Entra[Microsoft Entra ID] --> API
The app runs as one Linux container on Azure App Service. The Azure Developer CLI provisions Azure Container Registry, a Microsoft Foundry account and project, monitoring, managed identities, role assignments, App Service and, optionally, the Entra app registration for sign-in.
The agent can use only its registered tools, plus the model's hosted web search for recent public information (on by default). Search queries leave the Azure data boundary; set AZURE_OPENAI_WEB_SEARCH=false before azd up to turn it off. There is no shell, file system or code execution. Run one active instance, because session and throttling coordination is process-local.
Deploy to your Azure subscription
Prerequisites
- Azure CLI
- Azure Developer CLI
- An Azure subscription where you can create resources and role assignments
- Permission to create an Entra app registration, or an existing app registration to reuse
Deploy
az login --tenant <tenant-id>
az account set --subscription <subscription-id>
azd auth login
azd up
azd up asks for an environment name and region, provisions the stack, builds the image in Azure Container Registry and prints the app's URL. To reuse existing resources or change defaults, use azd env set; see Azure deployment permissions and azure.yaml.
Remove the deployment with:
azd down --purge
Run locally
Prerequisites
Your Azure CLI identity also needs Foundry User (formerly Azure AI User) on the Foundry account that hosts the project. Cognitive Services OpenAI User covers only the account's OpenAI endpoints, not the project Responses endpoint, and management roles such as Owner don't include model-inference permissions. This is separate from signing in to your Azure tenant in the browser; see local model authorization.
Configure
cd src\backend
dotnet user-secrets set "AzureOpenAI:Endpoint" "https://<account>.services.ai.azure.com/api/projects/<project>"
dotnet user-secrets set "AzureOpenAI:DeploymentName" "<your-deployment>"
Optional settings:
AzureOpenAI:TenantId when the model is in a different tenant from the Azure CLI defaultAzureOpenAI:ProjectName if AzureOpenAI:Endpoint is the account endpoint rather than the project endpointMicrosoft:ClientId, Microsoft:ClientSecret and Microsoft:TenantId to enable Azure sign-in locallyApplicationInsights:ConnectionString for telemetry
Build and run
cd src\frontend
npm ci
npm run build
cd ..\backend
$env:ASPNETCORE_ENVIRONMENT = "Development"
dotnet run --urls http://localhost:5000
Open http://localhost:5000. Build the frontend before starting the backend, so the static web root (src/backend/wwwroot) exists at startup. The contributor guide covers the backend, Python, frontend and desktop/mobile browser regression tests.
For maintainers
/evaluate-sessions exports the last 30 days of real conversations, rates each one from 0 to 10, finds the ten most important issues and their root causes in the code, and asks which to fix before implementing regression-tested local fixes. It never impersonates users, commits customer transcripts or deploys on its own./investigate-logs triages exceptions in Application Insights.npm run og-image in src/frontend re-renders the social sharing card from its HTML source.
Security
- OAuth uses PKCE, nonce validation, incremental delegated consent and explicit resource scopes.
- The user's Azure roles (RBAC) and consented scopes remain the authorization boundary.
- Azure
DELETE and mutating action POST operations are blocked in code.
- Generated downloads and conversation transcripts are checked against their owner.
- Changes through Azure Resource Manager need explicit approval in the app; chat text and scheduled prompts can't approve them.
- Budget figures can lag billing, and quota or placement evidence doesn't guarantee capacity.
- Keep production secrets in managed identities, App Service settings or GitHub Actions secrets, never in source control.
- The feedback form's GitHub App key stays on the server. Each issue uses an installation token limited to Issues: write on one repository, and submissions with secrets, IDs, email addresses or IP addresses are refused.
See SECURITY.md to report a vulnerability and session management for how sessions behave.
Contributing
See CONTRIBUTING.md, SUPPORT.md and the Code of Conduct.
Contact
Questions about this sample or delivering it for your organization: contact the maintainer, Ali Reza Farahnak on LinkedIn. Report bugs and feature requests with the app's Have feedback? button or as GitHub issues.
License
MIT
