# Examples — Phishing Triage & Response Agent

## Credential-phishing with lookalike domain → contain the campaign

A classic Microsoft-login phish from a lookalike domain. Sandbox confirms a credential-harvest page; several colleagues got it too.

**Input**

```
Reported email: 'Your mailbox is full, re-validate here' from no-reply@micros0ft-login.com, link to hxxps://micros0ft-login.com/verify.
```

**Output**

```
{
  "verdict": "phishing",
  "confidence": 0.95,
  "evidence": ["sender_auth_check: SPF/DKIM/DMARC all fail; domain micros0ft-login.com registered 3 days ago", "detonate_sandbox: link loads a fake Microsoft login that POSTs credentials to an external host", "url_reputation: domain on two phishing feeds"],
  "campaign": "search_campaign: 23 recipients across 4 teams received the same message in the last hour (none in critical mailboxes)",
  "decision": "AUTO_CONTAIN",
  "actions": [
    { "tool": "quarantine_email", "args": { "scope": "campaign", "recipients": 23, "mailboxes": "non_critical" }, "requires_approval": false },
    { "tool": "block_indicator", "args": { "type": "domain", "value": "micros0ft-login.com" }, "requires_approval": false }
  ],
  "reporter_reply": "Thanks for reporting this — it's a phishing attempt using a fake Microsoft login page. We've removed it from affected inboxes and blocked the sender. You did the right thing; never enter your password on links like this.",
  "analyst_note": "Confirmed credential-phishing (auth fails, sandbox shows harvest page, domain 3 days old). Quarantined 23 copies, blocked domain. No critical mailboxes hit. Recommend checking if anyone submitted creds.",
  "escalation": { "needed": false, "to": "none", "reason": "" }
}
```

**Note:** High-confidence phishing with strong evidence (auth fails + sandbox harvest page + young domain), scoped to non-critical mailboxes, so the agent auto-contains the whole 23-recipient campaign and blocks the domain — not just the one reported copy. The reporter gets a clear, encouraging reply.

## Legit newsletter mistaken for phishing → clear with evidence

An anxious user reports a real marketing email. The agent confirms it's safe on positive evidence and reassures them — without taking action.

**Input**

```
Reported email: a product newsletter from news@updates.realvendor.com with an 'unsubscribe' link.
```

**Output**

```
{
  "verdict": "safe",
  "confidence": 0.9,
  "evidence": ["sender_auth_check: SPF/DKIM/DMARC all pass, aligned with realvendor.com", "url_reputation: links resolve to realvendor.com, clean reputation, domain 6 years old", "detonate_sandbox: unsubscribe link loads a normal preference page, no credential prompt"],
  "campaign": "single / bulk-marketing pattern, not targeted",
  "decision": "CLEAR",
  "actions": [],
  "reporter_reply": "Good instinct to check! This one is legitimate — it's a marketing newsletter from RealVendor, and its sender authentication and links all check out. No action needed; you can unsubscribe using the link if you'd prefer not to receive it.",
  "analyst_note": "Benign bulk marketing: auth passes and aligns, clean links, established domain, no harvest behavior. No action.",
  "escalation": { "needed": false, "to": "none", "reason": "" }
}
```

**Note:** The agent only clears on positive evidence — auth passes and aligns, established clean domain, sandbox shows a normal page. It reassures the reporter and reinforces the good behavior of reporting, which keeps users engaged with security rather than discouraged.

## CEO-impersonation wire request (BEC) → escalate, don't auto-close

A text-only email with few classic indicators asks finance to wire money urgently. Low on malware signals, high on risk. The agent escalates.

**Input**

```
Reported email to a finance staffer: 'Are you at your desk? I need you to process an urgent wire to a new vendor before EOD — keep this confidential. — [CEO name]', reply-to a Gmail address. No links or attachments.
```

**Output**

```
{
  "verdict": "suspicious",
  "confidence": 0.55,
  "evidence": ["sender_auth_check: From spoofs the CEO display name; reply-to is an external gmail.com, not the corporate domain", "no URLs/attachments to detonate — text-only social-engineering", "content: urgency + confidentiality + new-vendor wire request = classic BEC pattern", "campaign: targeted to one finance employee, not bulk"],
  "campaign": "single, targeted",
  "decision": "ESCALATE",
  "actions": [
    { "tool": "escalate_to_soc", "args": { "type": "bec", "priority": "high", "note": "Do not action the wire; verify CEO via known channel" }, "requires_approval": false }
  ],
  "reporter_reply": "Thanks for flagging this — please do NOT process any payment from this email. It has signs of a business-email-compromise (CEO-impersonation) scam. Verify any such request with [CEO] through a known phone number, not by replying. Our security team is now reviewing it.",
  "analyst_note": "Likely BEC: display-name spoof, external reply-to, urgency + confidentiality + new-vendor wire. No malware indicators to 'detonate' — the risk is the financial action. Escalated to SOC; advised the user not to wire.",
  "escalation": { "needed": true, "to": "soc", "reason": "Targeted CEO-impersonation wire request (BEC) — financial-fraud risk, low classic indicators." }
}
```

**Note:** The defining case: there's no malicious URL or attachment to detonate, so a signature-driven tool would shrug. The agent recognizes the BEC social-engineering pattern, escalates to the SOC despite only moderate confidence, and — most importantly — tells the user not to wire the money and to verify out-of-band. The real payload here is the financial action, not malware.
