Skip to main content
Ghost’s detection can be tuned to match your organization’s risk profile. You can mute individual findings, customize agent criteria globally or per-project, and re-validate findings after making changes.

​
Muting findings

Muting dismisses an individual finding that isn’t relevant to your organization.

​
When to mute

  • Accepted risk: your team has reviewed the finding and determined the risk is acceptable.
  • Doesn’t apply: the finding doesn’t match your specific context or environment.
  • Not relevant: the detection category targets a pattern your organization doesn’t need to track.

​
How to mute

  1. Navigate to Findings and select the finding you want to dismiss.
  2. Click Mute and choose the scope of the mute:
    • Only for this finding: mutes this individual finding. Use this when the specific instance doesn’t apply but you want the agent to keep running against this project.
    • When any file path in this project starts with a given path: mutes findings from the same agent under that path prefix. Useful for separating between parts of the codebase that apply to internal or admin areas vs. external or user-facing logic.
    • In this project: mutes all findings from the same agent in the current project. Use this when the agent’s entire detection category isn’t relevant to a particular project.
    • Globally: mutes all findings from the same agent across all projects. Use this when the detection category doesn’t apply anywhere in your organization.
  3. Click Mute this finding to confirm. Muted findings are excluded from views and automated actions but remain tracked and can be unmuted at any time.
Muting is best for one-off dismissals. If you’re muting many findings from the same vector, consider tuning the agent criteria instead.

​
Tuning agent criteria

For broader control, create custom vectors that change what an agent checks for. Instead of dismissing findings one at a time, you’re adjusting detection at the source.

​
When to tune

  • You want to provide more directional guidance or specificity to the agent during finding analysis.
  • A vector is repeatedly surfacing findings that don’t apply to your codebase.
  • Your organization has security standards that differ from the defaults.
  • Different projects have different requirements (e.g., a public API vs. an internal service).

​
Agent tuning and vector customization

  1. Navigate to Agents and locate the vector you want to tune.
  2. Open the vector’s context menu and select Tune.
  3. Add, remove, or disable individual criteria to match your requirements.
  4. Add a description explaining the reasoning behind the change.
  5. Choose how broadly to apply the custom vector:
    • All projects: leave project selection empty. The custom vector overrides the system vector for all projects of that purpose in your organization.
    • Specific projects: select the projects this custom vector should apply to. Only those projects use the custom criteria; all others continue using the system defaults (or a global custom vector, if one exists).
  6. Click Create.
Project-specific tuning takes precedence over global tuning, which takes precedence over system defaults. See criteria priority for the full lookup order.

​
Editing and deleting customizations

To edit a custom vector, open its criteria detail and click Edit Custom Vector. You can update the description, criteria, and project assignment. To delete a custom vector, select Delete from the vector’s context menu.
Customizing a system agent’s criteria doesn’t delete the original system criteria. To revert back to the defaults, delete the custom vector and the system criteria will take effect again.

​
Re-validating findings

After tuning criteria, you can re-validate existing findings to see how they hold up against your updated configuration. When you trigger re-validation, Ghost identifies which findings have criteria that changed and re-evaluates them against the current code using the new criteria. Based on the results:
  • Open findings that still meet the updated criteria are re-verified with fresh evidence.
  • Open findings that no longer meet the updated criteria are closed.
  • Recently closed findings that now meet the updated criteria are reopened (for example, if criteria were loosened or made more specific).
To trigger re-validation:
  1. On the agent or vector you tuned, click Validate Findings.
  2. Select the repository to validate against.
  3. Optionally select specific projects, or leave empty to validate all projects in the repository.
  4. Click Validate to start the job.
Re-validation runs in the background. Only findings with changed criteria are re-evaluated, so unchanged vectors are skipped.

​
Best practices

  • Start with muting before creating custom vectors. It helps you identify patterns before making broader changes.
  • Use global tuning for org-wide standards and per-project tuning for project-specific needs.
  • Add clear descriptions to custom vectors so your team understands the reasoning behind each override.
  • Review custom vectors periodically as your codebase and security requirements evolve.
  • Re-validate after tuning so existing findings reflect your updated criteria.

​
Criteria priority

When multiple levels of criteria exist for the same vector, the most specific one wins:
PrioritySourceApplies to
1 (highest)Project-specific custom vectorSelected projects only
2Global custom vectorAll projects in org
3 (default)System vectorAll projects