In the brief history of AI security, the prompt injection has quickly become the top threat. Large language models are inherently unable to distinguish between legitimate instructions provided by users and malicious ones sneaked into emails, source code, and other third-party content the models are processing. This makes it trivial to surreptitiously inject malicious commands that the LLM readily follows.

With no way to enforce this crucial boundary between trusted and untrusted sources, AI engine developers are left to erect elaborate guardrails designed to mitigate the damage rather than solve the root cause.

To date, most prompt injections have fallen into a class known as push, in which each potential victim is targeted. For example, the adversary injects malicious instructions into an individual email or calendar invitation. Because the injection must then be sent (or pushed) to each specific target, the scale of the attack is limited, hampering mass exploits that hit the Internet at large.

Read full article

Comments

The price of AI tokens is fluctuating widely, with some becoming cheaper and others more expensive, leaving users of AI services struggling to assess if the price is right. Aman Panjwani, an AI engineer based in India, says that GPT-4-class model output cost about $20 per million tokens in late 2022. Today, equivalent capability costs about $0.40, a 55x decline in less than four years, he said, citing Introl’s December 2025 unit-economics analysis. “When DeepSeek released its R1 reasoning model in January 2025 at $0.55 per million input tokens and $2.19 output – against OpenAI’s o1-preview at $15 and $60, launched just four months earlier – the entire market repriced overnight,” Panjwani said in an analysis provided to The Register. “A 97 percent discount tends to do that.” During this same period, prices for cutting-edge frontier models surged. “OpenAI doubled the price of GPT-5.5 to $5 input and $30 output per million tokens – that’s on its own pricing page,” said Panwani. “Google’s Gemini Flash 3.5 arrived three to six times more expensive than the model it replaced.” The recent release of Anthropic Claude Sonnet 5 continues that trend. Even though its per-token price is lower than Claude Opus 4.8, it uses more tokens to produce the same results. Anthropic’s Mythos and Fable models are also quite costly, when available. Also this year, Anthropic moved corporate customers away from per-seat pricing to metered pricing and limited permitted uses of its subsidized subscription plans. Panjwani argues such moves show the token market is splitting in two, with commodity inference heading toward zero even as frontier inference costs rise. Ameya Kanitkar, CTO of Larridin, an AI measurement platform, said that about six months ago, AI costs were a primary concern because companies spent between $20 and $100 per month per LLM subscription. But around February, AI services vendors companies began pushing for more AI usage at a time when the models were getting better and could handle more complex agentic work that takes longer to complete. “On average we have seen the cost go up about 10x between January and now, especially in engineering ops,” Kanitkar said in an interview with The Register. It’s a change he attributes to the shift toward longer, agentic tasks and metered pricing. “The new trend that is emerging is that the open source models, open weight models are actually not that far behind the frontier models,” he said. “And now the costs are hitting the balance sheet, which are not the real costs, companies have started truly thinking, ‘okay, how can we actually adjust these costs?'” Kanitkar said he’s seeing companies spending between 10 and 20 percent of their labor cost – e.g. $2,000 to $4,000 per month for a software engineer paid $200,000 annually – on tokens. But, he added, higher spending doesn’t necessarily mean higher productivity. Between 15 and 30 percent of AI users among Larridin’s clients account for more than 50 percent of total AI spend, and often that spending does not correlate with gains in output, according to a company spokesperson. When Larridin plotted token spend against developer productivity, it found an inflection point at about 35 to 40 percent of client spending where burning more tokens failed to boost productivity. Using that point as a token limit for employees can cut AI costs by 40 percent without changing anything else, Kanitkar said. Open weight models offer another cost lever. Kimi 2.6/2.7 and GLM 5.2, Kanitkar said, “are almost at parity with Opus4.7 or 4.8. And they are 10x cheaper in theory, or about 5x cheaper in practice. They tend to be a little bit slow and they tend to consume more tokens on the pure token basis – that costs more, but the token cost is low.” Kanitkar said he’s now seeing almost 75 percent of companies use multiple models. Switching back and forth, he said, is more difficult for customer-facing agentic work, but for software development, it’s much more viable. Even so, price isn’t always the most important consideration. Larridin data shows that enterprises still direct almost half of their AI spending toward Anthropic’s Opus model because it handles complex engineering and reasoning tasks well. ®

SYSTEMS APPROACH A few weeks ago, Larry and I independently received the same advice from two different sources: take a look at Media Over QUIC (MoQ) for your next edition. I’ve been following the standardization of QUIC for several years (and wrote about it) but MoQ had not yet come onto my radar. A quick look at some IETF drafts gave me some of the main concepts, but it can be frustratingly hard to pick out the important high-level ideas from the masses of protocol-specific detail that goes into an Internet draft. And there are enough moving parts to MoQ for it to present another case of the blind men and the elephant. I’m going to explain what I think is important about MoQ in this post. For one thing, the name doesn’t get across what is interesting to me about MoQ. Yes, it can be used to transmit media (e.g., video and audio) using QUIC as the underlying transport protocol. But you can do that today just by watching a video on the web if the server happens to support HTTP3 over QUIC. There is something else going on with MoQ. In my view, MoQ occupies a middle ground between WebRTC (which is used for lots of video conferencing applications like Google Meet) and DASH (Dynamic Adaptive Streaming over HTTP) which powers most entertainment video streaming on the web. If I take some of the proponents of MoQ at face value it could replace both those technologies, but more realistically I can see it filling a gap when neither DASH nor WebRTC is the ideal choice. So let me first explain the two bookends that MoQ sits between. There are two handy blogs positioning MoQ against WebRTC and DASH that helped me form the views below, so you may want to go back to the source. WebRTC is a collection of protocols and APIs (backed by an open source implementation) that enable a real-time media stream to be established between a pair of web browsers. There are quite a few problems that need to be solved, such as getting access to the camera and audio devices, and building an end-to-end connection between two hosts that might both be sitting behind NATs and firewalls. The media is sent using RTP over UDP (usually). This all works reasonably well today as evidenced by the success of browser-based video conferencing. Arguably the biggest weakness of WebRTC is around scale. Large conferences generally need an overlay network to replicate the video streams out to all the participants. In the case of WebRTC, the overlay nodes are called Selective Forwarding Units (SFUs). They are typically deployed by the conferencing app provider to scale out their meetings; as I understand it, there are SFU overlays for Teams, Google Meet, Zoom, etc. DASH is the approach used to stream most non-real-time media. The standard view is that TCP is not a suitable protocol for real-time streaming, due to its strict ordering and use of retransmissions to ensure reliability, leading to potentially unbounded delay. But since most entertainment video is not strictly real-time, DASH manages to work around the limitations of TCP, leveraging TCP congestion control along with the benefits of standard web infrastructure. In particular, DASH gets to scale thanks to the existing deployment of CDNs. And as the web is starting to adopt QUIC in place of TCP for HTTP traffic, DASH gets some benefits of QUIC as well. What DASH is not really able to do, however, is deliver low enough latency to meet the needs of real-time applications. With QUIC providing reliable delivery of each chunk of video, there is still no way to bound latency. A CDN For Real-Time Streams What MoQ aims to do is offer latency closer to that of WebRTC with the scalability to support massive numbers of receivers that comes with DASH. The key to scalability in MoQ is the use of relays, a form of overlay that handles replication of media. Just as CDNs can scale the delivery of HTTP traffic, MoQ relays are designed to scale the delivery of MoQ traffic. They do so by supporting a publish/subscribe model for media distribution. In MoQ, the main abstraction is a track, which might, for example, correspond to a particular live stream encoded at some resolution. Publishers publish media to the track and subscribers receive it. With relays sitting between publishers and subscribers, the two groups don’t need to have direct connections or even know about each other. As its name implies, MoQ uses QUIC as the underlying transport. This might seem at odds with the desire to minimize latency, since QUIC, like TCP , uses retransmission of lost packets to ensure reliable delivery. MoQ takes advantage of some of the features of QUIC to get around this. In particular, the lightweight streams of QUIC allow for independent components of a QUIC connection to proceed without being blocked by each other. So MoQ uses streams to ensure that different parts of a media stream can be sent independently of each other. One use of this is to discard the higher resolution parts of a video if necessary to deal with congestion. It is also possible to just terminate a stream if, for example, the observed level of congestion suggests that sending this part of the media would only exacerbate congestion, or the information in the stream would arrive too late to be useful. MoQ objects have an associated priority that can be used to make decisions about which streams to transmit and which to terminate. The lightweight streams of QUIC stake out an intermediate point in the design space between TCP and UDP. Reliable delivery can be applied selectively to individual streams, and congestion control can limit the total amount of traffic in a QUIC connection when required. Lower priority streams can be sacrificed to ensure that latency remains within bounds, congestion is avoided, and more important packets are not stuck waiting for less important ones to arrive. MoQ relay nodes can store, forward, and replicate objects. They don’t need to have any understanding of the content; objects are self-contained pieces of data that carry enough metadata, which is visible to relays, to enable them to be handled appropriately. A typical object in MoQ would be an independently decodable set of frames in a video. The metadata allows the relay nodes to make decisions about how to prioritize transmission of objects in the event of congestion or other resource shortage. Metadata also enables subscribers to determine what track an object belongs to. Application Layer Framing Lives On It strikes me (thanks to a conversation with Larry) that MoQ captures the idea of Application Layer Framing (ALF) that Clark and Tennenhouse proposed in 1990. Only the application knows what data it needs to do its job, but it can frame the data in such a way that the network can help the application function. MoQ lets the application define objects that represent units of video that can be independently decoded, and prioritize those objects based on their importance (e.g., lower priority for high frequency components of the video). The relay nodes don’t have to understand the application at all—they just use the metadata to relay objects in a way that benefits the application, which isn’t something SFUs can do. This also makes MoQ more useful than IP multicast (which has the additional downside of adding complexity to the network’s core). The specifications for MoQ are still evolving and implementations are trying to track the specifications. Nevertheless, this approach draws on the success of existing technologies such as QUIC and DASH and has the weight of major industry players behind it, so there is reason to be optimistic for its future. The implementation of the relay function in large-scale deployments (e.g., Cloudflare) indicates the industry investment in MoQ. It also suggests that the idea of trying to replicate the success of CDNs for real-time streams might have traction. And if you want to see MoQ in action, you can try a demo here or here. ® Larry Peterson and Bruce Davie are the authors behind Computer Networks: A Systems Approach and the related Systems Approach series of books. All their content is open source and available for free on GitHub. You can find them on Mastodon, their newsletter right here, and past The Register columns here.