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.
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.
Pipeline permissions: You need View, Create/Edit, and Execute for Pipelines. Go to Harness RBAC to review role assignments.
A provisioned workspace: Change inventories and blast radius analysis require a workspace with recorded state. Go to Provision workspaces 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 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.
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 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 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 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.
This is the same evaluation engine that reports policy results on an individual pipeline run, aggregated across the account. Go to OPA Policies 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.
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.
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 and IaCM Remediation Agent 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 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 for the workspace permissions themselves, and to RBAC in Harness 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.
Go to Analyze infrastructure risk with AI 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:
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.
Plan: The OpenTofu or Terraform plan step produces the proposed change set, and plan diffs show what the change proposes to do.
Blast radius analysis: The agent step scores how high-risk the change is, immediately after the plan.
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.
Apply: The apply step runs only after the approval is granted.
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.
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.
Go to Approval step to configure the approval gate and Cost Estimation 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.
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.
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.
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.
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 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 to write and attach governance policies to workspaces.
Go to Workspace templates to standardize workspace creation across an estate.
Go to Analyze infrastructure risk with AI to add blast radius analysis to a pipeline.
Go to Automation dashboards and value tracking to review how the same execution data is reported as cost and value.
Last updated
Was this helpful?