> 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/harness-platform/use-harness-ai/core-capabilities/in-your-pipelines/worker-agent/harness-managed-agents.md).
# Harness Managed Worker Agents
Reference for Harness Managed Worker Agents, including inputs, runtime behavior, and outputs for each agent.
Harness Managed Worker Agents are maintained and versioned by Harness, and are loaded into your account by default. Use them from the **Marketplace** tab of the Worker Agent Catalog without writing a prompt or container definition.
## Available agents
| Agent | What it does | Writes to your repository |
| ----------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | --------------------------------------------------------------- |
| [Auto-Remediation](#auto-remediation) | Fixes SAST and secret findings from an STO scan and validates the fix. | Yes. Opens one pull request. |
| [CI Failure Autofix](#ci-failure-autofix) | Finds the root cause of a failed CI run and fixes it in code. | Yes. Commits and pushes to a branch. |
| [Code Coverage Generation](#code-coverage-generation) | Writes unit tests to close coverage gaps. | Yes. Commits and pushes to a branch. |
| [Code Review](#code-review) | Reviews a pull request and posts comments, an overview, and suggested reviewers. Coming soon. | No. Posts comments on the pull request. |
| [Container and Dependency Remediation](#container-and-dependency-remediation) | Fixes vulnerable base images and package dependencies from a container scan. | Yes. Opens separate pull requests for base images and packages. |
| [Database Impact Analysis](#database-impact-analysis) | Checks a SQL change for zero-downtime safety and returns a pass or fail verdict. | No. |
| [Feature Flag Cleanup](#feature-flag-cleanup) | Removes a stale feature flag and keeps the chosen treatment. | Yes. Commits and pushes to a branch. |
| [Kubernetes Manifest Remediation](#kubernetes-manifest-remediation) | Analyzes a failed Kubernetes or Helm deployment and writes a remediation report. | No. Recommends changes only. |
## What you will learn from this topic
By the end of this topic, you will be able to:
* [Find a Harness Managed Worker Agent in the catalog](#find-a-harness-managed-worker-agent).
* [Configure and run the Auto-Remediation agent](#auto-remediation).
* [Configure and run the CI Failure Autofix agent](#ci-failure-autofix).
* [Configure and run the Code Coverage Generation agent](#code-coverage-generation).
* [Configure and run the Code Review agent](#code-review).
* [Configure and run the Container and Dependency Remediation agent](#container-and-dependency-remediation).
* [Configure and run the Database Impact Analysis agent](#database-impact-analysis).
* [Configure and run the Feature Flag Cleanup agent](#feature-flag-cleanup).
* [Configure and run the Kubernetes Manifest Remediation agent](#kubernetes-manifest-remediation).
* [Understand what each step of an agent does and which outputs it produces](#how-the-container-and-dependency-remediation-agent-works).
## Before you begin
* **Worker Agents enabled**: Harness AI and Worker Agents must be enabled in your account. Go to [Worker Agent](/harness-platform/use-harness-ai/core-capabilities/in-your-pipelines/worker-agent.md) for details.
* **Pipeline permissions**: **View**, **Create/Edit**, and **Execute** permissions for pipelines in your project.
* **Model Connector**: An Anthropic or OpenAI connector, or a [Harness-managed LLM connector](/harness-platform/use-harness-ai/core-capabilities/in-your-pipelines/worker-agent/configuration.md#configure-model-connectors).
## Find a Harness Managed Worker Agent
1. From the **Module Selector**, go to **AI** and select **Worker Agents**.
2. Select the **Marketplace** tab.
3. Filter by the **Harness Managed** category.
4. Select an agent to view its description, version, status, and YAML definition.
Go to [Agent categories](/harness-platform/use-harness-ai/core-capabilities/in-your-pipelines/worker-agent.md#agent-categories) to compare Harness Managed Worker Agents with Harness Certified and Community agents.
## Auto-Remediation
| Property | Value |
| -------------------- | ------------------ |
| **Agent identifier** | `remediationAgent` |
| **Author** | Harness |
| **Version** | 1.0.2 |
The Auto-Remediation agent remediates SAST and secret findings from a selected STO scan, or from the latest succeeded scan on the same pipeline execution. It generates fixes with an LLM, validates the fix branch, and opens one pull request.
### Auto-Remediation use cases
* **Fix findings right after a scan**: Place the agent after a SAST or secret scan step and leave **Scan ID** and **Target Name** empty. The agent remediates the findings from that execution and opens a pull request, so developers review a proposed fix instead of a ticket.
* **Remediate on scan completion**: Run the agent from a scan-completion event so every completed scan on a target is remediated without a manual pipeline run.
* **Clear a backlog for a target**: Set **Target Name** and, optionally, **Target Variant** to remediate the findings of a specific application or branch variant on demand.
* **Remediate one scan**: Set **Scan ID** to fix the findings of a scan that you are investigating, such as a release candidate scan.
* **Prioritize by risk**: Limit **Issue Types** and **Severities**, for example `SECRET` with `CRITICAL` and `HIGH`, to fix the highest risk findings first.
* **Prove the fix before review**: Set **Scan Validation Pipeline** and **Build Validation Pipeline** so the agent re-scans and builds the fix branch, and retries up to **Max Fix Attempts**, before it opens the pull request.
### Auto-Remediation prerequisites
* **STO scan**: A completed scan in Security Testing Orchestration (STO) that reports SAST or secret findings.
* **LLM connector**: A connector in the **AI** category. Required. The agent's sub-agents require an Anthropic (Claude) backend today.
* **SCM connector (optional)**: A GitHub, GitLab, Git, Bitbucket, or Azure Repos connector. Leave it unset to use Harness Code. A worker run does not inherit the connector from the remediation configuration. When a scan-completion event starts the pipeline, Harness fills this value from the remediation configuration.
* **Validation pipelines (optional)**: A scan pipeline that re-scans the fix branch and a build pipeline that builds it. Both must be in the same project as the agent pipeline.
### Add Auto-Remediation to a pipeline
1. Open your pipeline in the Pipeline Studio.
2. Click **Add Step** in the stage execution panel, select **Agents**, then select **Agent**.
3. Enter a **Name** and select **Auto-Remediation** from the **Agent** list.
4. Select a **Version**, or choose **Always use stable**.
5. Configure the [inputs](#auto-remediation-inputs).
6. Click **Apply Changes**.
{% hint style="info" %}
**CHOOSE THE SCAN TO REMEDIATE**
Set **Scan ID** to remediate a specific scan. Set **Target Name** to look up a target in the pipeline project. If you leave **Scan ID** and **Target Name** empty, the agent uses the latest succeeded scan on the current pipeline execution, so place the step after the scan step.
{% endhint %}
### Auto-Remediation inputs
| Input | Required | Default | Description |
| ------------------------------------------------ | -------- | ------- | ------------------------------------------------------------------------------------------------------------------------- |
| **Scan ID** (`scan_id`) | No | Empty | An STO scan ID. The account, organization, and project are taken from the scan. |
| **Target Name** (`target_name`) | No | Empty | The STO target name that a scan step uses, for example `nodegoat_12345`. The target is looked up in the pipeline project. |
| **Target Variant** (`target_variant`) | No | Empty | A variant ID or name. Leave empty to use the target baseline variant. |
| **Issue Types** (`scan_types`) | Yes | None | One or more of `SAST` and `SECRET`. |
| **Severities** (`severity_types`) | Yes | None | One or more of `CRITICAL`, `HIGH`, `MEDIUM`, `LOW`, and `INFO`. |
| **LLM Connector** (`llm_connector`) | Yes | None | The connector used to generate fixes. |
| **SCM Connector** (`scm_connector_ref`) | No | Unset | The source control connector. Leave unset to use Harness Code. |
| **Scan Validation Pipeline** (`scan_pipeline`) | No | Empty | The pipeline that re-scans the fix branch. |
| **Build Validation Pipeline** (`build_pipeline`) | No | Empty | The pipeline that builds the fix branch. |
| **Max Fix Attempts** (`max_fix_attempts`) | No | `5` | The number of fix and validate iterations in the joint scan and build loop. One attempt is a single validation round. |
If you leave both validation pipelines empty, the agent uses the validation pipelines from the code repository or project agent configuration. If none is configured, the pull request opens without validation.
Every input accepts a fixed value, a runtime input, or an expression.
### How the Auto-Remediation agent works
| Step | What it does |
| ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Scope** | Resolves the scan, target, and findings in scope, up to 300 occurrences, and resolves the validation pipelines. If no findings are in scope, the outcome is `ZERO_IN_SCOPE` and the remaining steps are skipped. |
| **Remediate** | Runs the AI agent with 8 GiB of memory and 4 CPUs, up to 1,200 turns. The agent fixes the findings, validates the fix branch through the scan and build pipelines, and opens one pull request. A failure in this step does not fail the stage. |
| **Persist** | Records the remediation result against the scan. Runs unless the outcome is `ZERO_IN_SCOPE`. |
Each step has a one-hour timeout.
### Auto-Remediation output variables
The **Scope** step publishes the following output variables, which the later steps consume.
| Variable | Description |
| --------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| `outcome` | The scoping result. `ZERO_IN_SCOPE` means no findings matched. |
| `workflowExecutionId` | The remediation execution identifier. |
| `accountId`, `orgId`, `projectId` | The scope of the selected scan. |
| `scanId`, `targetId`, `targetName`, `targetVariantName` | The resolved scan and target. |
| `originalOccurrenceCount` | The number of occurrences in scope. |
| `scmProvider`, `repoUrl`, `baseBranch`, `scmConnectorRef` | The resolved repository details. |
| `issueTypes`, `severityTypes` | The resolved selection criteria. |
| `scanPipelineId`, `buildPipelineId` | The resolved validation pipelines, with matching `*Org`, `*Project`, and `*InputSet` variables. |
Go to [Agent step expands to a step group at runtime](/harness-platform/use-harness-ai/core-capabilities/in-your-pipelines/worker-agent/worker-agent-in-pipeline.md#agent-step-expands-to-a-step-group-at-runtime) for the expression syntax.
### Auto-Remediation troubleshooting
The agent finishes without opening a pull request
Check the **Scope** step output. If `outcome` is `ZERO_IN_SCOPE`, no findings matched the selected issue types and severities. Add issue types or severities, then run the pipeline again.
## CI Failure Autofix
| Property | Value |
| -------------------- | -------------- |
| **Agent identifier** | `autofixAgent` |
| **Author** | Harness |
| **Version** | 1.0.0 |
The CI Failure Autofix agent identifies the root cause of a failed CI pipeline execution, applies a targeted fix to the code, and commits the fix to a branch.
### CI Failure Autofix use cases
* **Fix a failing build automatically**: Run the agent when a pipeline fails so that a fix is waiting on the branch when the developer returns.
* **Fix compile, lint, and test failures**: The agent reads the execution details and step logs, identifies the failing stage, step, and command, and fixes the cause in code.
* **Keep fixes small**: The agent applies the smallest change that resolves the failure and does not refactor unrelated code.
* **Fix a past failure**: Set **Failed Execution ID** and **Source Pipeline ID** to remediate an earlier run, such as one that failed overnight.
### CI Failure Autofix prerequisites
* **LLM connector**: A connector in the **AI** category, such as Anthropic or Bedrock. Required.
* **MCP connectors**: One or more MCP connectors for Harness and source control operations, such as Harness Code MCP or GitHub MCP. The agent uses them to read execution details and logs, read the repository, check the diff, commit, and push.
* **Repository context**: Run the agent after a clone codebase step, or set **Repository** and **Branch** explicitly. When you leave the inputs empty, the agent reads the values from runtime environment variables such as `$DRONE_REPO_LINK` and `$DRONE_BRANCH`, or from the execution metadata.
* **Write access**: The SCM connector must be able to push to the target branch.
### Add CI Failure Autofix to a pipeline
1. Open your pipeline in the Pipeline Studio.
2. Click **Add Step** in the stage execution panel, select **Agents**, then select **Agent**.
3. Enter a **Name** and select **CI Failure Autofix** from the **Agent** list.
4. Select a **Version**, or choose **Always use stable**.
5. Configure the [inputs](#ci-failure-autofix-inputs).
6. Click **Apply Changes**.
The agent step always runs. By default, it uses the execution and pipeline that it runs in, so it analyzes a failure from the same execution when you place it in a stage that runs after the failure, for example with a failure condition. To analyze a different run, set **Failed Execution ID** and **Source Pipeline ID**.
### CI Failure Autofix inputs
| Input | Required | Default | Description |
| --------------------------------------------- | -------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **LLM Connector** (`llm_connector`) | Yes | None | The connector the agent uses to call the model. |
| **Model Name** (`model_name`) | Yes | None | The Anthropic or Bedrock model identifier, or an inference profile ARN. |
| **MCP Connectors** (`mcp_connectors`) | No | None | The MCP connectors to mount for Harness and source control operations. |
| **Failed Execution ID** (`execution_id`) | No | Empty | The execution ID of the failed run to remediate. Leave empty to use `$HARNESS_EXECUTION_ID`. |
| **Source Pipeline ID** (`source_pipeline_id`) | No | Empty | The identifier of the pipeline that contains the failed execution. Leave empty to use `$HARNESS_PIPELINE_ID`. |
| **Repository** (`repo`) | No | Empty | The repository identifier: `org/repo` for GitHub-style providers, or the full repository path for Harness Code. Leave empty to derive it from the runtime SCM environment variables. |
| **Branch** (`branch`) | No | Empty | The branch to commit the fix to. Leave empty to use `$DRONE_BRANCH`. The agent confirms that the branch exists through the SCM MCP connector before it commits. |
Every input accepts a fixed value, a runtime input, or an expression.
### How the CI Failure Autofix agent works
The agent runs a single step, **Run Autofix Agent**, that always runs and is limited to 150 turns. The agent works autonomously and follows these steps:
1. Resolves the execution, pipeline, repository, and branch from the inputs, then from runtime environment variables, then from MCP tools. It fails with a message if a value is missing.
2. Fetches the execution details and step logs through the MCP tools, and identifies the failed stage and step, the failing command, and the error output.
3. Confirms that the repository is checked out in `/harness` on the target branch, and clones it if it is missing.
4. Reads the relevant code to understand the failure before it edits anything.
5. Applies the smallest targeted fix for the root cause.
6. Runs the linters, type checkers, build commands, and tests that the repository defines, and fixes errors that its change introduces.
7. Reviews the diff to confirm that it contains only the fix.
8. Stages only the changed files, makes one commit with the message `Autofix: harness-auto-fix created this fix`, and pushes it to the branch.
9. Prints a summary with the branch, the staged files, and the commit SHA.
The agent uses MCP tools first. If an MCP call keeps failing after a few retries, it falls back to Git commands in the step container.
### CI Failure Autofix safety rules
The agent commits directly to your branch, so it follows these rules:
* It stages files one at a time and never stages by directory or with `git add -A`.
* It makes exactly one commit per run.
* It works only with the commit that was cloned and never pulls, rebases, or merges new commits from the remote.
* It never force pushes. If the push is rejected, it undoes the local commit, prints the rejection, and exits with an error so that a person can resolve it.
* It never prints secrets, tokens, or credentials.
{% hint style="warning" %}
**REVIEW THE COMMIT**
The agent pushes to the branch you specify. Run it against a feature branch, or protect the branch with required reviews, so that a person reviews the fix before it merges.
{% endhint %}
### CI Failure Autofix troubleshooting
The push is rejected
Another commit reached the remote branch, or branch protection blocked the push. The agent undoes its local commit and exits with an error. Run the pipeline again after the branch is current, or point **Branch** at a branch that allows the push.
The agent cannot find the failed execution
Confirm that **Failed Execution ID** and **Source Pipeline ID** are correct, and that the MCP connector can read executions in the project. When the inputs are empty, the agent uses the execution that it runs in.
The agent cannot determine the repository or branch
Add a clone codebase step before the agent, or set **Repository** and **Branch** explicitly.
## Code Coverage Generation
| Property | Value |
| -------------------- | ------------------- |
| **Agent identifier** | `codeCoverageAgent` |
| **Author** | Harness |
| **Version** | 1.0.0 |
The Code Coverage Generation agent analyzes your repository, finds gaps in test coverage, writes unit tests to close them, and commits the tests to a branch.
### Code Coverage Generation use cases
* **Raise coverage on a legacy service**: Run the agent against a branch to generate tests for untested files and critical code paths.
* **Meet a coverage gate**: The agent targets 90% overall and 80% per file. Use it to bring a repository up to the threshold that your quality gate requires.
* **Add tests alongside a change**: Run the agent on a feature branch so that new code ships with tests that follow the project conventions.
* **Keep a coverage report current**: If the repository root has a `COVERAGE.md`, the agent updates its metrics with the before and after numbers.
* **Review coverage in the logs**: The agent prints a coverage report to the step log, with the overall change, per-file results, and key improvements.
### Code Coverage Generation prerequisites
* **LLM connector**: A connector in the **AI** category, such as Anthropic or Bedrock. Required.
* **MCP connectors**: One or more MCP connectors for source control, such as Harness Code MCP or GitHub MCP. The agent uses them to read the repository, check the diff, commit, and push.
* **Repository context**: Run the agent after a clone codebase step, or set **Repository** and **Branch** explicitly. When you leave the inputs empty, the agent reads the values from runtime environment variables such as `$DRONE_REPO_LINK` and `$DRONE_BRANCH`.
* **Write access**: The SCM connector must be able to push to the target branch.
* **Runnable tests**: The agent runs your tests with coverage in the step container, so the project must build and test in that environment.
### Add Code Coverage Generation to a pipeline
1. Open your pipeline in the Pipeline Studio.
2. Click **Add Step** in the stage execution panel, select **Agents**, then select **Agent**.
3. Enter a **Name** and select **Code Coverage Generation** from the **Agent** list.
4. Select a **Version**, or choose **Always use stable**.
5. Configure the [inputs](#code-coverage-generation-inputs).
6. Click **Apply Changes**.
### Code Coverage Generation inputs
| Input | Required | Default | Description |
| ------------------------------------- | -------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **LLM Connector** (`llm_connector`) | Yes | None | The connector the agent uses to call the model. |
| **Model Name** (`model_name`) | Yes | None | The Anthropic or Bedrock model identifier, or an inference profile ARN. |
| **MCP Connectors** (`mcp_connectors`) | No | None | The MCP connectors to mount for source control operations. |
| **Repository** (`repo`) | No | Empty | The repository identifier: `org/repo` for GitHub-style providers, or the full repository path for Harness Code. Leave empty to derive it from the runtime SCM environment variables. |
| **Branch** (`branch`) | No | Empty | The branch to commit the tests to. Leave empty to use `$DRONE_BRANCH`. The agent confirms that the branch exists through the SCM MCP connector before it commits. |
Every input accepts a fixed value, a runtime input, or an expression.
### How the Code Coverage Generation agent works
The agent runs a single step, **Run Code Coverage Agent**, that always runs and is limited to 150 turns. The agent works autonomously and follows these steps:
1. Resolves the branch, repository, and Harness context from the inputs, then from runtime environment variables, then from MCP tools. It fails with a message if a value is missing.
2. Confirms that the repository is checked out in `/harness`, and clones it if it is missing.
3. Detects the languages, test frameworks, and coverage tool, then runs the tests to record baseline coverage.
4. Identifies untested and under-tested files and critical code paths.
5. Writes tests that follow the project conventions and cover happy paths, edge cases, error handling, and boundary conditions. It changes production code only as much as testability requires.
6. Runs the full test suite with coverage, linters, and build commands, and fixes failures that its additions introduce.
7. Reviews the diff to confirm that only test additions and minimal testability changes are present.
8. Updates `COVERAGE.md` in place if it already exists. It does not create the file.
9. Stages only the changed files, makes one commit with the message `Code coverage: automated test additions by Harness AI`, and pushes it to the branch.
10. Prints the coverage report and a final summary with the branch, the staged files, and the commit SHA.
### Code Coverage Generation safety rules
The agent commits directly to your branch, so it follows these rules:
* It stages files one at a time and never stages by directory or with `git add -A`.
* It makes exactly one commit per run.
* It works only with the commit that was cloned and never pulls, rebases, or merges new commits from the remote.
* It never force pushes. If the push is rejected, it undoes the local commit, prints the rejection, and exits with an error so that a person can resolve it.
* It does not weaken or delete existing tests, and it does not change production logic to inflate coverage.
* It never prints secrets, tokens, or credentials.
{% hint style="warning" %}
**REVIEW THE COMMIT**
The agent pushes to the branch you specify. Run it against a feature branch, or protect the branch with required reviews, so that a person reviews the tests before they merge.
{% endhint %}
### Code Coverage Generation troubleshooting
The push is rejected
Another commit reached the remote branch, or branch protection blocked the push. The agent undoes its local commit and exits with an error. Run the pipeline again after the branch is current, or point **Branch** at a branch that allows the push.
The agent cannot determine the repository or branch
Add a clone codebase step before the agent, or set **Repository** and **Branch** explicitly.
The agent cannot run the tests
The agent runs tests in the Harness agent container. If your project needs additional toolchains or services to build and test, the baseline run fails and the agent cannot generate verified tests. Confirm that the project builds and tests in that environment.
## Code Review
| Property | Value |
| -------------------- | ------------------- |
| **Agent identifier** | `aiCodeReviewAgent` |
| **Author** | Harness |
| **Version** | 1.0.0 |
{% hint style="warning" %}
**COMING SOON**
The catalog lists this agent as not yet ready for use. The behavior below may change before release.
{% endhint %}
The Code Review agent reviews the pull request that triggered the pipeline. It generates review instructions from the diff, flags issues, verifies each flagged issue, and posts the results to the pull request: inline comments, an AI overview, success-criteria results, and suggested reviewers.
### Code Review use cases
* **First-pass review on every pull request**: Run the agent from a pull request trigger so every change gets an automated review before a human reviewer starts.
* **Reduce noisy comments**: The verify pass removes issues that duplicate existing comments and confirms each flagged issue, so reviewers see fewer false positives.
* **Enforce team guidance**: The verify pass applies project guidance and success criteria, and reports the success-criteria results on the pull request.
* **Route to the right reviewers**: Use the suggested reviewers to route the pull request to the people best placed to review it.
* **Control cost and depth**: Lower **Max Turns** and **Verify Pass Max Turns** for fast feedback on small changes, or raise them for large or sensitive changes.
### Code Review prerequisites
* **Pull request trigger**: The pipeline must run for a pull request, because the agent reviews the pull request that triggered the run.
* **Review configuration**: The agent reads its LLM connector and any MCP connectors from the generated review instructions, not from agent inputs. Ensure a model connector is configured for code review in your project.
### Add Code Review to a pipeline
1. Open your pipeline in the Pipeline Studio.
2. Click **Add Step** in the stage execution panel, select **Agents**, then select **Agent**.
3. Enter a **Name** and select **Code Review** from the **Agent** list.
4. Select a **Version**, or choose **Always use stable**.
5. Configure the [inputs](#code-review-inputs).
6. Click **Apply Changes**.
### Code Review inputs
| Input | Default | Description |
| ---------------------------------------------- | ------- | ---------------------------------------------------------------------------------------- |
| **Model Name** (`model_name`) | Empty | The model to use, for example `claude-opus-5`. Leave empty to use the connector default. |
| **Max Turns** (`max_turns`) | `150` | The maximum number of agent iterations in the flag-issues pass before the run ends. |
| **Verify Pass Max Turns** (`verify_max_turns`) | `150` | The maximum number of agent iterations in the verify pass. |
Every input accepts a fixed value, a runtime input, or an expression.
### How the Code Review agent works
The agent expands into the **AI PR Review Agent** step group, which runs the following steps in order.
| Step | What it does |
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **generate agent instructions** | Generates the review instructions and skill from the pull request diff in two-pass mode, and exposes them, including the LLM and MCP connector references, to later steps. |
| **print plugin outputs** | Prints the generated files to the step log for troubleshooting. |
| **flag issues agent** | Runs the AI agent to review the diff and flag candidate issues. |
| **generate verify instructions** | Generates the instructions for the verify pass. |
| **verify issues agent** | Runs the AI agent to remove duplicates of existing comments, verify each flagged issue, and apply project guidance and success criteria. It can use the MCP connectors from the review configuration. |
| **post review results** | Posts the inline comments, AI overview, success-criteria results, and suggested reviewers to the pull request. |
## Container and Dependency Remediation
| Property | Value |
| -------------------- | ---------------------------- |
| **Agent identifier** | `dependencyRemediationAgent` |
| **Author** | Harness |
| **Version** | 1.0.0 |
The Container and Dependency Remediation agent fixes vulnerabilities reported by a container scan. It updates vulnerable base images in Dockerfiles and vulnerable package dependencies, validates the fix branches, and opens separate pull requests for base image updates and package updates.
### Container and Dependency Remediation use cases
* **Patch vulnerable base images**: Update the base image in your Dockerfiles to a version that resolves the reported container findings. Set **Use STO Approved Base Images** to restrict upgrades to images that STO has already approved.
* **Upgrade vulnerable packages**: Bump vulnerable dependencies to fixed versions. Set **Max Version Update** to `PATCH` or `MINOR` to avoid breaking changes, or `MAJOR` when you accept them.
* **Focus on exploitable risk**: Combine **CISA KEV**, **Exploitable**, **Reachable**, and **EPSS Probability** with a severity filter to fix the vulnerabilities most likely to be exploited first.
* **Gate on a rebuilt image**: Set **Validation Pipeline**, **Build Step Id**, and **Scan Step Id** so the agent rebuilds and re-scans the remediated image and confirms the fix before it opens pull requests.
* **Review changes separately**: The agent opens separate pull requests for base image updates and package updates, so each can be reviewed, tested, and rolled back independently.
* **Monorepos and multiple Dockerfiles**: Set **Dockerfile Path** or **Repository Clone URL Override** to target one image, or leave them empty so the agent discovers Dockerfiles automatically.
### Prerequisites
* **Container scan**: A completed container scan in Security Testing Orchestration (STO). The agent reads the findings by scan ID.
* **LLM connector**: A connector in the **AI** category, such as Anthropic or OpenAI. Required.
* **SCM connector (optional)**: A GitHub connector with permission to clone the repository, push branches, and open pull requests. Leave it empty for a Harness Code repository, which authenticates with the ephemeral Harness token instead of a connector.
* **Validation pipeline (optional)**: A pipeline that rebuilds and re-scans the remediated image. Required only if you want the agent to confirm the fix before opening pull requests.
### Add the agent to a pipeline
In a CI pipeline, run the agent after the container scan step so it can consume the scan output.
1. Open your pipeline in the Pipeline Studio.
2. Click **Add Step** in the stage execution panel, select **Agents**, then select **Agent**.
3. Enter a **Name** and select **Container and Dependency Remediation** from the **Agent** list.
4. Select a **Version**, or choose **Always use stable**.
5. Configure the [inputs](#inputs).
6. Click **Apply Changes**.
For the Agent step YAML syntax, go to [Use Worker Agents in pipelines](/harness-platform/use-harness-ai/core-capabilities/in-your-pipelines/worker-agent/worker-agent-in-pipeline.md#step-reference-syntax).
{% hint style="info" %}
**REFERENCE THE SCAN ID FROM THE PRECEDING STEP**
In a CI pipeline, set **Scan ID** to an expression that reads the output of the scan step, for example `<+steps.container_scan.output.scanId>`.
{% endhint %}
### Inputs
Inputs appear in the Agent step form in the groups shown below. Fields marked as optional can be left empty.
**Core**
| Input | Required | Description |
| --------------------------------------- | -------- | --------------------------------------------------------------------------------------- |
| **Scan ID** (`scan_id`) | Yes | The container scan ID whose findings the agent remediates. |
| **SCM Connector** (`scm_connector_ref`) | No | A GitHub connector used to clone the repository, push branches, and open pull requests. |
| **LLM Connector** (`llm_connector`) | Yes | The connector the agent runner uses to call the model. |
**Severity**
| Input | Required | Description |
| ---------------------------------------------- | -------- | --------------------------------------------------------------- |
| **Severities to Remediate** (`severity_types`) | Yes | One or more of `CRITICAL`, `HIGH`, `MEDIUM`, `LOW`, and `INFO`. |
**Remediation criteria**
These criteria add findings to the set selected by severity.
| Input | Default | Description |
| ----------------------------------------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **EPSS Probability** (`epss_probability`) | `none` | Includes findings at or above an Exploit Prediction Scoring System threshold. `gte_15`, `gte_5`, and `gte_1` correspond to 15%, 5%, and 1%. `none` disables EPSS selection. |
| **CISA KEV** (`cisa_kev`) | `false` | Includes findings for a CVE on the CISA Known Exploited Vulnerabilities catalog. |
| **Exploitable** (`exploitable`) | `false` | Includes findings where the scanner found evidence of a known exploit or proof of concept. |
| **Reachable** (`reachable`) | `false` | Includes findings whose vulnerable code paths are reachable, based on static analysis. |
**Validation**
| Input | Default | Description |
| ----------------------------------------------- | ------- | --------------------------------------------------------------------------------------------------------------------------- |
| **Validation Pipeline** (`validation_pipeline`) | Empty | The pipeline that rebuilds and re-scans the remediated image. Leave empty to skip pipeline validation. |
| **Build Step Id** (`build_step_id`) | Empty | The identifier of the step in the validation pipeline that produces the remediated image, for example `build_image`. |
| **Scan Step Id** (`scan_step_id`) | Empty | The identifier of the container scan step in the validation pipeline that re-scans the image, for example `container_scan`. |
**More options**
| Input | Default | Description |
| ----------------------------------------------------------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Repository Clone URL Override** (`repo_url`) | Empty | The Git remote URL where Dockerfiles and application manifests live. Leave empty to resolve it automatically. |
| **Dockerfile Path** (`dockerfile_path`) | Empty | The Dockerfile path relative to the repository root, for example `docker/app/Dockerfile`. Leave empty to discover Dockerfiles automatically. |
| **Max Version Update** (`max_version_update`) | `MINOR` | The highest semantic-version bump the agent may apply to a vulnerable package. `PATCH` allows patch bumps only, `MINOR` allows minor and patch, and `MAJOR` allows any bump. |
| **Use STO Approved Base Images** (`use_sto_approved_base_images`) | `false` | Restricts base image upgrades to variants that STO has already scanned and approved for the project. |
| **SCM Provider** (`scm_provider`) | Empty | The source control provider, such as `github` or `harness_code`. Populated from the scan-completion event. Leave empty to resolve it from the repository URL. |
Every field except the three selection lists and the boolean toggles accepts a fixed value, a runtime input, or an expression.
### How the Container and Dependency Remediation agent works
The agent expands into a step group that runs the following steps in order.
| Step | What it does |
| --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Scope** | Resolves the remediation target from the scan ID and the selection criteria. If no findings are in scope, the outcome is `ZERO_IN_SCOPE` and the remaining steps, other than **Persist**, are skipped. |
| **Clone Harness Code Repository** | Clones the repository with the ephemeral Harness token. Runs only when the SCM provider is `harness_code`. |
| **Clone Repository** | Clones the repository with the SCM connector credentials. Runs for every other SCM provider. |
| **Prepare Scope** | Builds the remediation scope: the default branch, the Dockerfile paths, and the base images in use. |
| **Remediate** | Runs the AI agent with 8 GiB of memory and 4 CPUs, up to 900 turns. The agent updates base images and package dependencies, validates the fix branches, and opens separate pull requests for base image and package updates. A failure in this step does not fail the stage. |
| **Persist** | Always runs. Records the remediation result against the scan and the pipeline execution. |
### Output variables
The **Scope** step publishes the following output variables, which downstream steps can reference.
| Variable | Description |
| ------------------------------------------------- | --------------------------------------------------------------------------- |
| `outcome` | The scoping result. `ZERO_IN_SCOPE` means no findings matched the criteria. |
| `executionId` | The remediation execution identifier. |
| `validationPipeline`, `buildStepId`, `scanStepId` | The resolved validation settings. |
| `defaultBranch` | The default branch of the target repository. |
| `scmProvider`, `repoUrl` | The resolved provider and clone URL. |
| `dockerfilePath` | The resolved Dockerfile path. |
| `targetName` | The name of the remediation target. |
Output variables are read through the step group path. Go to [Agent step expands to a step group at runtime](/harness-platform/use-harness-ai/core-capabilities/in-your-pipelines/worker-agent/worker-agent-in-pipeline.md#agent-step-expands-to-a-step-group-at-runtime) for the expression syntax.
### Troubleshooting
The agent finishes without opening a pull request
Check the **Scope** step output. If `outcome` is `ZERO_IN_SCOPE`, no findings matched the selected severities and criteria. Add severities or enable additional criteria, then run the pipeline again.
The Remediate step fails but the stage succeeds
The **Remediate** step is configured to ignore failures so that **Persist** can still record the result. Open the **Remediate** step logs to find the cause, such as an unreachable LLM connector or missing repository write access.
The agent cannot push branches or open pull requests
Confirm that the SCM connector has write permission on the target repository. For a Harness Code repository, leave **SCM Connector** empty and confirm the pipeline identity can push to the repository.
## Database Impact Analysis
| Property | Value |
| -------------------- | ------------------------ |
| **Agent identifier** | `databaseImpactAnalysis` |
| **Author** | Harness |
| **Version** | 1.0.0 |
The Database Impact Analysis agent reviews a SQL migration or change script and decides whether it is safe to run against a production database with zero downtime. It reports a `PASS` or `FAIL` verdict and a short summary as output variables that later steps can use to gate a deployment.
### Database Impact Analysis use cases
* **Gate a database migration**: Run the agent before the step that applies a migration, and proceed only when `VALIDATION_STATUS` is `PASS`.
* **Catch risky schema changes before production**: The agent flags changes that can lock tables for more than 500 ms, cause an outage, lose data, or cannot be undone.
* **Check backward compatibility**: The agent checks that the old and new versions of the application can run against the database at the same time, which supports rolling and blue-green deployments.
* **Explain the verdict to reviewers**: Include the `SUMMARY` output in a notification or approval message so that approvers see why the change passed or failed.
* **Add schema context**: Mount MCP connectors to give the agent more schema or database context for the analysis.
### Database Impact Analysis prerequisites
* **LLM connector**: A connector in the **AI** category. The default is the Harness-managed `account.harnessAnthropic` connector. Go to [Configure Model Connectors](/harness-platform/use-harness-ai/core-capabilities/in-your-pipelines/worker-agent/configuration.md#configure-model-connectors) for details.
* **SQL script**: The migration or change script to analyze, supplied as the input value.
* **MCP connectors (optional)**: Connectors that give the agent schema or database context.
### Add Database Impact Analysis to a pipeline
1. Open your pipeline in the Pipeline Studio.
2. Click **Add Step** in the stage execution panel, select **Agents**, then select **Agent**.
3. Enter a **Name** and select **Database Impact Analysis** from the **Agent** list.
4. Select a **Version**, or choose **Always use stable**.
5. Configure the [inputs](#database-impact-analysis-inputs).
6. Click **Apply Changes**.
### Database Impact Analysis inputs
| Input | Required | Default | Description |
| ------------------------------------- | -------- | ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| **SQL** (`sql`) | Yes | None | The SQL migration or change script to analyze. |
| **LLM Connector** (`llm_connector`) | Yes | `account.harnessAnthropic` | The connector the agent uses to call the model. |
| **Model Name** (`model_name`) | Yes | `global.anthropic.claude-haiku-4-5-20251001-v1:0` | The Anthropic or Bedrock model identifier, or an inference profile ARN. |
| **MCP Connectors** (`mcp_connectors`) | No | None | The MCP connectors to mount for additional schema or database context. Listed under **More** in the step form. |
Every input accepts a fixed value, a runtime input, or an expression.
### How the Database Impact Analysis agent works
The agent runs a single step, **Analyze Database Impact**, that always runs and is limited to 150 turns. The agent evaluates the SQL against the following criteria.
The SQL must:
* Be backward compatible, so that the old and new application versions can run against the database at the same time and always see the same data.
* Preserve database consistency and integrity.
* Be performant.
The SQL must not:
* Create locks that last more than 500 ms.
* Cause an outage when run in production.
* Cause data loss.
* Perform an operation that cannot be undone.
### Database Impact Analysis output variables
| Variable | Description |
| ------------------- | -------------------------------------------------------------------------------------- |
| `VALIDATION_STATUS` | `PASS` if the SQL is safe to run, or `FAIL` if it is not. |
| `SUMMARY` | A single-line explanation of what the change does and why it is or is not safe to run. |
The step always exits successfully, whatever the verdict. A `FAIL` verdict does not fail the stage, so add a condition on `VALIDATION_STATUS` to a later step to stop the pipeline. Go to [Agent step expands to a step group at runtime](/harness-platform/use-harness-ai/core-capabilities/in-your-pipelines/worker-agent/worker-agent-in-pipeline.md#agent-step-expands-to-a-step-group-at-runtime) for the expression that reads the output, and to [Example: IaC Plan Safety gate with agent outputs](/harness-platform/use-harness-ai/core-capabilities/in-your-pipelines/worker-agent/worker-agent-in-pipeline.md#example-iac-plan-safety-gate-with-agent-outputs) for a gating pattern.
{% hint style="warning" %}
**THE VERDICT IS ADVISORY**
The analysis is generated by a model. Treat a `PASS` verdict as an additional check and keep your normal migration review and testing in place.
{% endhint %}
### Database Impact Analysis troubleshooting
The stage succeeds even though the SQL is unsafe
The step does not fail on a `FAIL` verdict. Add a condition or a failure step that checks `VALIDATION_STATUS` in a later step.
The analysis is shallow or misses context
Mount an MCP connector that exposes your schema or database metadata, or select a more capable model in **Model Name**. The default model is optimized for speed.
## Feature Flag Cleanup
| Property | Value |
| -------------------- | ------------------------- |
| **Agent identifier** | `featureFlagCleanupAgent` |
| **Author** | Harness |
| **Version** | 1.0.0 |
The Feature Flag Cleanup agent removes references to a stale feature flag from your codebase, keeps only the code path for the treatment you choose, and commits the cleanup to a branch.
### Feature Flag Cleanup use cases
* **Remove a fully rolled out flag**: Set **Treatment** to the value that shipped, such as `on`, so the agent deletes the flag evaluation and the losing code path.
* **Retire an abandoned experiment**: Set **Treatment** to the value you are keeping, such as `off`, to delete the experiment code.
* **Clean up after a release**: Run the agent in a pipeline that is triggered when a flag is marked stale, so cleanup does not wait for a developer.
* **Remove dead code and unused imports**: The agent also removes variables, imports, and SDK client construction that become unused once the flag evaluation is gone.
* **Clean up shared constants**: When a flag is defined in an exported constant, the agent searches for the other files that use it and cleans them as well.
### Feature Flag Cleanup prerequisites
* **LLM connector**: A connector in the **AI** category, such as Anthropic or Bedrock. Required.
* **MCP connectors**: One or more MCP connectors for source control, such as Harness Code MCP or GitHub MCP. The agent uses them to read the repository, check the diff, commit, and push.
* **Repository context**: Run the agent after a clone codebase step, or set **Repository** and **Branch** explicitly. The agent reads the repository and branch from runtime environment variables such as `$DRONE_REPO_LINK` and `$DRONE_BRANCH` when you leave the inputs empty.
* **Write access**: The SCM connector must be able to push to the target branch.
### Add Feature Flag Cleanup to a pipeline
1. Open your pipeline in the Pipeline Studio.
2. Click **Add Step** in the stage execution panel, select **Agents**, then select **Agent**.
3. Enter a **Name** and select **Feature Flag Cleanup** from the **Agent** list.
4. Select a **Version**, or choose **Always use stable**.
5. Configure the [inputs](#feature-flag-cleanup-inputs).
6. Click **Apply Changes**.
### Feature Flag Cleanup inputs
| Input | Required | Default | Description |
| ------------------------------------- | -------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Feature Flag** (`feature_flag`) | Yes | None | The name of the feature flag to clean up. |
| **LLM Connector** (`llm_connector`) | Yes | None | The connector the agent uses to call the model. |
| **Model Name** (`model_name`) | Yes | None | The Anthropic or Bedrock model identifier, or an inference profile ARN. |
| **MCP Connectors** (`mcp_connectors`) | No | None | The MCP connectors to mount for source control operations. |
| **Repository** (`repo`) | No | Empty | The repository identifier: `org/repo` for GitHub-style providers, or the full repository path for Harness Code. Leave empty to derive it from the runtime SCM environment variables. |
| **Treatment** (`treatment`) | No | `on` | The treatment whose code path is kept after cleanup. |
| **Branch** (`branch`) | No | Empty | The branch to commit the cleanup to. Leave empty to use `$DRONE_BRANCH`. The agent confirms that the branch exists through the SCM MCP connector before it commits. |
Every input accepts a fixed value, a runtime input, or an expression.
### How the Feature Flag Cleanup agent works
The agent runs a single step, **Run Feature Flag Cleanup Agent**, that always runs and is limited to 150 turns. The agent works autonomously and follows these steps:
1. Resolves the branch, repository, and Harness context from the inputs, then from runtime environment variables, then from MCP tools. It fails with a message if a value is missing.
2. Confirms that the repository is checked out in `/harness`, and clones it if it is missing.
3. Searches the code for every reference to the flag and removes each flag evaluation, keeping only the code for the selected treatment.
4. Removes variables, imports, and SDK client code that become unused, and follows exported constants to other files.
5. Runs the available linters, formatters, build commands, and tests, and fixes failures caused by the cleanup.
6. Reviews the diff to confirm that only flag-related removals are present.
7. Stages only the changed files, makes one commit with the message `FF cleanup: remove feature flag (keep )`, and pushes it to the branch.
### Feature Flag Cleanup safety rules
The agent commits directly to your branch, so it follows these rules:
* It stages files one at a time and never stages by directory or with `git add -A`.
* It makes exactly one commit per run.
* It works only with the commit that was cloned and never pulls, rebases, or merges new commits from the remote.
* It never force pushes. If the push is rejected, it undoes the local commit, prints the rejection, and exits with an error so that a person can resolve it.
* It never removes code paths that the flag does not control, and never removes unrelated tests or code.
* It never prints secrets, tokens, or credentials.
{% hint style="warning" %}
**REVIEW THE COMMIT**
The agent pushes to the branch you specify. Run it against a feature branch, or protect the branch with required reviews, so that a person reviews the cleanup before it merges.
{% endhint %}
### Feature Flag Cleanup troubleshooting
The push is rejected
Another commit reached the remote branch, or branch protection blocked the push. The agent undoes its local commit and exits with an error. Run the pipeline again after the branch is current, or point **Branch** at a branch that allows the push.
The agent cannot determine the repository or branch
Add a clone codebase step before the agent, or set **Repository** and **Branch** explicitly.
## Kubernetes Manifest Remediation
| Property | Value |
| -------------------- | ------------------------- |
| **Agent identifier** | `manifestRemediatorAgent` |
| **Author** | Harness |
| **Version** | 1.0.0 |
The Kubernetes Manifest Remediation agent analyzes a failed Kubernetes or Helm deployment, finds the root cause, and writes a structured remediation report with actionable fixes. The agent recommends changes only. It does not modify or commit your manifests.
### Kubernetes Manifest Remediation use cases
* **Diagnose a failed deployment**: Run the agent after a failed deployment to get the failed step, the failure category, the root cause, and the supporting log evidence in one report.
* **Fix common manifest errors**: The agent inspects image pull failures, resource constraints, validation errors, Helm template errors, missing required fields, RBAC issues, and readiness and liveness probe failures.
* **Get proposed changes**: Each recommended fix lists the file, a before and after snippet, and the rationale, so that a developer can apply it directly.
* **Review without write access**: The agent never applies or commits changes, so you can use it where automated commits are not allowed.
* **Analyze a past failure**: Set **Failed Execution ID** and **Pipeline ID** to analyze an earlier run.
### Kubernetes Manifest Remediation prerequisites
* **LLM connector**: A connector in the **AI** category, such as Anthropic or Bedrock. Required.
* **Harness MCP connector**: An MCP connector that can fetch execution details and step logs. Add source control connectors as needed.
* **Failed deployment**: A failed execution with a `K8sRollingDeploy` or `HelmDeploy` step.
* **Manifest repository (optional)**: If the manifests or values files are in `/harness` or the workspace, the agent correlates the failure with them. Without them, the agent works from the execution logs alone.
### Add Kubernetes Manifest Remediation to a pipeline
1. Open your pipeline in the Pipeline Studio.
2. Click **Add Step** in the stage execution panel, select **Agents**, then select **Agent**.
3. Enter a **Name** and select **Kubernetes Manifest Remediation** from the **Agent** list.
4. Select a **Version**, or choose **Always use stable**.
5. Configure the [inputs](#kubernetes-manifest-remediation-inputs).
6. Click **Apply Changes**.
### Kubernetes Manifest Remediation inputs
| Input | Required | Default | Description |
| ------------------------------------------------ | -------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **LLM Connector** (`llm_connector`) | Yes | None | The connector the agent uses to call the model. |
| **Model Name** (`model_name`) | Yes | None | The Anthropic or Bedrock model identifier, or an inference profile ARN. |
| **MCP Connectors** (`mcp_connectors`) | No | None | The MCP connectors to mount. Include a Harness MCP connector to fetch logs and execution metadata. |
| **Failed Execution ID** (`harness_execution_id`) | No | Empty | The execution ID of the failed deployment. Leave empty to use `$HARNESS_EXECUTION_ID`. |
| **Pipeline ID** (`harness_pipeline_id`) | No | Empty | The identifier of the pipeline that contains the failed deployment. Leave empty to use `$HARNESS_PIPELINE_ID`. |
| **Harness Account ID** (`harness_account_id`) | No | Empty | The account identifier. Leave empty to use `$HARNESS_ACCOUNT_ID`. |
| **Harness Org ID** (`harness_org_id`) | No | Empty | The organization identifier. Leave empty to use `$HARNESS_ORG_ID`. |
| **Harness Project ID** (`harness_project_id`) | No | Empty | The project identifier. Leave empty to use `$HARNESS_PROJECT_ID`. |
| **Harness Base URL** (`harness_base_url`) | No | Empty | The Harness base URL. Set it for self-managed installs. Leave empty to derive it from `$HARNESS_TI_SERVICE_ENDPOINT`, for example `https://qa.harness.io/ti-service` becomes `https://qa.harness.io`. |
Every input accepts a fixed value, a runtime input, or an expression.
### How the Kubernetes Manifest Remediation agent works
The agent runs a single step, **Run Manifest Remediator Agent**, that always runs and is limited to 150 turns. The agent works autonomously and follows these steps:
1. Resolves the execution, pipeline, account, organization, project, and base URL from the inputs, then from runtime environment variables. It fails with a message if a value is missing.
2. Looks for the manifest or values repository in the workspace. It clones one only if none is accessible, and can work from the execution logs alone.
3. Fetches the execution through the MCP tools and identifies the failed `K8sRollingDeploy` and `HelmDeploy` steps.
4. Fetches the logs of those steps and inspects the events and errors.
5. Correlates the failure with the manifest and values configuration that the execution references.
6. Writes a remediation report to `manifest_remediation_results.yaml` in the workspace.
7. Prints the report to the step log.
### Kubernetes Manifest Remediation report
The report is a YAML file with the following structure.
| Field | Description |
| --------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| `execution_id`, `pipeline_id` | The analyzed execution and pipeline. |
| `analysis` | The `failed_step`, the `failure_type` category, a one-paragraph `root_cause`, and the supporting `evidence` log lines and events. |
| `recommended_fixes` | A list of fixes. Each has the `file`, a one-line `change`, the `before` and `after` YAML, and the `rationale`. |
| `deployment_strategy_adjustments` | Optional notes on the deployment strategy. |
| `next_steps` | Ordered, actionable steps. |
The agent does not embed secrets or tokens in the report, and it never applies or commits the recommended changes.
### Kubernetes Manifest Remediation troubleshooting
The report has no recommended fixes for a manifest file
The manifests were not available to the agent, so it worked from the execution logs alone. Add a clone codebase step that checks out the manifest or values repository before the agent.
The agent cannot find the failed execution
Confirm that **Failed Execution ID** and **Pipeline ID** are correct, and that the MCP connector can read executions and logs in the project. For a self-managed installation, set **Harness Base URL**.