Protect an AI agent from prompt injection by controlling how it moves from reading information to taking action. An agent can browse, plan, call tools, remember results, and continue across many steps. I would assume hostile content may influence one of those steps and design the workflow so influence does not become unrestricted authority.
This guide focuses on the agent loop: task definition, planning, execution, memory, delegation, and stopping conditions. A useful agent does not need unlimited independence. It needs enough bounded authority to complete a defined job and a reliable way to pause when the next step exceeds that authority.
Define the job and the forbidden outcomes
Give the agent a concrete objective and a limited set of resources. “Research these three suppliers and prepare a comparison” is easier to constrain than “handle procurement.” The first task can finish with a document; the second may imply account access, negotiation, purchases, and disclosure of internal requirements.
I would write down what success looks like and what must not happen. For a research agent, prohibited outcomes might include sending messages, uploading private files, or installing software. These limits should appear in tool configuration and service permissions, not only in the conversation.
Identify the stopping point before starting. When the agent has prepared the comparison, it should not decide that contacting suppliers is a helpful continuation unless that action has been authorized. A clear finish line reduces the opportunity for an injected instruction to expand the job under the appearance of initiative.
Map every place the agent receives outside content
An agent's input surface extends beyond the latest user message. Browser pages, search results, PDF text, images processed through OCR, emails, calendar descriptions, tool responses, and another agent's summary can all influence its next step. Persistent memory can carry that influence into a later session.
I would record the origin and trust level of each input. Material from a supplier can describe its offer, but it cannot authorize disclosure of another supplier's confidential quote. A tool response can report a status without gaining permission to change the agent's operating rules.
Do not assume a familiar domain makes every item trustworthy. User comments, shared files, imported records, and compromised content can appear inside otherwise legitimate systems. The relevant question is which party controls the text and what authority that party should have over the current workflow.
| Agent stage | Useful boundary | Concrete question |
|---|---|---|
| Research | Limited sources and read access | What outside material can influence it? |
| Planning | Proposal without extra authority | Does this step belong to the task? |
| Execution | Independent policy and exact approval | May this actor perform this action? |
| Memory | Reviewed persistence and isolation | Can this statement affect later sessions? |
Separate research from consequential execution
A research stage can gather evidence and propose next steps without having the ability to execute them. A later execution stage can receive a validated plan with only the tools needed for the approved operation. This separation reduces the authority available while the agent is reading arbitrary material.
The handoff needs care. A summary produced from hostile content is still model-generated material, so the executor must not treat it as a trusted policy update. Validate targets, arguments, and authorization independently. Moving text into a second model call does not automatically remove the original attack.
I would use the separation to simplify decisions: the research component explains what it found; a controlled component decides whether a proposed action is allowed. For example, a travel research agent can compare options while a separate booking step requires review of the exact itinerary and cost.
Give each tool a small permission boundary
Tools determine what an agent can actually affect. Prefer read-only access for analysis, a draft-writing tool for content preparation, and a narrowly scoped update operation for a specific service. Avoid adding a general shell or unrestricted network client merely because it might be useful later.
I would scope access by user, resource, operation, and duration. A task involving one project should not inherit every repository or shared drive available to the account. Temporary credentials should expire, and the underlying service should enforce the same limits even if the model requests something broader.
Consider combined capabilities too. A reader for sensitive files plus an unrestricted uploader can create an exfiltration path even when neither tool appears destructive alone. Review the complete tool set and its possible information flows rather than approving each connector in isolation.
The OWASP agent security guidance provides a reference for reviewing tool authority, memory, approvals, and agent-specific failure modes.
Require review that is specific and fresh
A review screen should show the exact action that is about to happen. For a message, that includes recipients and attachments; for a file operation, the paths and changes; for an account action, the target and affected setting. The reviewer should not need to reconstruct the decision from a long conversation.
I would require a new decision when meaningful details change. An earlier approval of a plan is not approval of a different destination discovered later. The executor should verify approval for the current actor and current operation, with appropriate expiry and protection against repeated use.
Avoid letting the agent decide that its own action is low risk and therefore exempt from review. Classification can help route requests, but the policy defining mandatory approval belongs outside model-controlled text. If the system cannot establish that the required approval is valid, the operation should stop.
Protect memory and reusable instructions
Memory can make an agent more helpful, but it can also preserve a malicious instruction. Treat the ability to write durable preferences or operating rules as a capability with its own permissions. A web page should not be able to create a permanent rule that future private documents must be uploaded to a new service.
I would distinguish temporary task observations from user-approved reusable preferences. Store provenance, limit retention, and isolate memory between users and tenants. Give people a practical way to inspect and delete stored material. If memory is summarized or transformed, preserve enough origin information to understand where a suspicious rule came from.
A remembered statement should never outrank current access policy. “The user prefers automatic sending” does not override a service requirement to review external messages. Persistent context can inform a workflow, but it cannot create new authority by repeating an unverified claim over time.
Bound loops, delegation, and recovery behavior
An agent can make repeated mistakes faster than a person if it keeps retrying a failed strategy. Set limits on steps, elapsed time, tool calls, and spending. Define which failures require stopping rather than searching for another route. An authorization denial should not become a puzzle the agent tries to bypass.
Delegation adds another boundary. A specialist agent's answer is a result to evaluate, not automatic permission for the receiving agent. Delegate only the required context and capabilities, and do not let a subordinate expand the parent's authority through a persuasive summary.
I would also separate recovery from escalation. A temporary network retry may be acceptable within a limit. Switching to a broader credential, disabling a safety check, or sending data to a new endpoint is a different decision. Require explicit policy support for those changes rather than treating them as routine persistence.
Test realistic indirect attacks safely
Build harmless scenarios around actual tasks. A supplier page can ask for an unapproved dummy upload; a tool response can request a forbidden account change; a saved note can try to alter later behavior. Use test accounts, synthetic documents, and destinations controlled for the exercise.
I would inspect the entire trace: sources read, plan changes, tool proposals, enforcement decisions, approvals, and downstream effects. An agent may claim to ignore an instruction while still allowing it to influence a later step. Conversely, a denied tool proposal shows that an external boundary can contain a model error.
Test long workflows as well as single turns. Context compression, memory updates, and handoffs can drop provenance or turn a tentative observation into an apparent instruction. Include ordinary tasks in the same evaluation so the protection remains practical enough for people to use without bypassing it.
Make stopping and cleanup part of the design
Operators need a way to halt the agent, cancel queued operations, revoke access, and inspect what already happened. A stop button that only hides the conversation is not enough if background jobs continue using a credential. Confirm how interruption reaches each component that can execute an action.
I would record pending and completed operations with enough detail to recover where possible. For reversible changes, keep appropriate history or backups. For external messages and disclosures, recognize that deletion may not undo delivery, which is why review must happen before the effect.
After a suspicious run, inspect persistent memory, connector permissions, scheduled work, and saved artifacts before restarting. The practical goal is a controlled agent lifecycle: define the task, constrain authority, check each consequence, and end the session with a clear account of what changed.
Common questions
Is an agent with two models automatically safer?
No. Separation can help architecture, but one model’s summary can still carry hostile influence. Execution needs its own permission and approval checks.
Should every action need human approval?
Scale controls to consequences. Routine bounded reads may run automatically, while sensitive external effects need stronger review. Keep those rules outside the model’s discretion.
Can a browser agent leak data without sending email?
Yes. Navigations, uploads, URLs, and other network requests can disclose information. Review outbound paths and enforce destination restrictions where appropriate.
Does a new conversation clear the risk?
It may clear some context, but not compromised tools, broad credentials, queued work, or persistent memory. Inspect and repair the affected components before restarting.