Does this mean Jailbreaking in a purely conversational context is no longer important?
No, that's not the point—defense in purely conversational contexts is still important, it's just that, relatively speaking, this area has already received a lot of research and hardening, so its defense mechanisms are relatively mature; defense against the tool-calling path is a relatively newer area, still under continuous development and reinforcement. The point of this article is that "a rational attacker will tend to seek the relatively weaker line of defense," not that conversational defense is no longer needed—it's a reminder that security investment priority shouldn't assume "covering conversational defense means covering all the risk."
In practice both need investment, it's just a matter of resource allocation: if an agent application has both conversational capability and tool-calling capability, the tool-calling path currently deserves relatively more priority attention, since that's the direction attackers are now more likely to target.
If an agent application only has read capability, no write or action-execution capability, does that mean this risk isn't a concern?
The risk genuinely is lower, but that doesn't mean it's not a concern at all. Even if an agent only has read capability, if what it reads gets integrated into the final answer presented to the user, injected malicious content could still influence the information the user receives through that channel (like being misled into outputting a summary containing incorrect or misleading content). While this doesn't cause damage as directly as executing a deletion action, it can still cause misdirection at the informational level.
What genuinely reduces risk substantially still comes back to the principle of least privilege: the scope of capability granted to an agent should precisely match what the task actually needs. If a task inherently only needs reading, it shouldn't also be granted write or execution capability alongside it—that way, even if the content read gets injected with an attack, the damage stays confined to the "information presentation level" rather than expanding to the "actual system operation level."
Could this problem ever be fully solved, or will it remain an ongoing risk indefinitely?
Given the current state of technology, a more realistic expectation is "continuously reducing risk, rather than eliminating it entirely." This is similar to the situation jailbreaking faces—defense mechanisms keep getting updated as new attack techniques emerge, but it's hard to claim it's "fully solved" past some point in time, because this is fundamentally an ongoing evolutionary process between attackers and defenders. Once a new defense technique appears, attackers will also try to find new ways around it.
For users and developers, a more practical attitude is treating this risk as something that needs ongoing management rather than a one-time problem to be solved—periodically staying on top of defense mechanism updates, and maintaining extra caution and confirmation mechanisms for high-risk tool-calling capabilities, better matches reality than expecting "someday this problem will be completely solved."
In daily use, what can everyday, non-developer users actually do to reduce this kind of risk?
For everyday, non-developer users, the most practical principle is staying extra alert to the combination of "asking an agent to read external content from an unclear source, while that same agent is also authorized to perform real actions." For example, if you ask an agent capable of sending email to read the content of a public webpage and summarize it, that combination itself is worth an extra layer of caution, especially if the webpage's content isn't from a source you fully trust.
A simple practical self-protection habit: for agent features that actually execute an action (rather than just producing a text answer), spend a moment confirming the action genuinely matches your expectation before it actually executes, especially when the action's content looks like it diverges from the task you originally assigned—that divergence itself could be a signal that an embedded instruction influenced the agent's judgment.
When AI Safety comes up, most people's intuitive image of an attack scenario is jailbreaking—a user in conversation trying every trick to induce the model into saying something it shouldn't. But as agent applications have become more widespread, the safety research community has gradually zeroed in on a more concerning pattern: attacks causing genuine real-world damage increasingly run through an agent's tool-calling path, rather than simple conversational inducement. This article covers the logic behind this shift, rather than repeating an introduction to Jailbreaking itself.
Jailbreaking in a purely conversational context, even if successful, causes relatively limited real damage the model can inflict—the worst outcome is usually outputting some text content that violates policy. That text itself doesn't proactively modify your files, doesn't send email, doesn't execute any real action; the damage stays confined to the level of "text output," which the user can choose to ignore, report, or simply disregard once they see it.
Once an agent is given tool-calling capability—reading and writing files, sending messages, operating external systems—an attacker's target is no longer inducing the model to "say" something, but to "do" something. This difference is qualitative, not just a matter of degree: being induced into outputting a piece of inappropriate text versus being induced into actually executing an action like deleting a file or sending an email are on completely different orders of magnitude in terms of real consequence. And the process of an agent reading external data (webpages, documents, email) provides exactly the channel that lets an attacker deliver a malicious instruction to the agent without needing to directly converse with the user at all—which is precisely why Prompt Injection deserves particular attention. It bypasses the user's own awareness and defenses entirely, shifting the attack surface directly onto third-party data an agent will process.
Thinking from an attacker's perspective, this shift actually follows rational logic: jailbreaking directly in conversation puts an attacker up against defenses the model has been specifically trained on for scenarios like "a user actively trying to induce it." Attacking through the tool-calling path instead puts an attacker up against the relatively newer, still-developing territory of "can the agent correctly distinguish task instructions from external data content." A rational attacker will prioritize seeking out the relatively weaker line of defense, rather than going head-to-head against a frontal defense that's already been extensively researched and hardened.
If you're evaluating whether to give an agent application the capability to actually execute actions (rather than just producing text answers), the shift covered in this article carries a concrete practical implication: security investment priority shouldn't only go toward "preventing a user from inducing the model into saying the wrong thing." Equally important—possibly even more important—is permission scoping for when an agent reads external data, and whether the agent can correctly distinguish the source of an instruction. For enterprise users, when evaluating the security risk of adopting an agent application, the tool-calling path should be given priority equal to, or even higher than, conversational defense—this judgment directly affects where security investment is most effectively spent.