Securing Agents That Act for You

Building an agent capable of browsing the web, managing personal context, and using tools creates a new class of risk. You are no longer just building a chatbot that answers questions. You are building a system that can send messages, change records, and commit money on a user's behalf.

Your decision is how to maintain the boundary between the information an agent reads and the authority it is granted to act. If you treat all input as a command, you invite manipulation. If you restrict the agent too much, you lose the utility of the system.

Distinguishing Input from Instruction#

An agent must read emails, documents, and websites to complete tasks. This creates a critical ambiguity: the same material can contain useful facts and malicious instructions.

Indirect prompt injection exploits this. An email may contain a legitimate meeting location but also include hidden instructions to forward your private documents. Research by Greshake and colleagues demonstrated this in LLM-integrated applications. Benchmarks like InjecAgent and AgentDojo provide settings for studying how agents handle this adversarial content.

Defending against this requires separating the data the agent processes from the authority it exercises. An agent reading a webpage is not inherently authorized to change your budget. The risk becomes consequential only when the system grants external information the power to override your explicit constraints.

Preventing Commercial Manipulation#

Commercial content presents a specific vector for manipulation. A merchant may use misleading reviews, fabricated specifications, or hidden sponsorship to influence an agent’s recommendation. In more aggressive cases, a website may inject instructions directed at the agent to ignore your criteria.

Research on conversational search has confirmed that product-ranking manipulation is possible through injected content. This creates a two-fold problem. First, the agent may provide a corrupted recommendation. Second, if the agent has purchase authority, it may execute a transaction based on false evidence or unauthorized terms.

A robust system must preserve sponsorship disclosures and distinguish independent evidence from marketing claims. Truthful advertising is acceptable; treating every commercial source as an attack is not. The system must verify final transaction terms against your constraints, regardless of what the agent’s research phase suggested.

Managing Memory Boundaries#

Personalization requires memory, but memory creates a persistent security boundary. If an agent records an unverified claim as a user preference, that poisoned data can influence future tasks indefinitely.

Research such as AgentPoison and MINJA highlights how interaction records can be poisoned to affect future agent behavior. The challenge is design: does your memory store preserve the source, the date, and the user’s confirmation status? If these attributes are lost during summarization, the agent treats the poisoned record as a trusted preference. Deleting an original message is insufficient if a secondary summary retains the influence.

Scoping Permissions and Delegation#

Permissions should be granular and time-bound. Access to a calendar is not permission to invite attendees. Access to compare products is not permission to buy them.

Time creates further risk. A user might authorize a task and later cancel it, but a background agent might continue based on stale assumptions. You must verify that permissions remain valid at the moment of execution. Knowing which agent sent a request is not enough; you must verify that the authority exists for the specific action requested.

Building Effective Defenses#

Control flows must be distinct from data flows. Approaches like CaMeL separate these concerns, while Progent checks tool calls against symbolic privilege policies.

For a personal agent, several controls must work in concert:

• Isolate Authority: Keep external content distinct from instructions that carry user authority.
• Verify Provenance: Preserve source information and usage restrictions when storing memory.
• Validate at Execution: Check tool arguments, costs, and current permissions at the final action boundary.
• Bind Approvals: Ensure that user approvals are tied to the specific action reviewed, not a general task description.

A sandbox protects the host, but it does not prevent an authenticated account from performing a harmful action. Each control protects a different boundary; the security of the system depends on the entire workflow.

Measuring Safe Completion#

Evaluations must distinguish between legitimate task completion and policy violations. An agent that refuses every request is safe but useless. An agent that completes a task but performs an extra, unauthorized operation has failed.

For persistent agents, tests must extend across sessions. Does malicious influence survive a restart? Does cancellation stop delegated work? Useful tests hold the user’s requirements fixed while varying the material the agent encounters. This reveals whether the system is responding to evidence or being redirected by an external actor.

The Rule for Delegation#

Before handing a task to an agent, define the difference between research and execution. Research requires read access to external information; execution requires a gated, verified step that checks the final recipient, destination, cost, and terms. Never let the agent’s ability to read a website become the authority to commit your resources.