24 October 2026/Personal project

How does my phishing helpdesk handle a case?

The email evidence, provider reports and Python script behind my email (phishing) helpdesk. And what happens if a message tries to instruct the agent.

Walter Verkerk· 8 min read

The project page explains why I built my email (phishing) helpdesk. This is a closer look at how a report becomes a case, how the abuse agent contacts a provider, and what I need to keep outside the model’s control.

I review the generated code and check how it behaves. Understanding the steps matters to me, especially when an agent is allowed to send something or change a blocklist.

Keeping the email as evidence

A report starts with an authorised person forwarding a suspicious email. The helpdesk keeps the received message as an .eml file, alongside a case record and a SHA-256 hash. The hash lets the script check that the attachment it is about to send is the same file that was recorded for that case.

A normal inline forward can lose original headers. Attaching the original email preserves more of that evidence. A saved server copy proves what the helpdesk received; it doesn’t reconstruct anything that was lost before forwarding. I want the reporting step to stay simple for the person asking for help, while keeping the best evidence available behind the scenes.

The analysis uses the message, headers and local mail evidence. It doesn’t open the suspicious destination, render the HTML or run an attachment. It records a finding and, for confirmed phishing, prepares an abuse report for the responsible provider.

Reporting to Amazon Web Services

AWS is a useful example of why the agent needs to identify the service involved before reporting. A phishing page hosted on infrastructure and a malicious email sent through a mail service can need different reporting routes. An Amazon name in an email isn’t enough to establish either one.

For general AWS abuse, AWS prefers its reporting form. Its official guidance also provides an email route for automated reports or when the form can’t be used. Abuse involving Amazon Simple Email Service has separate instructions. The agent should take the destination from the provider’s official guidance, not from a contact address supplied by the suspicious email.

The case handled by this project involved phishing content on AWS infrastructure. The agent used AWS Trust & Safety’s documented email route for automated reports. It supplied the observed destination and a short description, with the verified server-side .eml attached as supporting evidence.

The report needs to explain what was observed, which infrastructure is involved and why it appears to be phishing. The agent prepares that from the case evidence. It mustn’t fill gaps by guessing which provider owns a destination.

Does the original .eml go with it?

That depends on the provider’s reporting instructions, the evidence they need and what I’m authorised to share. Some routes accept supporting attachments; others use a form or ask for specific headers. Where a provider has requirements about who may submit, the agent needs to check those too. A report from my helpdesk must not pretend to come from the original recipient.

My current email dispatcher is deliberately narrower: it requires the exact, verified .eml attachment. It doesn’t yet choose a different attachment policy for each provider. If a provider needs another format, a different sender or a form submission, this route needs review rather than the agent improvising around it.

AWS permits email attachments that are important to an investigation; that isn’t a universal requirement to attach an .eml to every AWS report. An original message can contain personal information. Whether the provider needs the whole file or selected evidence is part of that sharing decision.

What the Python script does

The analysis agent prepares the finding. A separate abuse agent uses abuse_dispatch.py for the reporting step. The agent is instructed to use that script rather than an arbitrary shell command or a free-form send. It gives me a defined sequence to inspect in code.

The script has a few parts worth looking at:

validate()

Checks the standing authorisation, accepted case, completed analysis and allowed high-confidence phishing classification. It also checks the recorded provider-verification status, the file's location and its SHA-256 hash. Missing or inconsistent inputs stop this route.

compose_provider()

Builds the email from fixed fields: the case reference, observed infrastructure, evidence hash and original attachment. The destination comes from the checked case record, not from a new instruction inside the email being investigated.

dispatch()

Runs the checks, applies and verifies the exact local Pi-hole hostname block, then calls the provider-report step. If the block cannot be verified, the provider report waits. Pi-hole is still under testing and is working as expected so far.

send_and_wait()

Looks up the recorded message and mail-server result so a retry doesn't blindly send again. The case keeps its progress and failures for follow-up. The agent is instructed to run the dry-run eligibility check before dispatch.

Before anything is sent

These sections come from abuse_dispatch.py. The setup and other checks are omitted here.

Inside validate(), failed checks are collected before the script decides whether a case can continue:

if policy.get("standing_abuse_send_grant") is not True:
    failures.append("standing_grant_disabled")
if receipt.get("decision") != policy.get("required_decision"):
    failures.append("decision_not_accepted")
if receipt.get("analysis_status") != "completed":
    failures.append("analysis_incomplete")
if analysis.get("confidence") != policy.get("required_confidence"):
    failures.append("confidence_not_high")
if analysis.get("classification") not in policy.get("allowed_classifications", []):
    failures.append("classification_not_allowed")
if draft.get("recipient_status") != policy.get("required_recipient_status"):
    failures.append("recipient_not_verified_official")

Checking the original email

The file path is resolved first. The script then checks that it stays in the case directory, exists and matches the recorded SHA-256:

artifact = Path(str(attachment.get("path", ""))).resolve()

try:
    artifact.relative_to(ARTIFACTS_DIR)
except ValueError:
    failures.append("artifact_outside_case_directory")
if not artifact.is_file():
    failures.append("artifact_missing")
    actual_hash = None
else:
    actual_hash = hashlib.sha256(artifact.read_bytes()).hexdigest()
    if actual_hash != attachment.get("sha256"):
        failures.append("artifact_hash_mismatch")

Attaching the message

compose_provider() attaches those verified bytes as message/rfc822, preserving the email as an email attachment:

msg.add_attachment(
    artifact.read_bytes(),
    maintype="message",
    subtype="rfc822",
    filename=str(receipt["abuse_draft"]["attachment"]["filename"]),
)

A verification label in a case record is not independent verification by itself. The script checks that the earlier verification was recorded; it doesn’t establish provider ownership again. The evidence behind that decision still matters. The same is true of a model writing “high confidence”. I need to be able to inspect why it reached that conclusion.

What if the email gives the agent instructions?

A phishing email can target the investigator as well as the recipient. Its body, HTML or attachment text could contain instructions to ignore the rules, change the reporting address or disclose other information. Text doesn’t become trustworthy because it is hidden in HTML, quoted in a forward or repeated in an analysis result.

This is prompt injection. A model can mistake part of the evidence for an instruction, and a less capable model may be less reliable at keeping them apart. I wouldn’t treat a more capable model as a security boundary either.

The agents’ instructions already say to treat suspicious mail as data, never as orders. They prohibit following suspect links, loading external assets, running attachments, uploading samples and using a free-form sending route. Changes to the mail filters remain outside this standing permission.

Those instructions are necessary, but they aren’t enough on their own. The tools and permissions need to enforce the same limits. A model shouldn’t be able to rewrite its own policy, approve its own destination or bypass the dispatch checks. Those are boundaries to verify in code and tool access, not promises to accept from the model. The current script’s checks should not be mistaken for proof that every one of those boundaries is independently enforced.

Could another agent watch for drift?

I’d like a separate agent to review behaviour over time: which actions were requested, which checks ran, where cases stopped and whether the actions stayed within the agreed scope. This is a possible next step, not something running in this helpdesk today.

That reviewer should have read-only access to a minimal audit record, not the reporting agent’s send or configuration permissions. It could flag a changed destination, a skipped check or an unexpected tool call for me to review. Its input is untrusted too; feeding it the same injected content doesn’t make it independent assurance.

MAESTRO gives me a way to structure that review. It’s Ken Huang’s agentic-AI threat-modelling framework, published by the Cloud Security Alliance. It isn’t a monitoring product or a certification. Its seven layers suggest concrete questions for this project:

1. Foundation models: does the model keep instructions separate from email evidence?
2. Data operations: can I trace a finding back to the right original message without exposing unnecessary data?
3. Agent frameworks: can hand-offs carry untrusted instructions into another agent?
4. Deployment and infrastructure: are the script, policy and tool permissions protected from the agent being reviewed?
5. Evaluation and observability: can I see attempted actions, failed checks and changes in behaviour?
6. Security and compliance: did the action stay inside its authorisation and data-sharing rules?
7. Agent ecosystem: can one agent influence or approve another beyond its assigned role?

The reviewer would report exceptions to me. It wouldn’t give the operational agent new permissions or replace my own code review.

Sources and further reading

• AWS: reporting abuse and Trust & Safety FAQs: reporting routes and evidence requirements.
• AWS: reporting suspicious emails claiming to be from Amazon, a different route from general AWS hosting abuse.
• OWASP: prompt-injection prevention: untrusted input, tool restrictions and layered controls.
• Cloud Security Alliance: MAESTRO: the seven-layer framework. The project questions above are my proposed use of it, not a completed assessment.

Public guidance checked in October 2026. Provider routes can change; the agent needs to check the official instructions for the case it’s handling.