Secure the plan, not just the prompt
A short briefing on why agent security needs controls over the whole action sequence, with a practical review you can run today.
01
The signal
CrowdStrike’s 29 October research update describes prompt injection that shapes an agent’s plan, so individually ordinary actions can combine into an unsafe outcome. This is a dated research observation, not evidence of an incident in your organisation. OpenAI’s earlier analysis similarly argues for limiting the consequences of manipulation instead of relying only on identifying malicious text.
02
Our reading: authority belongs at execution
The architectural question is broader than whether a sentence looks suspicious: what may this agent read, where may information go, and which system actually enforces that decision? Microsoft’s agentic-risk guidance places deterministic controls, constrained tool access and accountable oversight alongside model-level measures. These sources support layered controls; they do not establish that any product eliminates prompt injection. Our recommendation is to review the complete action path, including the data source, destination and authority for each operation.
03
A fictional scenario
An internal support agent reads a troubleshooting page. The page suggests uploading configuration to a diagnostics service. Reading configuration and making an HTTP request may each be permitted operations, yet transmitting a secret to that destination should not be. This is a fictional teaching example, not a CT customer incident or a tested detection result. A warning on the page is useful; a destination policy enforced by the executing tool is the more important boundary.
04
Today’s 15-minute architecture review
Choose one agent workflow and draw its external input → proposed action → data read → outbound destination → approval → audit record path. Identify which components enforce destination and data-access rules. In an isolated, authorised test with synthetic data, introduce an external instruction that requests a harmless canary export to an unapproved destination. Check whether the executing layer refuses it, whether the original task can continue safely, and whether a reviewer can explain the result. Do not test against real customer data or production systems without the normal authority.
05
Keep three measurements separate
Record whether the model followed the intended task, whether the executing control allowed or refused the operation correctly, and whether the retained evidence supports that conclusion. A plausible explanation is not an enforcement result. A refusal in one synthetic test is not proof of general resilience. If the boundary is missing, capture its owner and next action rather than turning the gap into an unsupported readiness score.
06
The decision to take forward
Before widening an agent’s permissions, require an answer to: which independently enforced rule prevents untrusted material from changing where sensitive information can be sent? Where the answer depends entirely on the model recognising a suspicious request, narrow the workflow and design an execution control before expansion. This is CT editorial interpretation for architecture discussion, not a vulnerability assessment of your environment.
Primary sources
Publication dates are shown where known. Our interpretation is separate from source claims. No customer incidents or product efficacy results are inferred.