Secure AI Agents Need Dynamic Plans and Policies

Security folks know this feeling. A new capability arrives, looks helpful, then quietly starts taking instructions from places you did not expect. AI agents powered by Large Language Models (LLMs) now read the web, handle email, and call tools. Indirect prompt injection exploits that curiosity. Malicious text in a web page, message, or third party output slips into an agent’s context and steers it to do something unhelpful or unsafe.

What the paper argues

This position paper takes a system view. The authors say we should not expect model fine tuning or a few text filters to save us. Instead, they sketch an architecture with a clear control loop: an orchestrator plans work, a plan and policy approver checks intent, an executor acts, and a policy enforcer constrains effects. Defence in depth matters. Rule based checks do what they can. Learned models help only inside tight boxes. People stay in the loop when judgement and preference become the issue.

First, dynamic replanning and policy updates are necessary. Real environments change. APIs move. Debugging takes iteration. A static plan or a frozen policy grows stale and brittle. The system should treat replanning and policy evolution as routine, and do so with security context rather than as a blind retry.

Second, some security judgements are contextual and need learned models, but only on narrow, structured inputs with constrained outputs. In other words, do not let a model read arbitrary environmental text and then decide on access or actions. Instead, feed it a structured plan change, or a compact description of a proposed tool call, and ask a bounded question. The paper even points to using models to synthesise deterministic validators, which you then run without exposing the model to fresh untrusted text.

Third, language is ambiguous and objectives are messy. There are cases where the system cannot resolve intent automatically. Personalisation and human interaction should be first class design elements, not an afterthought. That makes the inevitable edge cases explicit and accountable.

Why this feels familiar

If you have lived through earlier waves, this rhyme is comforting. We once let documents carry active content that executed wherever it landed. The fix was not a perfect scanner. It was a scaffold of constraints, explicit consent, and smaller, better defined decision points. Over time we learned to limit what untrusted inputs could see, what they could call, and who had to approve the grey areas.

The paper also takes aim at current benchmarks. Many tests use short, static tasks and non adaptive payloads. They rarely push agents through multi step jobs that force replanning or policy revision. This flatters both utility and security. In practice, attackers adapt and environments shift. Evaluations should too.

For practitioners, the implications are concrete. Treat the agent’s control loop as a first class security surface. Keep plans and policies explicit and versioned so you can approve diffs, not blobs of text. Use learned models as adjudicators over structured artefacts with narrow prompts and outputs. Where checks must run at speed, consider synthesising deterministic validators from models and then freezing them. For high ambiguity decisions, design the human touchpoint early and let users express preferences that shape enforcement.

This is not a counsel of despair. It is a call to move security attention from the model’s raw appetite for text to the system’s bones. By deciding what evidence the model can observe and what choices it can make, you shrink the attack surface and gain clearer explanations when things go wrong. Better benchmarks that include long running tasks and adaptive attacks will help the field separate hopeful demos from robust designs. That rhythm is old, and it is usually how we make progress.