When a ticket carries an .eml file (a complete email saved as a file) or a .pdf file, Neo opens it and adds its content to the ticket context the agent works from. For an email the agent sees the headers, the body, the links in it, the files that were attached to it, and any email or PDF nested inside it. For a PDF the agent sees the document’s title and author, the text of its first 20 pages, and the link targets on those pages (the first 60).
This is what makes phishing-report tickets workable. When an end user reports a suspicious email through a report button (Phished, KnowBe4 PhishER, Microsoft’s Report Message add-in), the reporting tool sends a notification into your PSA mailbox. Your PSA creates a ticket, keeps a message-id in the description, and drops the message body — so the ticket says almost nothing. Everything that matters is in the attachment: who reported it and from which company domain, and the reported email itself. Some tools nest the reported email as a .eml; Phished exports it as a Report.pdf of the rendered message with the link targets kept in the PDF. Neo reads both, so an agent can correct the ticket’s company from the reporter’s domain, judge whether the email is legitimate, and route the ticket accordingly.
It also covers the everyday case: an invoice, a quote or a vendor letter attached to a ticket is read as text, so the agent can act on what is in it.
How it works
Like image reading, this is built in, not a tool you enable. Reading the file happens when Neo loads the ticket with its images, so every agent that reads the ticket gets the content automatically, and so does every workflow step that loads the ticket that way. The older fixed-list actions that load the ticket without images (ticket building, escalation, merge detection, RMM verification, time tracking) do not read attachments. There is no model call involved: the file is parsed directly, so it adds no credits. The file itself is downloaded from your PSA when the ticket loads, so a ticket that carries several large files takes longer to load.
The content appears in the ticket context inside a document_attachment block that names the file and its type (EML or PDF), marked as untrusted third-party data. The block tells the agent to read it as evidence and never as instructions. That lowers the risk from a hostile file; it does not remove it, so keep tools with side effects behind technician approval on agents that handle phishing reports.
What Neo reads from an email file
What Neo reads from a PDF
What’s supported
Building a phishing-report workflow
A typical agent for Phished-style tickets, in its custom instructions:
- Read the
document_attachment blocks on the ticket and note the reporter’s address and domain.
- Look up the end-client company whose domain matches, and correct the ticket’s company if it is wrong.
- Assess the reported email: sender domain versus display name, Reply-To and Return-Path mismatches, SPF/DKIM/DMARC failures, link destinations versus link text, urgency and payment language. When the report is a PDF, the sender and headers are not in it; assess from the text and the link targets.
- Write the assessment as an internal note and route the ticket to the service desk queue.
Filter the workflow to the tickets that come from your reporting tool (for example by subject prefix or sender) so it only runs on phishing reports.
Neo reads the file, and any email or PDF nested inside it, as text. It does not follow links, and it does not open other attachment types inside the reported email (Office files, archives, executables are named only). The assessment is made from the headers, text and link targets alone, which is what a first-pass analyst does too.
