Because the attack can couple prompt manipulation with an outbound API or tool path. Once the assistant is persuaded to summarise or forward sensitive context, the attacker is no longer relying on model output alone. The risk is multiplied when the assistant has delegated access to files, messages, or external services.
Why attack chains are more dangerous than plain prompt injection
Prompt injection becomes materially more dangerous when it is only the first step in a chain. The prompt steers the assistant, but the exfiltration happens through the assistant’s own tool or API privileges, which can reach files, inboxes, tickets, chat history, or external services that the attacker could not access directly.
That changes the problem from “bad text in, bad text out” to delegated action with real blast radius. Once the assistant can read context and then send, summarise, or transform it, the attacker can turn a single manipulation into a data-moving workflow.
Where the exfiltration path actually opens
The key distinction is that the assistant is no longer just a model generating an answer. It becomes an execution layer that can combine context retrieval, tool calls, and outbound communication, which creates a second trust boundary to abuse.
In practice, exfiltration often rides on capabilities that seem harmless in isolation: summarise a thread, forward a note, create a ticket, draft a reply, fetch attachments, or post to an integration. Each step widens the amount of sensitive material available and increases the chance that the attacker can move data out without obvious signs of model compromise.
That is why attack chains deserve more attention than standalone prompt injection. The risk is not just that the model is tricked, but that the trick is translated into action by a tool path that can touch systems and data the attacker should never see.
Why delegated access multiplies the blast radius
Delegated access is the force multiplier. If the assistant operates with the user’s session, service credentials, or integration tokens, then the attacker inherits those privileges indirectly and can exfiltrate data through legitimate channels that may look like normal automation.
This is especially serious when the assistant spans multiple repositories of trust, such as internal documents, messaging platforms, customer records, or developer tools. A single successful prompt can bridge those sources, combine partial context, and emit a package of sensitive information that is much more useful than one isolated prompt response.
The more the assistant is allowed to act on the user’s behalf, the less useful a narrow “prompt-only” security model becomes. The relevant question is not whether the model can be fooled, but whether fooled output can be turned into outbound movement with authority attached to it.
Risk and Threat Considerations
Attack chains raise exfiltration risk because they convert indirect influence into authenticated data movement. The attacker does not need full system compromise if the assistant can be induced to retrieve, summarise, and transmit sensitive context through approved tools or connected services.
Failure mechanism: A malicious prompt exploits the assistant’s willingness to follow instructions, then uses delegated tool access, session context, or integration privileges to move sensitive data out through a legitimate outbound path.
Impact: Sensitive content can leave the environment with less friction than a traditional breach, and monitoring may misread the activity as ordinary assistant use unless tool calls, destinations, and content boundaries are tightly constrained.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Attack chains exploit delegated authority to move sensitive data through agent tools. |
| ASI02 — Tool Misuse | The exfiltration path depends on abusing tools and integrations after prompt manipulation. | |
| ASI09 — Human-Agent Trust Exploitation | The attacker abuses user trust in the assistant to trigger harmful data movement. | |
| Recommendation — Constrain agent privileges and separate read access from outbound action authority. Restrict tool scope and validate every high-impact tool invocation. Require confirmation for sensitive transfers that originate from assistant output. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege limits how much data and which tools an assistant can reach. |
| IA-9 — Identification and Authentication (Non-Organizational Users) | Tool and service-to-service access often hinges on non-human authentication material. | |
| AU-2 — Event Logging | Tool-driven exfiltration needs logs that show which data moved and where. | |
| Recommendation — Reduce assistant permissions to the minimum needed for each workflow. Authenticate each non-human access path separately and rotate shared credentials. Log tool calls, destinations, and sensitive-data movement for review. | ||
| OWASP ASVS | V8 — Authorization | Assistant-driven data movement needs explicit authorization checks before release. |
| V16 — Security Logging and Error Handling | Detecting exfiltration requires auditability around assistant actions and failures. | |
| Recommendation — Enforce authorization checks before the assistant can disclose protected data. Instrument assistant actions so suspicious outbound transfers are reviewable. | ||
Practitioner Guidance
What to prioritise: Treat outbound action pathways as the control point, not just the prompt surface. The highest-risk designs are those where the assistant can both see sensitive context and initiate a send, share, export, or post action from the same trust context.
What to verify: Check whether the assistant can access more data than it needs for the task, whether tool permissions are scoped per action, and whether outbound destinations are explicitly allowlisted. If the assistant can reach files, mail, chat, CRM, or ticketing systems, assume exfiltration is a credible failure mode.
What good looks like: The assistant can assist without freely forwarding data, and every privileged outbound action is bounded, logged, and separable from prompt content. Where the workflow must span tools, the design should make data movement observable and reviewable rather than implicit.
Practitioner takeaway: The real security boundary is the combination of instruction plus authority. Prompt injection is annoying; prompt injection plus delegated outbound access is where exfiltration risk becomes operationally serious.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 13, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org