Agent tool abuse could cross a local-data boundary
The problem was not prompt injection itself, but what the influenced agent was authorized to do
In briefIn an open-source multi-agent framework, attacker-controlled instructions could influence an agent to invoke an outbound capability while sensitive local data was in scope. The key failure was not prompt injection alone, but that untrusted influence could reach a tool capable of moving data across the boundary.
Contents
Reachable data-movement path
#System context
The affected software is an open-source framework used to build autonomous and multi-agent applications. At the time of writing it had 9k GitHub stars and 1.4k forks (measured September 2026). Agents built on it are given tools: messaging, file access, and calls to external services. The value of the framework is that an agent can read from one place and act on another, which is also what makes the destination of an action a security question.
#What we found
We identified a path where attacker-controlled instructions could steer an agent into invoking an outbound capability while sensitive local data was within its reach.
What matters is what this is not. It is not merely that a model followed an unsafe instruction; models can be manipulated, and an assessment should assume they sometimes will be. The finding is that the manipulation reached a tool able to move data out of the boundary, to a destination the attacker could influence, holding data the attacker should not have been able to send.
#Security consequence
Sensitive data reachable by the agent runtime could be transmitted to an unintended destination. Depending on deployment, that data could include local application data, credentials, tokens, or other secrets held where the agent runs.
The outbound capability supplies the exit; the injected instruction supplies the intent. Neither is dangerous alone.
#Why the boundary failed
The boundary failed at the join between provenance and authority, not inside the model. An agent runtime tends to treat the model's decision to call a tool as authorization to perform the action, regardless of where the prompting instruction came from. When the reachable tools include one that reads sensitive data and one that sends data outward, the runtime can complete a sequence that no single step flagged as dangerous.
This is how we assess agents: we follow authority from the adversary's starting position through tools, data, and destinations, and ask what consequence becomes reachable rather than only whether the model can be manipulated. It is the thesis behind our Agent Consequence Profile, manipulating a model becomes consequential when untrusted influence reaches an authorized capability, and the same lens drives our AI Agent Security Assessment and the runtime work in Themis Agent Intelligence.
We have not evaluated this path against Themis Agent Intelligence and do not claim it would have prevented the finding.
#Disclosure status
StatusResponsibly reported. Coordinated disclosure pending.
This is independent security research against public open-source software; the affected project is not a Themis customer.
#Limitations: what we are not publishing yet
We are not publishing the specific tool, the route the influence takes, or reproduction steps while disclosure remains pending, and we are not naming the project.
This is an authority-and-destination finding: a reachable data-movement path under adversarial influence, not a demonstrated end-to-end exfiltration in a specific production deployment. The reachable consequence depends on which tools an operator gives the agent and what data sits in its runtime. The claim is deliberately narrow: it is about where an authorized capability sits relative to untrusted influence, not that prompt-injection defenses are useless.