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.

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.

How to govern infrastructure changes and track automation value with HarnessYouTube

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 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

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

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

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

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.

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

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

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

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 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

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

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

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

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

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 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

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

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

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.

Next steps

Go to Governance workflows and the MCP-powered IDE assistant for the full governance reference, including policy scope, audit streaming, and MCP setup.
Go to Automation dashboards and value tracking for the full dashboard reference, including permissions and how to act on a cost recommendation.
Go to Harness MCP Server to install and configure the MCP Server for your IDE.
Go to OPA Policies to write and attach policies to IaCM entities.

PreviousFAQ

Last updated 19 days ago

Was this helpful?