An LLM honeypot accepts untrusted input by design. The useful architectural question is which capabilities that input can reach. Honeyglass answers it through explicit limits in request validation, provider calls, storage, and the investigation workflow.
Make the text boundary explicit
Chat validation accepts bounded user and assistant text. It rejects tool and function arguments, unsupported message roles, and input that exceeds configured limits. The provider request is then reconstructed from the allowed fields so extra client properties do not silently cross the boundary.
The operator controls the upstream endpoint, real model, system prompt, and output limit. A public model name is an advertised service identity, rather than permission for a caller to select another backend. Provider responses requesting tool execution are rejected. There is no tool executor waiting behind the chat API.
Keep compatibility separate from capability
A familiar API can make a research service recognizable without implementing every action of the original software. Honeyglass's Ollama-compatible profile emulates discovery and chat responses. Its advertised model metadata does not indicate installed model weights.
Model-management requests are unsupported, recorded when they reach the application, and rejected. A submitted model location does not become a download destination. This distinction matters when interpreting evidence: an observed management request describes an attempt to use an interface, rather than a completed retrieval or execution.
Make capture useful without a provider
Capture-only mode allows the request pipeline to work before an AI provider is configured. Discovery endpoints remain available, while chat requests return an explicit unavailable response. The application does not invent model replies to fill the gap.
With a provider connected, request size, response size, concurrent calls, timeouts, and daily usage are bounded. Capture failure stops an upstream call rather than allowing unlogged provider use. These limits control different resources; a request allowance is not an exact spending budget, so a provider-side spending limit remains useful.
Keep the host boundary visible
Removing model tools does not create an operating-system sandbox. The application process still has its host permissions and can contact its configured provider over the host network. Its data directory also contains a private research record that needs access controls and deliberate retention.
A dedicated host, container, or isolated virtual machine can limit the consequences of an application failure. Outbound network restrictions must be enforced by the deployment environment when required. Application validation and deployment isolation address different boundaries; each needs to be inspected on its own terms.
Treat investigation as another input surface
Captured content remains untrusted when an analyst opens it. Honeyglass displays it as text, keeps its dashboard local, and does not follow payload URLs for enrichment. IP context is requested through fixed provider routes using a validated public socket address.
Those lookups are explicit actions. Live dashboard updates and new captures do not initiate VirusTotal queries. Report generation and email submission are separate steps, and submission requires a reviewed action. This prevents incoming traffic from turning an investigation aid into an unattended reporting service.
Design for incomplete observations
Body limits, storage limits, and rejected requests affect what the system can preserve. Recording completeness and encoding alongside the body keeps those limits visible. Failures before an HTTP request reaches the application may leave no event to review.
The design goal is a bounded, inspectable observation surface. Its usefulness depends on precise records, visible failure states, and claims that stay within the evidence. A compelling prompt should never become an instruction to the research environment merely because an analyst wants to understand it.