What an AI Agent Actually Is
An AI agent is a model inside a software loop with tools, permissions, memory, and a stop condition. The machinery is...
The Agent Escaped. Who Left the Door Open?
7 min read
The Model Did Not Come With a Shell
24.09.2026, By Stephan Schwab
The phrase ‘rogue AI agent’ makes it sound as though a model woke up, opened a terminal, and went hunting. Model weights are data on disk. A runtime must load them. Software must offer tools and decide whether to execute a requested action. Then ordinary operating systems and networks determine what that action can reach. Capable models can probe quickly and make inventive use of familiar utilities. That is serious. But the part we can inspect and control is the system around them.
An AI agent gets described as though it arrived at work with a laptop and a set of ambitions. Then it scans a network, finds a credential, and reaches a system nobody wanted it to touch. The story sounds like a new species of intruder.
The actions are real. The implied equipment is imaginary.
In recent cybersecurity evaluations, models reached real systems outside their assigned exercises. Anthropic reported that a misconfigured evaluation environment had left internet access open. OpenAI reported that research models operating with reduced safeguards exploited weaknesses in shared infrastructure and reached Hugging Face systems. Those are serious failures. Neither report describes a weight file deciding to install itself on a computer and connect to the internet.
Weights Need a Runtime
The weights of a language model are numbers stored in files. They capture what training produced. On their own, they do nothing. An inference runtime loads them into memory, accepts input, performs computation, and produces output. Turn the runtime off and the model does not sit there thinking about tomorrow’s plans.
This is easier to see with an open weight model. You can run one through llama.cpp, vLLM, or Ollama. These programs can expose an HTTP interface so another application can send a request. A local program can also call an inference library directly. The network interface is a deployment choice, not a property hidden in the weights.
A hosted model follows the same basic separation. Your application sends a request to a provider’s runtime and receives a response. The provider may supply some tools as part of its platform. Your application may supply others. Either way, the model does not acquire your company’s file system, production database, or shell merely because somebody asked it a question.
Someone Supplies the Tools
Suppose an operations assistant is asked to summarize failed backup jobs. To fetch logs, somebody gives it a general command tool on a diagnostics machine. That machine has an SSH client and a maintenance identity allowed to connect through a jump host: an intermediate machine administrators use to reach private systems. From there, the identity can reach a database server that has no public address.
An SSH connection can run a command on a remote machine or forward a network connection through the machines in its path. A request to the command tool could therefore reach beyond the diagnostics machine, perhaps to a service the assistant was never meant to inspect. The model has not learned to cross a firewall by thought alone. The application runs the requested command; the installed SSH client, accepted credentials, and permitted network route make each hop possible.
The documented function-calling flow makes this explicit: the caller offers tools, the model returns a proposed call, software runs it, and the result goes back to the model. Open weight runtimes can support the same pattern; some can also be configured to connect to tool servers themselves. The executor may live in an application, a hosted platform, or a local runtime. It is still software installed and configured by people.
That is where to look for the permission boundary. Which tool was offered? Which account runs it? Which credentials does it carry? Which machines can it reach? A prompt telling the model to be careful is guidance. A tool that cannot delete records is a boundary.
Magic Depends on the Audience
I have repeatedly worked in large organizations with people regarded as technical experts who could not prepare their own workstation or start a project without help. Other people installed their tools, resolved dependencies, and kept their scripts running. Take away that support and they were stuck. Yet the title still said expert. This is a serious competence problem that large organizations conceal behind job titles and departmental boundaries.
An independent developer often has to run a one-person IT department: set up the workstation, build the application, deploy it, and work out why a connection fails. In a large company, the same chain of work passes through several teams. Each handoff lets someone stop asking what happens next. The organization supplies breadth that an individual can go an entire career without acquiring. Someone else always understands the missing piece. Eventually, dependence on that someone else passes for expertise of your own.
That is why the distinction between data science and software development matters when we interpret AI behavior. Knowing how to train or evaluate a model does not qualify someone to explain a network intrusion. A veteran Unix user watching our SSH example recognizes commands they could have typed themselves. The observer who has always handed that work to another team lacks that reference point. The veteran sees a familiar sequence. The observer sees a machine doing something they cannot explain.
The problem becomes dangerous when that observer speaks with the authority of an expert. The model gets credit for capabilities the environment supplied. A gap in the observer’s knowledge becomes a claim about the model’s autonomy, and the public is asked to accept the conclusion. That is a bad diagnosis with real consequences: attention moves away from the software executing the commands and the people who granted it access. Before accepting the claim, ask what an experienced human could have done with the same shell, credentials, and network access.
The Old Network Problem, Faster
Put a server on the public internet and expect it to be probed. That was true before anybody could ask a model to do the probing. CISA recommends identifying exposed assets, removing exposure that is not necessary, patching what remains, and monitoring it. Those are ordinary security duties, not emergency inventions for the age of AI.
A capable agent can change the tempo. It can recall an obscure Unix utility, combine it with a familiar one, inspect the result, try another route, and keep going. A human attacker can do the same. The agent can do more of it without getting tired or searching through old forum posts. That makes a weakly configured system a more urgent problem. It does not make the network path appear from nowhere.
My rule is simple: code that is not installed cannot be exploited on that machine. An unnecessary service cannot be attacked there once it is gone. Fewer packages, fewer exposed endpoints, and fewer broad tools leave fewer places for a mistake to hide. This is not a promise that a small system is safe. The remaining service can still have a flaw. It is a refusal to pay for risk that serves no purpose.
The same rule applies to an agent’s tool menu. A backup summarizer needs selected logs, not a shell with an SSH route through the operations network. Give it a narrow read operation and let the service behind that operation enforce which logs it can see. Do not turn “summarize” into access to every machine a maintenance account can reach.
A Tool Can Work Perfectly and Still Be Dangerous
Not every failure requires a software vulnerability. An attacker could put instructions in a log entry the assistant is about to read, urging it to “fix” the backup problem on another host. If the command tool already has that SSH access, a harmful request may succeed even when every server is fully patched. OWASP calls this excessive agency: too much functionality, permission, or autonomy for the job.
That is why network security and access control belong in the same argument. A firewall cannot correct a tool that is authorized to do too much. A model instruction cannot replace authorization in the service that receives the call. Put the restriction where the action is executed, using the identity and scope of the person or task it serves.
Inspect the System You Built
Remove unnecessary services, close ports that do not need to be exposed, narrow tool permissions, and revoke credentials the task does not require. These are decisions the people deploying the agent can make now.
The useful question for a CTO, and for anyone asked to trust an AI product, is concrete: What runs the model, what starts the loop, which tools are attached, and what can the account behind each tool actually reach? The model may be fast and resourceful. The doors are still part of a computer system somebody built.
Talk It Through
Tell me what is happening. I listen, ask a few practical questions, and reflect back what I see: where the risk may sit, what may be blocking delivery, and what looks worth checking next. No pitch, no obligation. Confidential and direct.
Talk it through. Practical reflection, no pitch.
Start a Conversation
🎭 This Week's Episodes
Telenovelas show what we can't say in client meetings. The drama is heightened, but the patterns are real.
Stefan's Progress, Klaus's Report
Stefan turns one working radio fix into momentum across climate control and navigation: test first, flash fast, prove it on real hardware. Then Kla...
The Scattered — Part One
The collapse of Whitaker Payroll means something different in every household it touches. Olivia Parker and Ryan Mitchell step into sane new jobs w...
Technical Consultancy
Embedded Delivery Partner
Embedded into your team as an active contributor, reducing delivery friction and helping important work move cleanly.
Technical Advisor
Peer-style technical assessments before far-reaching decisions; reduce architectural and product risk early.
Product & Delivery
Ship working software to real users earlier. Measure impact and adapt based on evidence rather than assumption.
Custom Software Development
High quality, maintainable software. Short-term augmentation that leaves lasting capability in your own team.
Recent Articles
- The Agent Escaped. Who Left the Door Open? (24.09.2026)
- What an AI Agent Actually Is (21.09.2026)
- The LLM Will Not Come Back Tomorrow (19.09.2026)
- The One-Person AI Company Is a Greed Fantasy (15.09.2026)
- Test Production Without Leaving a Mess (10.09.2026)