The key idea
Treat web pages, briefs and incoming documents as evidence, not instructions. Keep the research task limited to approved, non-sensitive inputs and drafting, verify its actual data access and outbound permissions with the system owner, and approve any later action separately. Clear prompts help, but protection also depends on controls outside the model.

A competitor-research assistant has a straightforward job: read the supplied material and prepare a useful comparison. But a source can contain instructions as well as information. A sentence inside it may try to change the assignment without your team’s permission.
This is prompt injection. When the instruction arrives through something the assistant reads, such as a page, document, email or tool result, it is called indirect prompt injection. Your team does not have to paste it deliberately for it to enter the workflow.
When a competitor page tries to rewrite the assignment
Consider a hypothetical comparison of three public competitor pages for an internal marketing brief. One page includes a direction to favour its own vendor or leave out a weakness. That direction has no authority over the assignment. The assistant should still produce a sourced comparison, treating the attempted redirection as untrusted source content.
This differs from an invented claim: the material itself contains an instruction trying to redirect the assistant. The result might still look plausible. A list of suspicious phrases will not reliably identify every attempt, and a polished page has no more authority to issue instructions.
Start with what the assistant can actually reach
Before adjusting the prompt, sit down with the person responsible for the system and map the whole workflow. Which inputs arrive? Which private files can it read? Which tools can it use? Where can it make network requests, and who can receive its output? Include connections available to the assistant even if this particular assignment does not need them.
Those permissions determine the possible consequences. Biasing our comparison is already a problem. If the assistant can also read private pricing notes and send messages, the scope for harm changes. Access useful for one job should not automatically accompany every research task.
Read-only access deserves particular attention. It can prevent certain changes through authorised tools, but it does not automatically prevent disclosure. Information may leave through a message or through data included in a request to an external address. Check both what can be read and how information can leave.
Make the first pilot a draft-only assignment
Our recommendation at MindVerve is to begin with approved, non-sensitive competitor sources and an internal draft as the only output. Keep secrets out of the research stage. Ask the system owner to disable unnecessary send, publish and write tools and restrict allowed destinations through the platform. These are configuration decisions, not powers that a marketing prompt can grant or remove.
Keep a record of where each source came from so a reviewer can check important claims against the original. Tell the assistant to flag attempted redirection as source content without obeying it. That makes the intended behaviour clear, while the access controls limit what an unexpected response could do.
If nobody can verify permissions or outbound restrictions, narrow the pilot further: supply approved documents manually and allow no external actions. Bring in the responsible IT or security owner before introducing sensitive material.
Why a stronger prompt is only part of the answer
Separating your instructions from the source text helps express the assignment. It does not create a security boundary. Retrieval-augmented generation, or RAG, means finding relevant passages before generating an answer; those passages can still contain attempted instructions. A second AI reviewer can also make mistakes, so its approval is not a guarantee.
Combine clear instructions, limited access, checks on proposed actions outside the language model, and ongoing testing. OpenAI and Anthropic describe layered defences that remain imperfect. These measures reduce risk; they do not establish immunity.
Rehearse the boundary with fictional material
Before expanding the pilot, we suggest an isolated exercise with fictional documents and data, with no real messages sent. This is a proposed test, not one we have carried out. Compare a normal source with a document requesting an irrelevant slogan in the summary and another requesting transmission to a fictional, unapproved recipient.
Expect a useful, faithful summary of the normal material, flagged attempts to redirect the task, and no unauthorised outbound action. Check the action logs: the assistant saying it sent nothing is not sufficient evidence. Also record false alarms, whether useful work was completed, and the effort required from reviewers.
Save the input, prompt, model and workflow versions, expected and observed results, and actual action log. Retest after meaningful changes. One successful run proves little about other inputs. Unexpected action or disclosure should halt expansion: stop the affected workflow, preserve only necessary evidence without circulating sensitive data, involve its IT or security owner, and retest before resuming.
Approve the next action, not a vague continuation
Sending the draft, publishing it and changing campaign spend are separate actions. Each needs its own permission and a check of the exact content or change, destination and proposed action. A general approval to continue does not establish what the person approved.
Choose one workflow that remains valuable with these limits. Staff training helps reviewers understand the sources and proposed actions; engineering controls constrain access and execution. Both matter because a source can provide evidence, but it cannot grant permission.
Official sources checked on 22 September 2026, UTC.
Official sources
OWASP · LLM01:2025 Prompt InjectionOWASP · LLM Prompt Injection PreventionOpenAI · Understanding prompt injections (2025-11-07)Anthropic · Prompt injection defenses (2025-11-24)MindVerve
Marketing automation
MindVerve’s AI Workflow Launch configures one scoped marketing workflow, tests representative cases and exceptions, and provides reusable instructions, training, documentation and handover. Mapping the research inputs and reviewing how exceptions are handled is a practical starting point. The service is not a cybersecurity audit, certification or guarantee of protection. Licences, API usage and additional integrations are excluded; support and maintenance are agreed separately. If the task is still unclear, AI Opportunity Sprint can help define the priorities and scope first.
Discuss your research workflowRead the guide · AI Workflow Launch