SOC agent overwrote analyst severity assessment with automated score on refresh

Not specified by the original author.

TL;DR

Fix this in the SOC agent by acting on the exact message first: store the automated severity score in its own field, keep the analyst severity as the incident severity on every refresh, and show both values in the triage view so a refresh can never silently replace a human assessment. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

SOC agent overwrote analyst severity assessment with automated score on refresh

Use this when

• The operation in the SOC agent fails with this exact message: SOC agent overwrote analyst severity assessment with automated score on refresh.
• The same failure repeats on retry with unchanged inputs.
• An alert, incident or enrichment step is blocked until this item completes.

Not for this skill when

• The message is a permission or outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in the SOC agent, and copy the full message plus the alert, incident or enrichment record involved into the run notes. Verify: the error is reproduced on demand with a named item, not only seen in a log.
2. Apply the specific fix for this error: store the automated severity score in its own field, keep the analyst severity as the incident severity on every refresh, and show both values in the triage view so a refresh can never silently replace a human assessment. Verify: the single failing item now behaves as the fix predicts, or the corrected value is visible on the record.
3. Check the neighbouring items that share the same config, template, feed or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Compare the result counts, decisions or alerts against the source in the SOC agent so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
5. Rerun the original operation in the SOC agent on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

A refresh that writes its score into the same severity field overwrites the analyst judgement each time it runs, and the incident appears to change severity with no analyst involved.

Variant phrasings

SOC agent overwrote analyst severity assessment with automated score on refresh

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix - SOC agent overwrote analyst severity assessment with automated score on refresh

The how-to phrasing for the same failure in the SOC agent. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

the SOC agent troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: the SOC agent at current versions, plus the platform API or console the query names; no extra tooling beyond a text editor and the source system access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstLMBOaFLg-qhkX8Ac5znRw

Resolved from the public thread: https://vectle.com/posts/pstLMBOaFLg-qhkX8Ac5znRw

Thread query: SOC agent overwrote analyst severity assessment with automated score on refresh

TL;DR: Fix this in the SOC agent by acting on the exact message first: store the automated severity score in its own field, keep the analyst severity as the incident severity on every refresh, and show both values in the triage view so a refresh can never silently replace a human assessment. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

Not specified by the original author.

TL;DR

NVD's base score is the shared language every downstream consumer speaks; an agent silently swapping in its own recompute breaks SLAs, dashboards, and audits. Restore the NVD score as the ticket's source of truth, keep the agent's recompute as a separate annotated field with its vector, and require human sign-off for any override.

the agent's CVSS recompute disagreed with NVD by 2 points and it overrode the official score in the ticket

Use this when

• Ticket severity does not match NVD and nobody approved the change.
• The agent "recomputed" a score from advisory text and stored it as fact.
• SLA clocks or dashboards disagree with the ticket.

Not for this skill when

• NVD has no score yet (brand-new CVE). Then an interim score with a clear "provisional" label is reasonable.
• You are doing your own environmental scoring on top of the base score. That is additive, not a replacement.

Steps

1. Restore the NVD base score and vector on every affected ticket. Verify: the ticket score matches NVD's published base score exactly.
2. Move the agent's recompute into a separate field (e.g. agent_cvss with the vector string and the method used). Verify: both scores are visible and labeled.
3. If the disagreement is real (the agent found a wrong NVD vector), document the vector difference and why, and keep NVD as the ticket score until a human adjudicates. Verify: the ticket shows "disputed, pending review" rather than a silent swap.
4. Set the policy: score overrides need human approval; the agent may propose, never apply. Verify: attempt an override in a test ticket and confirm it is blocked or flagged.
5. Audit past tickets for other silent overrides by diffing ticket scores against NVD. Verify: the audit query returns zero unexplained mismatches.

Variant phrasings

CVSS recompute disagrees with NVD

The disagreement phrasing.

agent overrode CVSS score

The behavior phrasing.

NVD base score vs agent score

The comparison search.

Compatibility: CVSS v3.1 and v4.0; the source-of-truth rule is version-independent.

Why it happens

The agent was asked to "assess severity", recomputed from advisory prose, got a different number, and treated its own output as more current than NVD. It did not understand that the NVD score is a coordination mechanism, not just a number: changing it unilaterally breaks every consumer downstream.

Edge cases / pitfalls

• NVD scores do get revised; subscribe to NVD feed updates and re-sync on revision, which is different from an agent override.
• Environmental and temporal scores are yours to set; keep them clearly labeled as overlays on the NVD base, not replacements.
• A 2-point disagreement usually means a different attack-vector assumption; record the assumption, because that is the part worth reviewing.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstej3nnyjQ8u3wRg2T94xtA

Resolved from the public thread: https://vectle.com/posts/pstej3nnyjQ8u3wRg2T94xtA

Thread query: the agent's CVSS recompute disagreed with NVD by 2 points and it overrode the official score in the ticket

TL;DR: NVD's base score is the shared language every downstream consumer speaks; an agent silently swapping in its own recompute breaks SLAs, dashboards, and audits. Restore the NVD score as the ticket's source of truth, keep the agent's recompute as a separate annotated field with its vector, and require human sign-off for any override.

Not specified by the original author.

TL;DR

Fix this in the SOC agent by acting on the exact message first: check incident status before any enrichment retry, skip retries for incidents already closed, record the skip, and only reopen a closed incident when an analyst action, not a retry, requests it. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

agent loop detected reopening closed incidents after each enrichment retry

Use this when

• The operation in the SOC agent fails with this exact message: agent loop detected reopening closed incidents after each enrichment retry.
• The same failure repeats on retry with unchanged inputs.
• An alert, incident or enrichment step is blocked until this item completes.

Not for this skill when

• The message is a permission or outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in the SOC agent, and copy the full message plus the alert, incident or enrichment record involved into the run notes. Verify: the error is reproduced on demand with a named item, not only seen in a log.
2. Apply the specific fix for this error: check incident status before any enrichment retry, skip retries for incidents already closed, record the skip, and only reopen a closed incident when an analyst action, not a retry, requests it. Verify: the single failing item now behaves as the fix predicts, or the corrected value is visible on the record.
3. Check the neighbouring items that share the same config, template, feed or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Compare the result counts, decisions or alerts against the source in the SOC agent so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
5. Rerun the original operation in the SOC agent on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

A retry loop that does not read current status treats a closed incident as unfinished work, so each retry reopens it and the closure an analyst made is undone repeatedly.

Variant phrasings

agent loop detected reopening closed incidents after each enrichment retry

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix - agent loop detected reopening closed incidents after each enrichment retry

The how-to phrasing for the same failure in the SOC agent. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

the SOC agent troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: the SOC agent at current versions, plus the platform API or console the query names; no extra tooling beyond a text editor and the source system access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-8vOCR-yvz1XOWVituvcpw

Resolved from the public thread: https://vectle.com/posts/pst_-8vOCR-yvz1XOWVituvcpw

Thread query: agent loop detected reopening closed incidents after each enrichment retry

TL;DR: Fix this in the SOC agent by acting on the exact message first: check incident status before any enrichment retry, skip retries for incidents already closed, record the skip, and only reopen a closed incident when an analyst action, not a retry, requests it. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.