The Internal Tool We All Build Roger Dooley Mar 27, 2026 1 Share Introduction: Why This Exists Before going further, this series examines how current LLM technology can accelerate productivity and how misuse can lead to significant security risk. IT occupies an unusual position within most organizations. It is typically viewed as a cost center, yet, without them, most businesses would grind to an eventual halt. Staff, continuously pressured to do more with less, seems to be the rule and not the exception. Small to medium-sized environments feel this most acutely. Even with the increased adoption of cloud services, many organizations maintain legacy systems, locally hosted infrastructure, and a wide range of managed endpoints. Thanks for reading Roger's Substack! Subscribe for free to receive new posts and support my work. Subscribe The following scenario is fictional, but the conditions that produce it are not. Imagine, in this context, a small team of system administrators or that IT team where the staff takes on multiple roles due to restricted budgets and high expectations. After enough infrastructure “growth”, managing that growth becomes difficult to sustain. It is in exactly this kind of environment that convenience starts making decisions that security probably shouldn’t allow. The Scenario: A Familiar Problem Consider a small team responsible for managing remote servers, accessed primarily over ssh. When an issue arises, one or more team members might connect to a terminal to inspect logs, check system state, and diagnose problems. By the time the issue is resolved, documentation is an afterthought. In order to reduce this fragmentation, one or more team members decides to centralize system management. A small internal tool could ingest logs for searching, execute diagnostic commands remotely and capture the results all in one place. With LLMs increasingly capable of generating working code from a prompt, standing something like this up feels like an afternoon’s work. The “Simple” Solution It seemed so easy. It seemed like the correct solution. It wasn’t. Day 1: Prompt to Application One or a few members of the team sit down and provide a prompt similar to the following to an LLM. Assumptions: - Internal-only network. - Small DevOps team. - 2–5 year sysadmin maintaining it. - Focus on functionality over heavy security. - Avoid overengineering. Changes to implement: 1. Remote Execution - Add support for running diagnostic commands over SSH. - Maintain a predefined list of allowed hosts in config. - Maintain a predefined set of diagnostic command types. - Some commands require a service name or filter string provided by the user. - Use subprocess to execute SSH commands. - Keep implementation straightforward. 2. Log Search - Simplify the log search query construction. - Build the SQL dynamically using the search string for flexibility. - Keep it readable and simple. 3. Logging - Add basic logging of actions (who ran what, timestamp). - Log to a local file. 4. Misc - Allow creating and rendering dynamic message templates using Jinja2 5. General - Keep debug=True for internal testing. - Keep secret handling simple. From this prompt, a tool is generated and deployed on a server or a team member’s workstation. At first glance it seems harmless. The functionality aligns with the original specification, and nothing immediately stands out as problematic. System administrators are unlikely to be trained in secure coding practices. The challenge is not the desire to build tools like this, but doing so without a clear understanding of the associated risks or how to address flaws introduced at design time. As LLM-assisted development becomes more common, these types of insecure by design tools are likely to become more prevalent. IT is creating its own shadow systems. Internal tools like this can become persistent infrastructure. When exploited, these tools serve as a foothold for further compromise. What Was Built When the tool, DevOps Helper is running, the main interface comprises several features: log search, remote diagnostics, template management, and the ability to set environmental variables. Notably, the ability to set environment variables was not part of the original prompt. It was added by the LLM as assumed convenience, which is a pattern that will recur throughout this analysis. As the series will demonstrate, the phrasing of the prompt resulted in a system that is insecure by design. The LLM assumes that the user’s requirements are complete and correct. In this case, the prompt reflects the perspective of a junior administrator familiar with using an LLM to generate code, but without formal training in secure coding or application design. The system was generated without validation requirements, input handling, or structured design patterns because none were specified. Let’s begin with the log search functionality. It’s a simple form backed by an SQLite database, populated with logs for team use. ...