The research question
What reaches a publicly accessible AI interface, and what can its operator reliably conclude from those requests? Honeyglass approaches that question through a deliberately limited service: familiar model API behavior, bounded request capture, and a private investigation workflow.
The project records requests that reach the application. It does not assume that every visitor is an attacker, that a submitted instruction executed, or that a network address identifies a person. Those distinctions shape the implementation as much as the interface.
From observation to review
- Observe. Present a text-only chat interface or an Ollama-compatible service profile and record the requests that reach it.
- Preserve. Keep request metadata, bounded body evidence, application outcomes, and capture limitations together.
- Enrich. Request network registration or IP reputation context for an eligible source address when an operator needs it.
- Review. Inspect the event and its context before deciding whether an external report is appropriate.
A limited capability surface
Honeyglass supplies no shell, browser, filesystem tools, or model-management executor. Its compatibility profile emulates discovery and chat behavior; an advertised model name does not mean that model weights are installed. Unsupported model-management requests are captured and rejected.
Capture-only mode works without an AI provider. Chat requests receive an explicit unavailable response instead of an invented model reply. With a provider connected, only the operator chooses the upstream endpoint, system prompt, and real model. Input size, output, concurrency, and provider-call limits bound that path.
Evidence with its context intact
The private dashboard separates submitted text from actual provider responses. It retains the observed socket peer separately from any resolved client-address claim, and displays captured content as text. Requests, rejected input, and incomplete captures can be inspected without following embedded payload links.
On-demand registry lookup can identify a network's published abuse contact. Optional VirusTotal enrichment adds vendor verdicts, reputation, network information, and available analysis dates. That lookup sends the validated source IP, rather than prompts, headers, or request bodies. Enrichment provides context and does not establish attribution or automatically make a request reportable.
Reporting remains a decision
Opening a report prepares a factual draft from a captured event and official registration data. The operator reviews the recipient, checks the event against their own tests, and can redact sensitive material before sending. Public traffic never triggers email submission on its own.
Routine discovery alone is insufficient for reporting in this workflow. Even a prompt or model-management attempt needs contextual review: use of a reachable service does not itself establish abuse, and the captured request does not prove successful execution. Delivery records also distinguish SMTP acceptance from confirmed arrival.
What this project can tell us
Honeyglass observes application requests, not every packet or event along the network path. Traffic blocked upstream, invalid HTTP rejected before a request exists, storage failures, and configured capture bounds limit the record. The stored representation and its hash must be interpreted alongside those limits.
This public project brief explains the design without publishing operational endpoints or raw captures. The accompanying methodology notes describe how the evidence boundary and the capability boundary inform the work.