> 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/platform/policy-and-governance/governance-and-ide-assistant.md).

# Governance workflows and the MCP-powered IDE assistant

Govern infrastructure changes with workspace templates, policy evaluation, blast radius analysis, and approval gates, then query the same data from your IDE over MCP.

Governance and developer experience are usually two different tools, owned by two different teams. In Harness IaCM they are the same underlying execution data viewed two ways: platform teams read it as policy evaluations, change inventories, and approval records, and developers read it as answers to questions asked from inside their editor.

This topic walks through the governance path a change travels: standardized at creation, checked against policy, sized for impact, and approved before apply. It then shows how the same data is reachable from inside the IDE over the Model Context Protocol (MCP), an open standard that lets an assistant call real tools instead of answering from training data.

{% embed url="<https://youtu.be/Czfx8JVO_Gw?t=836>" %}

***

## What you will learn from this topic

* **Policy creation**: How workspace templates lock platform requirements while leaving per-field overrides configurable.
* **Compliance monitoring**: How policy evaluations roll up into an account-wide trend and name the entities that are failing.
* **Audit reporting**: How the resource-level change inventory is generated as part of the run.
* **Least-privilege enforcement**: How blast radius analysis shows what a pending change will touch before it is applied.
* **Change control workflows**: How scanning, planning, risk analysis, approval, and apply are sequenced in one pipeline.
* **Editor integration**: How the Harness MCP Server answers questions about live infrastructure state from your IDE.

***

## Before you begin

Before you use this guide, ensure you have the following:

* **Harness account with IaCM enabled**: You need Infrastructure as Code Management under Infrastructure in Harness when it is entitled on your account.

{% hint style="info" %}
**CONTACT HARNESS SUPPORT**

If IaCM does not appear, contact your account administrator or [Harness Support](mailto:support@harness.io).
{% endhint %}

* **Pipeline permissions**: You need **View**, **Create/Edit**, and **Execute** for Pipelines. Go to [Harness RBAC](https://developer.harness.io/harness-platform/use-harness-platform/platform-access-control) to review role assignments.
* **A provisioned workspace**: Change inventories and blast radius analysis require a workspace with recorded state. Go to [Provision workspaces](/infrastructure-as-code-management/platform/workspaces/provision-workspace.md) to run a provisioning pipeline.
* **MCP setup, for the editor section only**: Harness AI enabled at the account level, the Harness MCP Server configured for your IDE, and a Harness API key with access to the relevant project. Go to [Harness MCP Server](/infrastructure-as-code-management/platform/platform-integrations/iacm-mcp.md) for the full setup.

***

## Policy creation

Governance starts at workspace creation. A workspace template defines the platform requirements once, and every workspace built from that template inherits them, so compliance does not depend on someone configuring it correctly by hand each time.

A parent template locks what the platform needs locked, typically:

* Cloud cost estimation settings.
* Naming conventions and tags.
* Approved provider versions.
* Default pipelines.
* The drift detection schedule.

Locking those fields does not force every child workspace to be identical. Variables that legitimately differ between environments stay configurable, using the same variable separation pattern as an ordinary workspace, with no need to fork the parent template.

<figure><img src="https://3575326923-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Ffhx6XzjvtJmfv5gPWZ5m%2Fuploads%2Fgit-blob-c6e8098a2ff7d722bc174e14deb8ce4b04eb9401%2Fiacm-workspace-template-overrides.jpg?alt=media" alt="Template configuration screen showing required environment and Terraform variables, with per-field override toggles"><figcaption><p>Required environment and Terraform variables, each with its own override toggle</p></figcaption></figure>

To add an environment-specific workspace, go to the workspace list, create a workspace, and select the parent template. The workspace is created with every locked setting already applied, and team-specific or environment-specific variables can be added on top. That is how one template replicates safely across many environment-specific workspaces instead of quietly becoming many slightly different copies of itself.

Go to [Workspace templates](/infrastructure-as-code-management/platform/workspaces/workspace-templates.md) to create a template and configure which fields are overridable.

Policies themselves are scoped the same way as the entities they govern. A policy created at account level applies to every organization and project beneath it, and a policy created at project level applies only inside that project, so a platform team can set a baseline centrally and leave narrower rules to the teams that own them. Go to [Harness Policy As Code overview](https://developer.harness.io/harness-platform/use-harness-platform/governance/policy-as-code/harness-governance-overview) for policy scope and inheritance across account, organization, and project levels.

Rego does not have to be written by hand. Harness AI generates a policy from a description of the rule in plain language, which lowers the cost of adding a new guardrail. Go to [Build policies using Harness AI](https://developer.harness.io/harness-platform/use-harness-platform/governance/policy-as-code/ai-for-policies) to use it, and note that it is gated behind a feature flag.

***

## Compliance monitoring

Policy as code means governance rules are defined once and evaluated automatically on every run, rather than enforced by hand at review time. Those evaluations roll up from individual pipelines into an account-wide view: total evaluations for the period, split into pass, error, and warning results, and trended daily.

The view does not stop at a count. **Entities with errors** and **entities with warnings** name the specific pipelines and secrets tripping policies most often, so a platform team knows which entity to fix rather than only that something, somewhere, failed.

<figure><img src="https://3575326923-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Ffhx6XzjvtJmfv5gPWZ5m%2Fuploads%2Fgit-blob-5ceb0b4a0f86e59725d76a8d00b47b1eff74f650%2Fiacm-policy-evaluation-dashboard.jpg?alt=media" alt="Policy as code dashboard showing evaluation totals, a daily evaluation trend chart, and tables of entities with errors and warnings"><figcaption><p>Evaluation totals and daily trend above the tables naming flagged entities</p></figcaption></figure>

This is the same evaluation engine that reports policy results on an individual pipeline run, aggregated across the account. Go to [OPA Policies](/infrastructure-as-code-management/platform/policy-and-governance/opa-workspace.md) to write and attach policies to workspaces.

***

## 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 evaluations and vulnerability checks that ran against the same plan.

<figure><img src="https://3575326923-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Ffhx6XzjvtJmfv5gPWZ5m%2Fuploads%2Fgit-blob-5af621f50d1cfa73af37d62c27cdc28eda700706%2Fiacm-change-inventory.jpg?alt=media" alt="Change analysis screen listing detected, added, changed, unchanged, removed, and imported resources with type and status columns, alongside tabs for policy evaluations and vulnerabilities"><figcaption><p>Resource rows by change type, with policy evaluation and vulnerability tabs alongside</p></figcaption></figure>

{% hint style="success" %}
**WHY THIS MATTERS**

This is the record a reviewer or an auditor needs, generated automatically as part of the run rather than assembled after the fact when someone asks for it.
{% endhint %}

The same tab shows drift findings. Scheduled or on-demand drift detection identifies changed resources and the specific attributes that changed, and those findings can feed the IaCM Remediation Agent, which generates infrastructure as code to bring unmanaged resources under management or initiates a governed reconciliation. Go to [Drift detection and ephemeral workspaces](/infrastructure-as-code-management/platform/workspaces/drift-ephemeral-workspaces.md) and [IaCM Remediation Agent](/infrastructure-as-code-management/platform/workspaces/remediation-agent.md) for those workflows.

Records that have to outlive the Harness audit log retention window, or be correlated with events from other systems, can be sent somewhere else. Audit logs stream to an external destination such as an Amazon S3 bucket or a SIEM tool, in JSON or NDJSON. Go to [Configure audit streaming](https://developer.harness.io/harness-platform/use-harness-platform/governance/audit-trail/audit-streaming) to add a streaming destination.

***

## Least-privilege enforcement

Access is scoped before a change is ever planned. Harness RBAC assigns roles to user groups and binds them to resource groups, so a team holds workspace permissions only on the workspaces it owns, at account, organization, or project scope. Go to [Workspace RBAC](/infrastructure-as-code-management/platform/workspaces/workspace-rbac.md) for the workspace permissions themselves, and to [RBAC in Harness](https://developer.harness.io/harness-platform/use-harness-platform/platform-access-control) for the role and resource group model.

Scoping governs who may change what. Blast radius analysis governs how far a permitted change reaches.

Blast radius analysis is a map of exactly which resources a pending change will touch, generated after the plan and before the apply. The AI Blast Radius Agent maps the dependencies between resources and then reasons over that map to identify downstream impact and change risk, expressed as a risk score.

The graph view renders the result: every resource the change deploys or touches, and how each relates to the other resources in the workspace. A change that reaches further than it should is caught before it ships rather than after.

<figure><img src="https://3575326923-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Ffhx6XzjvtJmfv5gPWZ5m%2Fuploads%2Fgit-blob-af6dd04859bf7127e636f48a3232ea727544047b%2Fiacm-blast-radius-graph.jpg?alt=media" alt="Node graph visualizing the blast radius of a change, with resources colored red, green, or gray to indicate risk"><figcaption><p>Resource dependency graph with nodes colored by assessed risk</p></figcaption></figure>

Go to [Analyze infrastructure risk with AI](/infrastructure-as-code-management/platform/iacm-pipelines/blast-radius-agent.md) to add and configure the agent step.

***

## Change control workflows

The controls above are sequenced in a single provisioning pipeline, so every change travels the same path:

1. **Security scanning**: Scanners run against the configuration before anything is planned. Harness supports Checkov and other open source and commercial scanners out of the box.
2. **Plan**: The OpenTofu or Terraform plan step produces the proposed change set, and plan diffs show what the change proposes to do.
3. **Blast radius analysis**: The agent step scores how high-risk the change is, immediately after the plan.
4. **Approval**: A Harness native approval step gates the change. ServiceNow and Jira approval gates are available from the step library, as are custom approval mechanisms, and they can be used alongside the native approval.
5. **Apply**: The apply step runs only after the approval is granted.

<figure><img src="https://3575326923-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Ffhx6XzjvtJmfv5gPWZ5m%2Fuploads%2Fgit-blob-529b2a88b0dd45ac7ef39e09642c9fde9d8a338d%2Fiacm-governed-pipeline-stages.jpg?alt=media" alt="Pipeline stage view showing steps for scanning, planning, blast radius analysis, approval, apply, and notification"><figcaption><p>Scan, plan, risk analysis, approval, apply, and notify as steps in one stage</p></figcaption></figure>

Context is what makes the approval meaningful. A single tab at approval time surfaces the cost estimation, any policy violations, and the blast radius analysis together, so whoever approves the change is looking at its actual consequences rather than a YAML diff.

<figure><img src="https://3575326923-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Ffhx6XzjvtJmfv5gPWZ5m%2Fuploads%2Fgit-blob-b0932405e83d241ca33217f9ce759341d0d95550%2Fiacm-approval-gate-blast-radius.jpg?alt=media" alt="Zoomed pipeline view highlighting the approval gate step next to a blast radius analysis panel, with a security scan terminal output visible"><figcaption><p>The approval gate beside the risk analysis panel, with scan output still attached to the run</p></figcaption></figure>

Conditional execution keeps the pipeline count down. In the advanced settings for a stage or a step, you can configure it to run only when specific conditions are met, which enforces a compliance gate for the cases that need it without hard-coding a separate pipeline per exception.

{% hint style="info" %}
**THE CONTROLS ARE THEMSELVES VERSION CONTROLLED**

OPA policies, asset governance rules, and RBAC assignments are stored as code, so a change to a governance rule goes through the same Git-based review and approval process as a change to infrastructure before it takes effect.
{% endhint %}

Go to [Approval step](/infrastructure-as-code-management/platform/iacm-pipelines/content/approval-step.md) to configure the approval gate and [Cost Estimation](/infrastructure-as-code-management/platform/workspaces/cost-estimation.md) to compare current and projected spend at approval time.

***

## Editor integration

None of the above helps a developer who has to leave the editor to reach it. MCP is what closes that gap, and the Harness MCP Server exposes IaCM data over it. The result is that the governance and operational data above is reachable as a conversation, inside the IDE.

### Sidebar assistant

The Harness VS Code extension lists the pipelines available in the project and puts a chat box next to them. The chat box does not answer the question itself. It routes the question to whichever AI tool is selected, and the tool picker reports the MCP status of each one, so it is clear before asking whether the answer will reach live infrastructure state.

<figure><img src="https://3575326923-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Ffhx6XzjvtJmfv5gPWZ5m%2Fuploads%2Fgit-blob-631264f1cedc3bf911897d5c08040b45e5d5a365%2Fiacm-vscode-sidebar-mcp.jpg?alt=media" alt="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"><figcaption><p>Recent pipelines above the chat box, with the MCP connection reporting ready</p></figcaption></figure>

### Answers backed by live state

Asking a question triggers real tool calls over the MCP Server, and the calls are visible as they run. The request resolves against the same knowledge graph that powers the agents in the Harness UI, which means the assistant reads the same resource data the platform team sees. Whether the question is asked from the IDE, the CLI, or the Harness UI, it reaches one graph through one governance layer.

<figure><img src="https://3575326923-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Ffhx6XzjvtJmfv5gPWZ5m%2Fuploads%2Fgit-blob-81031e4210a9dbf897d5d01e796cfad71e123975%2Fiacm-vscode-live-tool-call.jpg?alt=media" alt="VS Code chat panel showing a live tool call in progress, querying infrastructure resource data"><figcaption><p>A tool call in flight against live infrastructure data</p></figcaption></figure>

{% hint style="warning" %}
**LIVE STATE REQUIRES THE MCP CONNECTION**

Only a request that goes over the Harness MCP Server queries live infrastructure state. The tool picker labels each available assistant either **MCP ready** or **MCP not configured**, and the selected tool is named in the status bar alongside the same indicator. A tool listed as **MCP not configured** still answers, but it answers from training data, which reads as plausible without being accurate. Confirm the selected tool reports **MCP ready** before relying on an answer about infrastructure.
{% endhint %}

### Worked example: drift

A developer asks what percentage of the project has drifted. The assistant issues the tool calls and returns a reconciled answer rather than a single figure: the drifted workspaces by name, the state of every remaining workspace in the project, and the managed resource inside each drifted workspace.

The useful part is what it does with that data:

* **It separates real change from noise.** In this example the drift is identical in every affected workspace, confined to two metadata attributes that flipped from a null value to an empty map. That is a known provider artifact that a refresh clears, not a configuration change, and the answer says so.
* **It states the limit of its own answer.** Asked for a percentage of resources, it reports that a true resource-level percentage would require enumerating the resources in every remaining workspace, and offers to run that sweep rather than presenting a workspace-level figure as if it were a resource-level one.
* **It carries findings across domains.** Two of the drifted resources also hold an open cost recommendation, which the answer notes without being asked.

<figure><img src="https://3575326923-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Ffhx6XzjvtJmfv5gPWZ5m%2Fuploads%2Fgit-blob-c4bfe4224b87a53e8e84957e202b6dfd3a70c123%2Fiacm-vscode-drift-answer.jpg?alt=media" alt="VS Code chat panel showing a detailed answer to the question: what percentage of my resources are drifted within the Reference Architecture project, listing drifted resources and explaining the cause"><figcaption><p>A drift question answered from live resource data, with the cause identified per resource</p></figcaption></figure>

Follow-up questions drill into the same graph without switching tools, for example asking who ran the change that caused the drift. That attribution is pulled from the audit trail, which turns "something drifted" into a named user and a time.

Go to [Harness MCP Server](/infrastructure-as-code-management/platform/platform-integrations/iacm-mcp.md) for the full set of IaCM resource types exposed over MCP, the permissions each operation requires, and example prompts.

***

## Next steps

* Go to [OPA Policies](/infrastructure-as-code-management/platform/policy-and-governance/opa-workspace.md) to write and attach governance policies to workspaces.
* Go to [Workspace templates](/infrastructure-as-code-management/platform/workspaces/workspace-templates.md) to standardize workspace creation across an estate.
* Go to [Analyze infrastructure risk with AI](/infrastructure-as-code-management/platform/iacm-pipelines/blast-radius-agent.md) to add blast radius analysis to a pipeline.
* Go to [Automation dashboards and value tracking](/infrastructure-as-code-management/platform/reports-and-insights/automation-value-dashboards.md) to review how the same execution data is reported as cost and value.

{% @harness-feedback/feedback %}