> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/infrastructure-as-code-management/troubleshooting-and-resources/use-cases.md). # How to govern infrastructure changes and track automation value with Harness IaCM How governance workflows, value and cost dashboards, and an MCP-powered editor assistant all read the same Harness IaCM execution data. Governance workflows for platform teams, cost and value dashboards for automation owners, and an MCP-powered assistant that brings both into the editor. Governing infrastructure change and proving the value of automation usually get treated as two different problems, owned by two different teams, tracked in two different tools. In Harness IaCM they are the same execution data, viewed two different ways. This topic walks through both views, plus how developers reach the same data without leaving their editor. {% hint style="info" %} **IN SHORT** Every infrastructure change in Harness IaCM is scanned, checked against policy, sized for impact, and gated by approval, automatically. Every pipeline run also rolls up into cost, value, and delivery dashboards, so automation owners can see what is running and what it is worth. Developers can ask about any of it, in plain language, from inside VS Code. {% endhint %} {% embed url="" %} *** ## What you will learn from this topic * **Governance for every change**: How a change is standardized at creation, checked against policy, sized for impact, and approved before it is applied. * **Automation value in practice**: How execution volume, delivery performance, value realized, utilization, and cost recommendations are reported from execution data. * **Access from the editor**: How the same governance and operational data is reachable as a conversation inside VS Code over MCP. *** ## Who this is for | Audience | What they see | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | Platform and ops teams | Governed workspace templates, policy creation, compliance monitoring, audit reporting, least-privilege enforcement, and change control workflows | | Automation tool owners | Operational dashboards, automation analytics, utilization optimization, and cost optimization recommendations | | Developers | Pipelines, drift, and audit data, reachable from the editor over MCP | *** ## Key terms | Term | What it means here | | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | Policy as code | Governance rules defined once and evaluated automatically on every run, instead of enforced by hand. | | Blast radius analysis | A map of exactly which resources a pending change will touch, generated before it is applied. | | DORA metrics | Four standard DevOps Research and Assessment delivery metrics: lead time to production, deployment frequency, mean time to restore, and failure rate. | | MCP | Model Context Protocol, which lets an assistant call real tools against live data rather than generate a guess from training data. | *** ## Governance for every change Every infrastructure change moves through the same governed path: standardized at creation, checked against policy, sized for impact, and approved before it is applied. Each step leaves a record behind it. Go to [the walkthrough](https://www.youtube.com/watch?v=Czfx8JVO_Gw) to watch this section. ### Governed workspace templates Platform teams publish a catalog of pre-approved templates, one per workspace type, each already wired to the right provider, repository, and starting configuration. A new workspace starts from one of these, not from a blank slate, so standardization happens by default rather than by review.
New workspace dialog open over a catalog of approved workspace templates, each card showing a template ID, scope, version, and last-updated date

Template catalog a new workspace is created from

### Policy creation Required fields, approved providers, and override permissions are defined once, on a workspace template. Every new workspace created from that template inherits the same rules, so governance does not depend on someone setting it up correctly by hand each time.
Workspace template configuration screen with per-field controls for whether a value can be overridden

Workspace template with per-field override controls

### Compliance monitoring Policy evaluations run automatically and roll up into a live dashboard: total evaluations, the pass and fail trend by day, and exactly which entities are currently failing or throwing a warning.
Policy evaluation dashboard showing total evaluations, a pass and fail trend by day, and tables of entities with errors and with warnings

Policy evaluation trend, with entities flagged for errors and warnings

### Audit reporting Before a change is applied, its full resource impact is broken out by type: **detected**, **added**, **changed**, **unchanged**, **removed**, and **imported**. That breakdown sits next to the policy and vulnerability checks that ran against the same plan.
Change inventory listing each affected resource by change type, with tabs for policy evaluations and vulnerability checks

Resource-level change inventory, with policy and vulnerability tabs

{% hint style="info" %} **WHY THIS MATTERS** This is the record a reviewer or auditor actually needs, generated automatically as part of the run rather than assembled after the fact when someone asks for it. {% endhint %} ### Least-privilege enforcement Blast radius analysis maps exactly which resources a change touches before it is applied, so a change that reaches further than it should gets caught before it ships, not after.
Blast radius graph for a pending change, showing the resources it will touch as connected nodes

Blast radius graph for a pending change

### Change control workflows Security scanning, plan review, and blast radius analysis run inside the pipeline automatically, with a manual approval step gating anything before it reaches Apply. Scan output and analysis stay attached to the run afterward.
Pipeline stage view showing steps for scanning, planning, blast radius analysis, approval, apply, and notification

Scan, plan, blast radius, approval, and apply as steps in one pipeline

Zoomed pipeline view highlighting the approval gate step next to a blast radius analysis panel, with security scan terminal output visible

The approval gate beside the blast radius panel, with scan output still attached to the run

*** ## Automation value in practice Once automation is running at scale, the questions change: how much is running, is it working, and what does it cost. These dashboards answer all three from the same execution data, without extra tracking work. Go to [the walkthrough](https://youtu.be/Czfx8JVO_Gw?si=PgSxIUJln3uLVpuM\&t=250) to watch this section. ### Operational dashboards Pipeline execution volume, trend, and success rate for the whole estate are available in one dashboard, rather than pieced together pipeline by pipeline.
Executive dashboard showing pipeline executions in the last 30 days, annualized executions, success rate, and week-over-week execution volume charts

Execution volume, trend, and success rate

### Automation analytics DORA metrics sit alongside monthly value realized and labor hours saved, broken down by organization and by project, so delivery performance and the reduction in manual work appear in the same view.
DORA metrics dashboard with charts for lead time to production, production deployment frequency, mean time to restore, and failure rate

Delivery metrics: lead time, deployment frequency, MTTR, and failure rate

Automation ROI dashboard showing monthly value realized as a total and as org and project breakdown donuts, above a labor savings chart trended against total pipeline runs by week

Monthly value realized and labor savings, full dashboard view

### Utilization optimization Cluster-level cost, forecasted cost, and a rolling efficiency score make it clear where compute is being paid for and not used.
Cluster costs and utilization dashboard with total and forecasted cost tiles, a utilized, idle, and unallocated cost breakdown, an efficiency score gauge, cost by cluster name, and an efficiency score trend over time

Cluster cost, trend, and efficiency score

### Cost optimization recommendations Each recommendation comes with a resource, a reason, and a projected monthly saving attached. You can turn one into a Jira ticket directly from the list, and track what it actually saves once it is applied.
Recommendations panel showing potential monthly savings and spend, with a table of resource-level recommendations, potential savings, and a Jira ticket status column with create-a-ticket actions

Recommendation queue with one-click Jira ticketing

*** ## Access from the editor None of the above is useful if developers have to leave their editor to get it. The same governance and operational data is reachable as a conversation, directly inside the IDE, over MCP. Go to [the walkthrough](https://youtu.be/Czfx8JVO_Gw?si=gbfcGR8ixEHiuVS5\&t=836) to watch this section. ### Editor sidebar The editor extension lists the pipelines a developer owns and puts a chat box next to them, ready as soon as the MCP connection shows as ready.
VS Code sidebar showing the Harness pipeline extension with a list of recent pipelines and an ask-about-this-pipeline chat box, with an MCP ready status indicator

Pipeline list and chat box, MCP ready

### Answers backed by live data Asking a question triggers a real tool call against live infrastructure state, not a canned response, so the assistant is reading the same resource data the platform team sees.
VS Code chat panel showing a live tool call in progress, querying infrastructure resource data

Live tool call against infrastructure data, in progress

### A worked example Asked what percentage of resources are drifted in a project, the assistant pulls the resource list, reports the drifted set, and explains what is driving the drift, down to the specific field that changed.
VS Code chat panel answering a question about drifted resources, listing the drifted set and naming the field that changed

Drift question, answered from live resource data

{% hint style="info" %} **WORTH KNOWING** The assistant chooses between multiple connected tools, such as an MCP-ready extension or a separate copilot without MCP configured. Only the MCP-connected option can query live infrastructure state. {% endhint %} *** ## Next steps * Go to [Governance workflows and the MCP-powered IDE assistant](/infrastructure-as-code-management/platform/policy-and-governance/governance-and-ide-assistant.md) for the full governance reference, including policy scope, audit streaming, and MCP setup. * Go to [Automation dashboards and value tracking](/infrastructure-as-code-management/platform/reports-and-insights/automation-value-dashboards.md) for the full dashboard reference, including permissions and how to act on a cost recommendation. * Go to [Harness MCP Server](/infrastructure-as-code-management/platform/platform-integrations/iacm-mcp.md) to install and configure the MCP Server for your IDE. * Go to [OPA Policies](/infrastructure-as-code-management/platform/policy-and-governance/opa-workspace.md) to write and attach policies to IaCM entities. {% @harness-feedback/feedback %}