sandbox verdict callback arrived after the agent closed the case and failed to reopen the incident

TL;DR

Design for late truth instead of forbidding it: when a sandbox callback lands on a closed case, evaluate the verdict, and if it contradicts the closure, reopen the case with the verdict attached, notify the owner, and link the reopen event to the original report. Sandbox detonation is asynchronous and sometimes slow, so an agent that treats closure as final will file away real malware as a false alarm whenever the sandbox has a busy day.

sandbox verdict callback arrived after the agent closed the case and failed to reopen the incident

Use this when

• A case was closed as benign or false positive, then a malicious sandbox verdict arrived for the same sample.
• The callback was logged but the case state did not change.
• The sample belonged to a user reported phish that may need a purge.

Not for this skill when

• The verdict arrived before closure and the analyst ignored it. That is a review quality issue, not late handling.
• The callback is a duplicate of a verdict already on the case. Deduplication, not reopening, is the fix there.

Steps

1. Reproduce the race in test: submit a sample, close its case, then deliver a delayed malicious callback and record what happens. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the current behaviour on a late malicious verdict is documented
2. Define the reopen rule precisely: which verdicts on which closed states reopen, and which only annotate the case. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: the rule is written in the case handling documentation or config
3. Implement the rule so a qualifying late verdict reopens the case, attaches the full sandbox report, and assigns it back to the triage queue with a late verdict flag. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: a test late verdict reopens its case and appears in the queue flagged
4. Add a notification for reopened cases so a human sees them the same day, and include the original closure reason in the notice. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: a test reopen generates the notification with the closure context
5. Run a lookback over recently closed cases for sandbox verdicts that arrived after closure and process any malicious ones now. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the lookback lists any affected cases and their new state

Why it happens

Triage agents close cases on the evidence available at decision time, and detonation queues do not respect case timelines. The mismatch is structural: the slower and more loaded the sandbox, the more verdicts arrive after closure, exactly when the sample was interesting enough to detonate. A case model that cannot be reopened by new evidence turns an async delay into a wrong final answer, and the error is invisible because the callback succeeded technically.

Variants and edge cases

sandbox verdict callback arrived after agent closed case failed to reopen

The exact race wording from the incident.

late detonation verdict reopen incident triage agent state machine

The state machine variant naming the design fix.

malicious verdict after false positive closure purge missed sandbox delay

The consequence variant when a purge was needed.

Compatibility: Sandbox detonation APIs with webhook callbacks, agent case management state design.

Edge cases to check:

• Track the closure to verdict gap as a metric; a growing gap is an early warning the sandbox needs capacity.
• Never auto close a case with a pending detonation on high risk reports; waiting states exist for this reason.

Provenance

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

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

Thread query: sandbox verdict callback arrived after the agent closed the case and failed to reopen the incident

TL;DR: Design for late truth instead of forbidding it: when a sandbox callback lands on a closed case, evaluate the verdict, and if it contradicts the closure, reopen the case with the verdict attached, notify the owner, and link the reopen event to the original report. Sandbox detonation is asynchronous and sometimes slow, so an agent that treats closure as final will file away real malware as a false alarm whenever the sandbox has a busy day.