How to Protect AI Agents from Indirect Prompt Injection and Data Exfiltration

AI agents are becoming more useful because they can do more than answer questions. They can browse websites, read email, search documents, inspect repositories, call tools, update records, send messages, and trigger workflows. The same capabilities that make an agent productive also create a serious security problem: the agent may consume malicious instructions hidden inside content it was only supposed to read.

That threat is called indirect prompt injection, and when the manipulated agent can access sensitive data or powerful tools, the attack can become agent hijacking, privilege abuse, or data exfiltration. The central security lesson is simple: untrusted content must never be allowed to grant authority. An agent can read information from a source, but the source should not be able to redefine the agent’s goals, expand its permissions, or silently authorize a sensitive action.

This guide explains how indirect prompt injection works, why tool-using agents are different from ordinary chatbots, where data exfiltration paths appear, how to design layered defenses, how to place human approval at the right points, how to protect memory, and how to test agent systems before production. It deliberately focuses on architecture, workflows, risk decisions, and operational practices rather than code, so the principles apply across models, frameworks, cloud providers, and agent platforms.

Table of Contents

• 1. What indirect prompt injection is
• 2. Why AI agents are more exposed than ordinary chatbots
• 3. How indirect prompt injection travels through an agent workflow
• 4. What data exfiltration looks like in agentic systems
• 5. The core security principle: content cannot grant authority
• 6. Build a layered defense architecture
• 7. Control external inputs and retrieved context
• 8. Secure tools, permissions, and authorization
• 9. Design safe human approval for high-impact actions
• 10. Prevent memory and context poisoning
• 11. Control outbound communication and data egress
• 12. Monitor agent behavior and prepare for incidents
• 13. Test and red-team the complete agent workflow
• 14. Real-world scenarios
• 15. Common mistakes and why they fail
• 16. Performance, usability, and security trade-offs
• 17. Production checklist
• 18. Troubleshooting suspicious behavior
• 19. FAQ
• 20. Conclusion

1. What Is Indirect Prompt Injection?

Indirect prompt injection occurs when malicious or misleading instructions are embedded in external content that an AI system later reads. The attacker does not need to type the instruction directly into the user’s chat. Instead, the payload can live inside a web page, email, document, issue description, support ticket, retrieved knowledge-base article, repository file, image, tool response, or other data source.

The agent is supposed to treat that material as data. The attack succeeds when the model interprets some of the content as instructions that override or distort the user’s intended task. In a simple chatbot, the result may be a misleading answer. In an agent, the result can be much more serious because the model may be able to call tools, access private context, or take actions in external systems.

Direct vs. indirect prompt injection

The important distinction is trust. A user instruction may have legitimate authority within the user’s permissions. A web page, email body, PDF, third-party API response, or repository README does not. The security architecture should make that difference explicit rather than hoping the model always infers it correctly.

Indirect prompt injection is closer to social engineering than a simple input-filter problem

Modern attacks may not contain obvious phrases such as “ignore previous instructions.” They can look like normal operational guidance, a fake compliance requirement, a believable workflow step, a request to “verify” data at an external destination, or a claim that the agent has already been authorized. This is why keyword filtering alone is not a durable defense. A persuasive malicious message can be semantically ordinary while still attempting to redirect the agent’s goals or create an unsafe data flow.

2. Why AI Agents Are More Exposed Than Ordinary Chatbots

A chatbot primarily transforms input into output. An agent may transform input into action. That difference changes the security model. When the system can invoke tools, the model’s interpretation of text can affect email, databases, files, cloud resources, browsers, payment systems, tickets, calendars, source repositories, or internal business applications.

The risk grows when three conditions exist at the same time: the agent consumes untrusted content, the agent has access to valuable data or powerful tools, and the agent can transmit or modify something without an independent authorization check. A secure design tries to prevent those three conditions from forming an unrestricted path.

Agents combine multiple trust domains

A single agent session may contain the user’s request, system instructions, internal company data, retrieved public content, third-party tool results, persistent memory, and messages from other agents. These sources do not deserve equal trust. If they are blended into one undifferentiated context, the model may receive a malicious instruction with no deterministic mechanism to enforce which source is allowed to influence which decision.

Autonomy increases the blast radius

Automation is valuable because it removes repetitive confirmations. But every skipped confirmation transfers more responsibility to the agent and to the surrounding policy controls. Read-only research is one risk level; sending an email, changing permissions, deleting files, creating a public post, updating a customer record, or moving money is another. Secure agent design therefore links autonomy to action risk instead of treating autonomy as a single on/off setting.

3. How Indirect Prompt Injection Travels Through an Agent Workflow

A useful way to reason about agent attacks is the source-to-sink model. A source is any place where an attacker can influence content. A sink is any capability that can cause harm if misused. The agent and its context connect the two.

The strongest defenses break the chain at multiple points. They reduce attacker influence at the source, label or transform untrusted context, restrict which tools can be used, independently validate sensitive actions, and constrain what can leave the system.

Common injection sources

• Web pages and search results, including hidden or visually unobtrusive text.
• Emails, attachments, calendar descriptions, and collaboration messages.
• Documents retrieved from internal or external knowledge bases.
• Issue descriptions, pull-request comments, README files, and repository documentation.
• Third-party API responses and tool metadata that the agent assumes are trustworthy.
• RAG content that has been poisoned upstream or indexed without provenance controls.
• Images or multimodal content containing instructions the model can interpret.
• Persistent memory entries created from previous untrusted interactions.
• Messages produced by another agent in a multi-agent workflow.

4. What Data Exfiltration Looks Like in Agentic Systems

Data exfiltration does not require the agent to print a password in the chat. It can happen through any channel the agent is allowed to use. A manipulated agent might include private information in a URL, send a message to an attacker-controlled recipient, upload a file, create a public document, place secrets into a third-party API call, write confidential data into logs, or pass sensitive context to another agent with a weaker trust boundary.

Sensitive data that may be exposed

• Authentication tokens, session artifacts, credentials, and reset codes.
• Customer data, personal information, financial records, health-related records, or HR data.
• Private source code, internal documentation, unreleased product information, or incident details.
• System prompts, proprietary instructions, business logic, or confidential model context.
• Private email, calendar information, files, cloud documents, and internal messages.
• Operational metadata that can help an attacker map infrastructure or privileges.

The dangerous combination: read access plus send access

One of the most important architectural reviews is to identify agents that can both read sensitive information and communicate with an external destination. The destination may be a browser request, webhook, email, messaging tool, external storage service, or generic HTTP capability. When both sides exist in the same trust path, a successful prompt injection can become a confidentiality incident. Reducing either read scope or outbound scope can dramatically lower the impact.

5. The Core Security Principle: Content Cannot Grant Authority

The most useful mental rule for secure agent systems is: information can inform a decision, but information must not authorize itself. A web page can tell the agent that a refund is needed, but the web page cannot grant permission to issue the refund. An email can contain a request to send a file, but the email cannot expand the recipient list or grant access to confidential documents. A retrieved document can describe an administrative procedure, but it cannot transform the agent into an administrator.

Authorization should come from trusted identity, policy, configuration, explicit user consent, and deterministic control systems. The model can recommend an action, but the system should determine whether the action is allowed.

6. Build a Layered Defense Architecture

Prompt injection is not a problem that can be solved by one classifier, one system prompt, or one content filter. Defenses should assume that some malicious content will eventually reach the model. The architecture must therefore contain the consequences of a successful manipulation.

Layer 1: define trust zones

Classify the information and capabilities surrounding the agent. Separate trusted instructions from untrusted data, internal resources from public resources, low-risk tools from sensitive tools, and user-scoped data from organization-wide data. Trust zones make it possible to design explicit transitions rather than allowing context to flow freely.

Layer 2: minimize privileges

Give the agent only the tools, operations, resources, and data required for the current task. A research agent should not inherit write permissions simply because another workflow sometimes needs them. Read-only and write-capable tools should be separate. Access should be scoped to specific resources rather than broad directories, databases, mailboxes, or cloud accounts.

Layer 3: separate planning from execution

The model can decide what it wants to do, but a separate policy or execution component should decide whether the action is allowed. This prevents the model from serving as both the requester and the final authority. For sensitive actions, the execution layer should validate identity, scope, target, parameters, approval state, and policy version before anything happens.

Layer 4: control outbound flows

Egress controls limit where data can go. An agent should not have unrestricted ability to contact arbitrary destinations. Approved domains, approved recipients, approved services, destination reputation, data classification, and payload inspection can all reduce exfiltration risk. For high-risk sessions, outbound network access may be unnecessary and should be disabled.

Layer 5: add human approval where it changes risk

Human-in-the-loop controls are most valuable before irreversible, externally visible, privileged, financial, destructive, or privacy-sensitive actions. Approval should show the user exactly what will happen, what data will be sent, to whom, using which tool, and with which target resource.

Layer 6: observe and test continuously

Agent behavior changes when prompts, tools, models, retrieval sources, memory policies, or providers change. Security evaluation therefore needs to be continuous. Monitoring should reveal abnormal tool use, repeated permission failures, unexpected destinations, large outbound payloads, risky approval patterns, and unusual chains of actions.

7. Control External Inputs and Retrieved Context

All external content should be treated as potentially adversarial. That includes content from sources that are usually benign. A legitimate website can be compromised. A trusted colleague’s account can be taken over. A public repository can accept malicious contributions. An internal knowledge base can contain stale or manipulated content.

Preserve provenance

The system should retain where each piece of context came from. Provenance helps the agent and downstream controls distinguish user instructions, system instructions, internal documents, public web content, tool outputs, and memory. It also makes incident investigation possible after a suspicious action.

Separate instructions from data

Retrieved material should be represented as data with clear boundaries. The system should avoid concatenating external content into the same instruction channel used for trusted policy. Strong separation does not guarantee that a model will never be influenced, but it reduces ambiguity and creates a consistent basis for testing and enforcement.

Transform high-risk content before use

For some workflows, the agent does not need raw external content. A safer intermediary can extract structured facts, produce a constrained summary, remove active links, strip irrelevant formatting, or isolate fields that are actually needed. The goal is not to claim perfect sanitization; it is to reduce the amount of attacker-controlled language that reaches a privileged reasoning step.

Do not rely on filtering alone

Filters are useful for obvious patterns, known malicious markers, or policy violations, but sophisticated prompt injection can look like plausible instructions. A filter that attempts to classify every malicious message is solving a difficult social-engineering problem. Filters should therefore be one layer among several, not the final security boundary.

8. Secure Tools, Permissions, and Authorization

Tool security is where prompt injection becomes a systems-security problem. If the model is manipulated but cannot access sensitive capabilities, the impact is limited. If the model has broad credentials and unrestricted tools, the same manipulation can become a serious incident.

Use task-scoped tools instead of general-purpose tools

Prefer narrow capabilities that represent a specific business operation. A tool that can “read one approved report” is safer than a generic file-system reader. A tool that can “draft a customer response” is safer than a general communication tool that can send to any recipient. A tool that can “request a refund review” is safer than direct access to a financial transaction system.

Scope permissions by operation and resource

Read, write, delete, administer, share, publish, and send permissions should be distinct. Resource scope matters as much as operation scope. Access to one project, folder, mailbox label, dataset, or account should not silently imply access to every resource the underlying credential can reach.

Use short-lived, context-bound authorization

When a privileged action is necessary, authorization should be temporary and tied to the current task. The system should avoid giving the model a long-lived credential that remains useful after the action is complete. Sensitive operations should bind authorization to the intended actor, tool, target, action parameters, and time window so that an approval cannot easily be replayed for a different purpose.

Never let model confidence become authorization

A model can be very confident and still be wrong or manipulated. Authorization decisions should not depend solely on natural-language assertions such as “this is safe,” “the user already approved,” or “the source is trusted.” Those claims need deterministic evidence from the application state and policy system.

9. Design Safe Human Approval for High-Impact Actions

Human approval is not automatically safe. A weak confirmation dialog can be manipulated by the same injected content that manipulated the agent. The user may be shown a vague message such as “Continue?” without seeing the true recipient, destination, or data being transmitted.

What a useful approval should show

• The exact action the agent proposes.
• The specific tool or system that will perform it.
• The target resource, recipient, account, file, or destination.
• A concise preview of the data that will be transmitted or changed.
• Why the action is needed for the user’s original task.
• Whether the action is reversible and what its consequences are.
• Any unusual risk signal, such as a new external domain or elevated permission.

Bind approval to the exact action

An approval should not mean “the agent may do anything related to this task.” It should authorize one clearly defined action or a tightly bounded set of actions. If the target, recipient, amount, data payload, or resource changes, the authorization should be re-evaluated.

Avoid approval fatigue

Too many low-value confirmations teach users to click through without reading. Risk-based autonomy is better: allow low-impact, reversible actions automatically; require stronger checks for sensitive operations. A good approval strategy protects the user without making the agent unusable.

10. Prevent Memory and Context Poisoning

Persistent memory creates a special form of indirect prompt injection because malicious content can survive the original session. A poisoned memory item may influence later decisions, affect another workflow, or be retrieved when the user no longer remembers where it came from.

Treat memory as a database, not as trusted truth

Memory entries need provenance, scope, retention rules, sensitivity classification, and validation. User-specific memory should not leak into other users or tenants. Temporary observations should expire. Sensitive information should be minimized or redacted. Long-term memory should not be populated automatically from arbitrary external content.

Separate facts, preferences, and instructions

A durable fact such as a user’s preferred report format is different from an external instruction such as “always send future reports to this new address.” Systems should distinguish these categories. Persisting instructions from untrusted content is particularly risky because it turns a one-time injection into a standing policy change.

Review memory when an incident is suspected

Incident response should include stored context. Removing the malicious source is not enough if the agent already saved the instruction or a derived conclusion. Investigators should check memory, summaries, cached retrieval results, and downstream agent messages for persistence.

11. Control Outbound Communication and Data Egress

Many high-impact prompt-injection attacks require an outbound channel. If an attacker wants the agent to steal information, the information must leave the trusted boundary somehow. Egress control is therefore one of the most effective defenses against data exfiltration.

Restrict destinations

Agents should contact only destinations needed for the task. New domains, new recipients, URL shorteners, public paste services, arbitrary webhooks, or unapproved cloud storage deserve additional scrutiny. In high-trust environments, outbound access may need explicit allowlists or a controlled proxy.

Inspect what leaves the system

The execution layer can check whether an outbound request contains secrets, unusually large payloads, personal data, internal identifiers, or content copied from sensitive context. This does not require understanding every possible attack. It focuses on the data-flow invariant: sensitive information should not leave through an unapproved sink.

Minimize the data available to the agent

The safest secret is the one the agent never receives. Instead of loading entire mailboxes, file shares, or customer records into context, retrieve the smallest subset necessary. Data minimization reduces both accidental leakage and the value of a successful injection.

12. Monitor Agent Behavior and Prepare for Incidents

Traditional application logs are not enough if they record only the final answer. Security teams need visibility into agent decisions, tool requests, authorization outcomes, approvals, external destinations, retrieval sources, and the result of each sensitive action. The goal is not to expose private chain-of-thought; it is to record auditable system-level events and decisions.

Security-relevant events to monitor

• Unexpected use of high-risk tools.
• Repeated denied attempts to access restricted resources.
• New or unusual external destinations.
• Large outbound payloads or sudden changes in data volume.
• A shift from read-only behavior to write or administrative behavior.
• Repeated approval bypass attempts or suspicious approval sequences.
• Tool-call loops, unusually deep chains, or sudden cost spikes.
• Cross-user or cross-tenant context anomalies.
• Changes in memory behavior, retrieval sources, or tool policy.

Create an agent incident playbook

1. Stop or suspend the affected agent workflow and revoke temporary credentials.
2. Preserve audit records, tool-call metadata, approvals, retrieval provenance, and outbound destinations.
3. Identify the source content that influenced the agent and determine whether it remains reachable.
4. Check for persistence in memory, cached context, indexes, summaries, or multi-agent messages.
5. Review every sensitive action taken after the suspected injection point.
6. Rotate exposed secrets or tokens and reverse changes where possible.
7. Add the attack pattern to regression tests and update the relevant policy controls.

13. Test and Red-Team the Complete Agent Workflow

Agent security testing should cover the full system, not only the underlying model. NIST’s 2026 red-teaming analysis illustrates why: attackers adapt to models and scenarios, and successful attack families can transfer across settings. A production test plan therefore needs realistic sources, real permission boundaries, representative tools, and expected denial behavior.

Abuse cases every agent team should test

Test after every meaningful change

Prompt changes, model upgrades, new tools, new connectors, new retrieval sources, memory changes, policy changes, and provider changes can alter security behavior. Previously successful attacks should become regression tests. Release gates should become stricter when high-risk permissions or approval logic changes.

Measure control behavior, not just attack success

A secure system can remain safe even if the model becomes partially manipulated. Testing should therefore record what happened at each layer: Did the tool policy deny the call? Did the egress control block the destination? Did approval show the correct payload? Did the agent stop after a circuit breaker? This is more informative than a single pass/fail score for the model.

14. Real-World Scenarios

Scenario A: Email assistant

A user asks an agent to summarize recent messages and prepare follow-ups. One inbound email contains a plausible-looking instruction to retrieve private employee information and send it to a “verification” service. A weak system lets the email redefine the workflow. A stronger system treats the email body as untrusted data, prevents it from granting access to HR records, blocks new external recipients without approval, and keeps the email-reading tool separate from the HR-data tool.

Scenario B: Browser research agent

A research agent visits many websites while authenticated to internal services in the same session. A malicious page instructs it to include confidential context in a URL parameter. A safer architecture uses limited or logged-out browsing when authentication is not needed, restricts outbound destinations, prevents sensitive context from being embedded in arbitrary requests, and asks for explicit approval when a navigation could transmit protected data.

Scenario C: Coding agent

A coding agent reads an issue description, repository documentation, pull-request comments, and dependency metadata. One source contains instructions to weaken a security check or disclose repository information. The agent should not treat issue text as policy. Repository modifications that affect authentication, authorization, tests, secrets, deployment, or external communication should receive additional review, and the agent should not inherit broad credentials simply because it can edit code.

Scenario D: Customer-support agent

A support message claims that a special exception has already been approved and instructs the agent to issue a large refund. The message is evidence for the case, not authorization. A separate policy service should enforce refund limits, eligibility, user identity, and escalation requirements. The agent may recommend the refund, but cannot expand its own financial authority.

Scenario E: Multi-agent workflow

A research agent passes findings to a planning agent, which passes tasks to an execution agent. If the research agent is hijacked, malicious instructions can propagate downstream. Each agent should verify the trust level and permitted semantics of incoming messages. The execution agent should not assume that a request is authorized simply because another agent generated it.

15. Common Mistakes and Why They Fail

16. Performance, Usability, and Security Trade-offs

Stronger security controls can add latency, reduce agent autonomy, or require more user interaction. The goal is not to maximize friction. It is to place friction where the expected impact is high and remove it where the action is low-risk and reversible.

Use risk tiers

Optimize architecture before adding more model calls

A common response to prompt injection is to add another model as a judge or filter. That can help, but it also adds cost, latency, and another probabilistic component. Deterministic controls such as scoped permissions, destination restrictions, typed actions, quotas, and explicit approval often provide more predictable security value. Use model-based detection where it complements, rather than replaces, those controls.

17. Production Checklist for Indirect Prompt Injection Defense

• Inventory every external content source the agent can read.
• Inventory every tool, credential, data store, connector, and outbound communication channel the agent can access.
• Classify sources by trust and data by sensitivity.
• Identify source-to-sink paths where untrusted content can influence sensitive actions.
• Separate trusted instructions from retrieved data and preserve provenance.
• Grant the minimum tools and permissions required for the current task.
• Separate read, write, delete, send, publish, and administrative capabilities.
• Keep authorization decisions outside the model.
• Separate planning from execution for sensitive operations.
• Restrict outbound destinations and inspect sensitive data leaving the system.
• Use human approval for high-impact or irreversible actions.
• Bind approval to the exact tool, target, parameters, actor, and time window.
• Isolate memory by user, tenant, and session where appropriate.
• Validate what is allowed to become persistent memory and expire temporary context.
• Log tool calls, authorization results, approval records, destinations, and outcomes.
• Set limits for retries, recursion, tool-chain depth, tokens, and cost.
• Build adversarial tests for prompt injection, exfiltration, tool misuse, and memory poisoning.
• Re-run security tests after changes to prompts, models, tools, retrieval, memory, providers, or permissions.
• Maintain a documented incident response process that includes memory and cached context.
• Review the agent’s real permissions periodically; remove capabilities that are no longer required.

18. Troubleshooting Suspicious Agent Behavior

The agent suddenly wants to use an unrelated tool

Treat this as a possible goal-hijacking signal. Check the most recent retrieved sources and tool results, verify whether the requested capability is necessary for the original task, and deny the call unless the policy explicitly allows it. Review whether the tool is too broadly available to the session.

The agent wants to send data to a new domain or recipient

Do not approve based only on the agent’s explanation. Verify the destination independently, inspect the data that would leave the system, and determine whether the user’s original request actually requires external transmission. New destinations should trigger stronger controls than previously approved internal destinations.

The agent keeps retrying a denied action

Repeated attempts can indicate manipulation, poor planning, or a policy mismatch. Apply retry and circuit-breaker limits, capture the relevant context, and review the source that caused the action. A secure agent should not be able to brute-force policy by repeatedly reframing the same prohibited operation.

The same suspicious behavior returns in later sessions

Investigate persistent memory, caches, summaries, retrieval indexes, saved browser state, and messages passed between agents. The original injection may have become stored context. Purge or quarantine contaminated state and add regression tests before restoring the workflow.

A model upgrade changes approval or tool behavior

Treat model changes as security-relevant releases. Re-run representative attack suites and compare denial, approval, tool selection, and egress behavior. Do not assume a newer or more capable model preserves previous security properties.

19. Frequently Asked Questions

What is indirect prompt injection in an AI agent?

Indirect prompt injection is an attack in which malicious instructions are hidden in external content—such as a web page, email, document, repository, or tool response—that the agent later reads. The goal is to manipulate the agent into taking actions the user did not request.

How is indirect prompt injection different from a jailbreak?

A jailbreak is usually delivered directly through the interaction with the model. Indirect prompt injection is delivered through external data the model consumes. The distinction matters because an attacker may never interact directly with the agent or user.

Why is prompt injection more dangerous for AI agents than chatbots?

Agents often have tools, credentials, memory, and permission to act. A manipulated chatbot may produce a bad answer; a manipulated agent may send data, change records, access private resources, or trigger external systems.

Can prompt injection be completely prevented?

No single control can guarantee perfect prevention. Security should assume that some malicious content may reach or influence the model. The practical objective is layered containment: limit privileges, restrict data flows, independently authorize actions, require approval where needed, and monitor behavior.

What is the most important defense against agent data exfiltration?

Eliminate unrestricted source-to-sink paths. An agent that can read sensitive data should not also have uncontrolled ability to transmit information externally. Data minimization, destination restrictions, egress inspection, and action-specific approval are especially important.

Should AI agents have administrator permissions?

As a default, no. Agents should receive the minimum authority required for a specific task, ideally through narrow, short-lived, resource-scoped permissions. Administrative actions should use stronger controls and explicit authorization.

Does human approval solve prompt injection?

Human approval reduces risk only when the approval is meaningful. The user must see the exact action, target, recipient, and data involved. Vague or frequent confirmations can create approval fatigue and may fail to reveal the malicious effect.

How should agent memory be secured?

Treat memory as persistent application data. Validate what is stored, keep provenance, isolate users and tenants, minimize sensitive information, set retention limits, and prevent untrusted content from becoming durable instructions.

How often should an AI agent be security tested?

Test before production and after changes that affect prompts, models, tools, permissions, retrieval sources, memory, connectors, providers, or approval logic. Previously discovered failures should remain in a regression suite.

What should be logged for an AI agent?

Log security-relevant system events such as tool requests, authorization decisions, approvals, target resources, external destinations, outcomes, policy versions, and anomalies. Avoid storing secrets or unnecessary sensitive content in logs.

Is a prompt-injection detector enough?

No. Detection can help, but sophisticated attacks may resemble ordinary language or social engineering. The most reliable architecture assumes detection will sometimes fail and uses deterministic permissions, isolation, egress controls, and independent authorization to contain the impact.

How can small teams improve agent security without a large security platform?

Start with an inventory of data sources and tools, reduce permissions, separate read and write capabilities, restrict external destinations, require clear approval for high-impact actions, keep audit logs, and build a small set of adversarial regression tests. These architecture decisions provide strong value even without specialized products.

20. Conclusion

Indirect prompt injection is difficult because an AI agent is designed to understand and act on language, while attackers can place language inside the data the agent consumes. Trying to solve that problem only by teaching the model to “ignore malicious instructions” is not enough. A secure system must assume that untrusted content can sometimes influence the model and ensure that influence does not automatically become authority.

The strongest architecture uses layers: clear trust boundaries, minimal permissions, separate planning and execution, deterministic authorization, destination restrictions, data minimization, risk-based human approval, protected memory, structured monitoring, and adversarial testing. These controls change the security objective from “the model must never be fooled” to a more realistic goal: “even if the model is fooled, the system prevents or limits harmful consequences.”

For teams deploying tool-using agents, that shift is the difference between treating prompt injection as a text-filtering problem and treating it as what it has become: a full application-security and authorization problem. The earlier those boundaries are designed into the agent architecture, the easier it is to scale autonomy without scaling the blast radius at the same time.