TL;DR
I started on a TRS-80, then grew up around Apple IIe computers, an Apple-CAT II modem, BBS systems, g-files, phone-phreaking lore and the MCI-code culture of the dial-up era.
Bell Labs later moved telephone signaling away from per-trunk in-band designs toward signaling independent of the customer transmission channel.
NIST now calls indirect prompt injection “agent hijacking.” The systems are different, but the old design smell is familiar: untrusted content can start sounding like control.
Long before I had words like threat model, trust boundary or adversarial input, I had an Apple IIe, an Apple-CAT II modem and a second phone line.
I ran a BBS. I learned assembly. I disassembled software to see what it was really doing instead of what the manual said it did. The boards I remember were full of g-files, phreaking lore, weird little discoveries and the kind of information that only made sense if you had spent enough nights staring at a terminal to understand the culture around it. MCI codes were part of that world too.
The interesting part was the question underneath it.
What does this system assume only it can say?
That question has followed me for most of my life. In 2026, it has a new target.
G-files were compressed curiosity
There was something almost absurdly efficient about a BBS. One computer. One modem (or two). One phone line (or two). Somebody dialed in, the machines negotiated with each other and suddenly a person who might live three states away was inside a little digital room you had built.
The text files mattered as much as the software. Jason Scott, who has spent years preserving BBS history at TEXTFILES.COM, traces the term “g-files” back to the General Files areas on early Apple II BBS systems. Those sections became places for informational, funny, technical and sometimes very underground text files. “General Files” became G-Files, G-Philes and eventually just philes.
That sounds quaint now. It didn’t feel quaint then. A few kilobytes could carry somebody else’s mental model of a system: what they noticed, what broke, what was undocumented, what behaved differently at 2:00 in the morning than it did in the manual.
I think that was the real education. Documentation describes intended behavior. Curious people discover actual behavior.
The Apple-CAT II fit perfectly into that world. I’ve written before that mine let me do things the documentation said I couldn’t. That sentence probably explains more about how I ended up in security than any certification ever could.
The phone network had a control-channel problem
Phone phreaking is easy to romanticize now because the hardware is old enough to feel like museum furniture. I don’t think the useful lesson is nostalgia, and I definitely don’t think it’s the tricks.
The useful lesson is architectural.
Bell Labs’ own technical literature described telephone signaling systems where control information traveled in-band, using the same voice path that carried customer traffic. A 1954 Bell System Technical Journal paper described in-band single-frequency signaling systems explicitly as systems that used the voice paths. By 1978, Bell Labs was describing the move toward Common Channel Interoffice Signaling, where signaling could operate independently from the channel carrying the customer’s conversation.
That distinction matters.
In-band signaling isn’t automatically insecure. The weakness appears when a user-controllable path can produce something the network treats as privileged control and the system doesn’t have a stronger way to distinguish who is allowed to issue that control in that context.
That’s the part the phreaking world learned to look for. Not “phones are insecure.” Something more precise: the network had assumptions about which signals meant what and where those signals were supposed to come from. Curious people tested the assumptions.
Some of that culture crossed legal and ethical lines. I’m not interested in sanding that history down until everybody involved looks like a harmless tinkerer. What stayed with me was the systems instinct: find the boundary where ordinary input can be mistaken for authority.
Prompt injection smells familiar
An LLM isn’t a telephone switch. A malicious sentence in an email isn’t a supervisory tone on a long-distance trunk. The analogy breaks if you push it too far … and it should.
But the architectural smell is familiar.
Modern AI agents process instructions and untrusted content inside the same broad interpretive environment. A user asks an agent to do something. The agent opens a website, reads an email or inspects a code repository. Somewhere inside that external material is text written by somebody else. If the model interprets the attacker’s text as a higher-priority instruction rather than data to be processed, control just leaked through the content channel.
NIST’s Center for AI Standards and Innovation calls this agent hijacking, also known as indirect prompt injection. In its March 2026 analysis of a large red-teaming competition, NIST described agents ingesting malicious instructions from websites, emails and code repositories, with the attacker trying to redirect the agent toward harmful actions such as data exfiltration or running malicious code.
OpenAI’s current framing is even more interesting to me. Its March 2026 security work says the most effective real-world prompt-injection attacks increasingly resemble social engineering rather than simple prompt overrides. That changes the defensive problem. You are no longer hunting for one obviously malicious string. You are asking whether the system can preserve the user’s intent while reading content designed to manipulate its interpretation of that intent.
That is a much older problem than the phrase “prompt injection.”
Control and content keep collapsing back together
The old telephone network eventually moved more signaling out of the customer voice path. The modern AI stack is moving in the opposite experiential direction. We keep asking one model to absorb everything: the user’s request, tool output, retrieved documents, emails, webpages, memory, previous agent messages and system instructions.
From a product perspective, that is elegant. From a security perspective, it creates a strange concentration of meaning. The same system has to interpret which text is evidence, which text is instruction, which text is hostile persuasion and which text is merely somebody talking about an instruction.
That is why prompt injection cannot be reduced to “make the system prompt stronger.” OpenAI’s own conclusion is that defenses cannot rely only on filtering inputs. NIST is evaluating the problem under adversarial pressure. OWASP’s 2026 agentic-security work includes prompt injection alongside privilege escalation and other risks that become more consequential when a model can take actions instead of merely produce text.
I’ve been writing recently about agent identity, delegated authority and why privileges should shrink as work moves through an agent chain. This is the upstream version of that problem. If untrusted data can alter the agent’s interpretation of what it was asked to do, narrow authority becomes the thing that limits how expensive the mistake can get.
Different control. Same habit of thought.
The part experience actually buys you
I don’t think being around early computers gives anyone magical insight into AI. Plenty of people were there and learned completely different lessons. Experience only matters if the old failures stay mentally available when the abstraction changes.
What many decades does give me is pattern memory.
I’ve watched systems move from phone lines and modems to IP networks, cloud APIs and now action-capable models. The interfaces changed. The names changed. The same categories of mistake keep walking back into the room wearing better clothes: trust based on location, authority that is broader than the task, control information mixed with ordinary traffic, systems that assume an input could only have come from the “right” place.
That is why the old BBS years still feel relevant to me. The Apple-CAT, the g-files, the phone system, the MCI-code lore and all the strange little corners of dial-up culture trained an instinct before I knew it had, or was going to be given, a professional name.
Look at what the system assumes.
Then look for the place where the assumption becomes executable.
Today, that might be a model reading an email and deciding whether a sentence inside it is information or instruction. Forty years ago, the surface looked different enough that nobody would have called the problems related.
I would not call them the same vulnerability now either.
I would call them the same warning.
If your architecture cannot explain why this input is data and that instruction is authority, somebody will eventually make the distinction for you.
Resources
A. Weaver and N. A. Newell, Bell System Technical Journal, “In-Band Single-Frequency Signaling” (1954): https://www.nokia.com/bell-labs/publications-and-media/publications/in-band-single-frequency-signaling/
C. A. Dahlbom and J. S. Ryan, Bell System Technical Journal, “Common Channel Interoffice Signaling: History and Description of a New Signaling System” (1978): https://www.nokia.com/bell-labs/publications-and-media/publications/common-channel-interoffice-signaling-history-and-description-of-a-new-signaling-system/
NIST CAISI, “Insights into AI Agent Security from a Large-Scale Red-Teaming Competition” (March 23, 2026): https://www.nist.gov/blogs/caisi-research-blog/insights-ai-agent-security-large-scale-red-teaming-competition
OpenAI, “Designing AI agents to resist prompt injection” (March 11, 2026): https://openai.com/index/designing-agents-to-resist-prompt-injection/
OWASP Gen AI Security Project, “AI Security Solutions Landscape For AI and Agentic Red Teaming Q2 2026” (April 9, 2026): https://genai.owasp.org/resource/ai-security-solutions-landscape-for-ai-and-agentic-red-teaming-q2-2026/
Jason Scott, “The Age of Reason: An Apple II BBS” (historical discussion of General Files / G-Files): https://ascii.textfiles.com/archives/1461
Editorial note: Personal references to Apple IIe, Apple-CAT II, BBS operation, g-files, phone phreaking and MCI-code culture are based on Steve’s supplied history and previously published Morphic material. The article intentionally omits operational phreaking methods, access codes and instructions.