What is H1 Remediation?

H1 Remediation turns a validated vulnerability into a developer-ready remediation plan. Agentic validation now includes an additional step: root cause analysis. This traces a validated finding to the exact vulnerable code in your own repository. H1 Remediation takes that analysis and builds a remediation plan around it: the recommended approach, the root cause, and, where one can be reliably identified, a suggested code-level change. It uses analysis from your codebase rather than generic guidance for the vulnerability class.

Like agentic validation, H1 Remediation is a decision-support tool. It does not open tickets, create pull requests, or change your code on its own. Your engineering team reviews the plan and decides what to apply, adapt, or discard.

How It Works

Agentic validation and exploitation continue to run as they do today. H1 Remediation adds new capabilities without changing that workflow. It adds two capabilities to agentic validation:

Root cause analysis — for a validated finding with a connected code repository, agentic validation traces the vulnerability to the exact function or configuration responsible, increasing confidence in the validation by grounding the finding in real code evidence rather than the reported behavior alone.
Additional context — where you've connected Atlassian or Linear, agentic validation pulls in incident history and business context to improve validation. For example, it can confirm whether a similar issue is already tracked in Linear or Jira, helping improve duplicate detection.

H1 Remediation then takes the root cause analysis and builds a remediation plan: the recommended approach, root cause detail, priority, and, where one can be reliably identified, a suggested code-level change and verification checks (see What It Provides).

Root Cause Analysis

Agentic validation confirms a report is valid and, for supported vulnerability types, reproduces it in a sandboxed browser (see Agentic Validation for how scope, duplication, and exploitation are determined).

For reports with a connected code repository, agentic validation adds an additional check: root cause analysis. Instead of describing the vulnerability class in general terms, it identifies the specific file, line range, and code responsible based on your repository.

Identifies the exact code. The result includes a plain-language explanation of the root cause (for example, "missing input sanitization in controllers/users.rb"), together with the relevant code snippet and its exact location. Your engineers can start investigating immediately.
Finds the right repository automatically. In organizations with more than one connected repository, root cause analysis determines which repository is relevant to a finding, removing a manual triage step.
Provides additional evidence for prioritization. Because the analysis references your actual code, engineering can review the root cause alongside the validation results when deciding how to prioritize the fix.

This root cause analysis is what H1 Remediation uses to build a remediation plan, rather than relying on generic guidance for the vulnerability class.

For more information about report validation, including scope alignment, guideline eligibility, duplication, and exploitation, see the Agentic Validation article. This section focuses only on root cause analysis.

Gathering Additional Context

Where you've connected Atlassian or Linear, agentic validation can pull in additional context during validation:

Atlassian — incident history from Jira, and business context from Confluence
Linear — incident history from Linear

This is a read-only lookup: it never creates, edits, or closes a ticket. Currently, this context informs agentic validation itself — for example, checking Linear or Jira for a similar issue your team has already tracked, to better inform duplicate detection. This context isn't currently included in the remediation plan, although both features use the same integrations.

What This Context Can Show

Whether this vulnerability (or something very similar) is already tracked internally, and its current status
Whether a fix has already been deployed, and when
Related follow-up or hardening work already planned or in progress
Which team owns the affected system

Example: For a report describing an HTTP request smuggling issue, a Linear/Atlassian lookup might return something like:

Found ENG-4721: "Security: HTTP Request Smuggling CL.TE desync." Status: Done. Team: Infrastructure, linked to this HackerOne report. Fix deployed [date], normalizing header parsing between the frontend and backend. Also found INFRA-892 — a related follow-up audit of proxy configurations, Status: In Progress.

What It Provides

For each validated finding, H1 Remediation builds a remediation plan:

Root cause: Where the vulnerability exists in your code and why, based on the root cause analysis.
Remediation approach: The recommended fix, explained in plain language.
Priority: The report priority, as determined by agentic prioritization.
Suggested code-level change: A code-level recommendation, when one can be reliably determined.
Verification checks: Steps your team can use to confirm the fix worked.

H1 Remediation doesn't include a suggested code-level change for every finding. The level of detail reflects what can be reliably determined for that vulnerability and codebase. Some remediation plans include only the root cause and remediation approach, rather than a speculative code suggestion.

Creating Tickets From Reports

Currently, this context informs agentic validation. For example, it checks Linear or Jira for similar issues your team has already tracked to improve duplicate detection. This is a distinct capability from the read-only context lookup used during remediation. See:

Using Remediation Data in Your Own Tools

If your organization uses Tray integrations to send report data to your own systems, such as Jira, ServiceNow, or webhooks, you can map the remediation plan into your own fields.

{{remediation_plan}} — the full plan, formatted as markdown

This variable is separate from {{remediation_advice}}, which provides generic CWE-based guidance rather than the report-specific analysis generated by H1 Remediation. Don't map both variables to the same field expecting the same content.

Using H1 Remediation via MCP

If your organization has the HackerOne MCP Server connected, you can pull HackerOne data directly into Claude Code, Claude Desktop, Cursor, or any other MCP-compatible client, without leaving your usual workflow.

Two tools cover H1 Remediation specifically:

get_remediation_plan: Returns the remediation plan, including the root cause, remediation approach, suggested code-level change, and verification checks.
get_code_validation_summary: Returns the root cause analysis for a report.

Together with get_report, these tools let coding agents build on HackerOne's analysis instead of starting from the report alone.

Start with get_code_validation_summary so your coding agent begins with the identified root cause instead of deriving it from the report.
Use get_remediation_plan as a starting point for implementing a fix in your repository.
Use the verification checks to generate and run tests that confirm the fix works.
Compare your coding agent's proposed fix with the remediation plan as an additional review step.

For setup and the full tool list, see the HackerOne MCP Server Setup & Tool Reference.

Human Review

Humans stay in control. H1 Remediation does not modify your code, create pull requests, or open tickets automatically. Your engineering team reviews each remediation plan and decides what to apply, adapt, or discard.

Connecting Your Codebase

To perform root cause analysis and generate a remediation plan, H1 Remediation requires access to your source code.

Repository connections are managed through H1 Code. During setup, you'll leave HackerOne briefly to authenticate with your repository provider, then return to complete the connection. You authorize access only to the repositories you select.

Current Coverage

H1 Remediation is rolling out to a limited set of organizations and code repositories today, expanding over time. Reports outside the current coverage continue through agentic validation normally but won't include a remediation plan.

What You See on the Report

From the report page, a row of stage icons next to the report title shows progress through Submission, Validation, Prioritization, and Remediation. Select the stage indicator to open a panel showing each stage.

Within that panel, the Remediation section behaves like this:

While remediation is running, the status updates as it progresses:
- Analyzing root cause → Identifying code patterns → Generating remediation plan → Validating approach.
Once complete, it expands into a checklist:
- Root cause
- Remediation approach
- Suggested code change
- Business rationale
- Implementation steps
- Verification checks
Each row shows a short summary. Available fields vary by report. If a value can't be determined, the row displays Not available instead of being left blank.
The Agent log tab shows which tools, such as Atlassian, Linear, or a connected code repository, informed the recommendation, together with the reasoning for each step.

FAQs

Does H1 Remediation automatically fix my code, open a pull request, or create a ticket?

No. H1 Remediation does not take any action on its own. It produces a remediation plan — including root cause analysis — for a human to review and apply.

Do I need to connect my code repository?

Yes. H1 Remediation requires a connected code repository to perform root cause analysis and generate a remediation plan. Reports without a connected repository still complete agentic validation, but they won't include a remediation plan.

Does H1 Remediation share my code or tickets outside my organization?

No. It operates within the context of your own organization only.

Does H1 Remediation access my code without my permission?

No. It only reads repositories you've explicitly authorized by connecting them through H1 Code.

If I've connected Atlassian or Linear, will H1 Remediation create tickets automatically?

No. The context lookup used during remediation is read-only. Automatic ticket creation is configured separately.

What happens if H1 Remediation can't produce a remediation plan?

A remediation plan isn't available for every report. For example, the affected repository might not be connected or supported, or the agent might not be able to determine a reliable root cause. In those cases, the report continues through the normal validation workflow without a remediation plan.

H1 Remediation