Investigating an LLM honeypot begins with a small, precise claim: this application received this request at this time. Keeping that claim separate from interpretation makes the record more useful to another analyst, a network operator, or the person reviewing it later.
Start with the observation
A useful event records the timestamp, method, route, observed socket peer, application response, and bounded request body. It also records whether the body is complete, truncated, or represented in another encoding. These fields describe the observation and the limits of the instrument.
A hash needs the same precision. A hash of stored text can support comparisons with that stored representation. It cannot establish the contents of bytes that were never retained. When capture is incomplete or encoded, describe the hash's scope rather than presenting it as a fingerprint of the full original request.
Treat network context carefully
A source IP identifies a network endpoint. That endpoint may be a VPN exit, proxy, shared server, or NAT device. A registration lookup can identify the network responsible for an allocation and a useful reporting contact; it does not identify the individual operating a client.
Headers need additional care because clients can supply them. A user agent is a claim, and a forwarded address is meaningful only within a verified proxy trust chain. Honeyglass preserves the socket peer separately and excludes mismatched forwarded-address claims from its enrichment and reporting paths.
Separate input from outcome
Text asking a model to run a command establishes that the text was submitted. It does not establish that a command ran. Likewise, a request to retrieve a model can reach a compatibility endpoint and be rejected without any download taking place.
Conversation histories can contain another ambiguity: a client can submit text with an assistant role. That text is evidence of the client's submission, rather than proof of an earlier model reply. Actual provider responses need their own record. Separating the two prevents a plausible-looking transcript from becoming an unsupported execution narrative.
Use enrichment as context
Reputation data can help prioritize an investigation. Its analysis date, missing fields, and source still matter. A vendor detection does not prove who sent a request or that the observed request was harmful. An undetected verdict or missing record does not establish that an endpoint is harmless.
Honeyglass makes IP enrichment an explicit operator action. It queries a validated public source address without forwarding prompts, headers, or payload bodies. The returned context is displayed alongside the event; it does not rewrite the captured evidence or automatically change reporting eligibility.
Review before reporting
Before contacting a provider, verify the timestamp and destination, exclude your own tests, and assess the request under the provider's policy. Routine service discovery alone is insufficient for an abuse report in this workflow. A substantive request still needs contextual judgment.
A useful report asks the operator to review a specific observation. It states capture limitations, removes unnecessary sensitive material, and avoids unsupported claims about compromise or successful execution. The recipient may have account and infrastructure records that the honeypot operator does not. A factual report helps them make that correlation without pretending it has already happened.
Publish the method, protect the record
Public research can explain an instrument's design and its limitations without publishing raw prompts, addresses, or operational endpoints. Keeping the private record distinct from the public explanation preserves room for careful review, correction, and responsible follow-up.