An agent reads a supplier PDF to compare delivery conditions. Inside the document is a sentence telling the assistant to ignore the purchasing team's request and send internal information elsewhere. The sentence is part of the document being analysed. It is not an instruction from the person who authorised the work.
This is the boundary prompt injection tries to cross: turning outside content into authority over the agent. The business impact becomes more serious when the agent can send messages, modify records or call powerful tools. A useful defence therefore limits both what outside content can influence and what the application will allow the agent to do.
Map the route from a document to an action
In an illustrative procurement assistant, outside material may arrive through a PDF, a web page, an email or a tool response containing extracted text. It can pass through a summary, retrieval index or another agent before reaching the component that prepares a business action. A trusted connector does not make every document it returns trustworthy.
List these paths and the actions available at each point. Reading a delivery term requires different authority from changing a supplier account or sending an internal comparison. If one agent can do all three, a failure in interpretation has a much larger reach.
OWASP describes direct and indirect prompt injection, including risks from content in different modalities, and recommends layered mitigation such as least privilege, separation of external content and human approval for consequential actions. It does not offer a universal foolproof prevention method. OWASP prompt-injection guidance
Treat the outside text as evidence for the requested task. The application should retain its origin, document identity and access scope as it moves through the workflow. A summary of a suspicious instruction remains untrusted material; summarisation does not turn it into policy.
Keep business authority outside retrieved content
The active user request, application rules and permissions should come from controlled channels. Do not build a privileged instruction by concatenating a downloaded page into it. State clearly what the agent may extract, and pass external material using the message structure recommended for the provider and API in use.
OpenAI's agent-safety guidance warns against placing untrusted variables in developer messages and describes constraining data passed between steps. This is useful design guidance even when the application uses its own workflow rather than the product shown in the guide. OpenAI guidance for agent safety
Anthropic likewise documents explicit treatment of third-party material as untrusted content, with provider-specific guidance for tool-result placement and structured encoding. Follow the actual interface contract rather than assuming every provider handles message roles identically. Anthropic prompt-injection mitigations
For the procurement example, extract bounded fields such as product code, stated delivery window and quoted conditions, with source references. Validate their type and business meaning before later steps use them. A syntactically valid JSON field can still contain a wrong account, fabricated value or hostile instruction, so structure alone is not a complete defence.
Give tools less authority than the conversation can request
A tool that reads approved supplier documents should not also send arbitrary email or modify payment details. Separate capabilities and enforce access on the server for the authenticated user and business scope. The model's proposed customer identifier is an input to validate, not an authorisation decision.
Keep credentials in the application or execution environment, outside the model's ordinary text context. Use narrowly scoped operations where practical: prepare a comparison draft, request an approved record or propose a change for review. Avoid exposing a general-purpose command executor when a limited operation covers the business task.
Apply destination checks to outbound actions. The recipient and attachment set should come from verified business records and the current authorised request. An address discovered in a supplier PDF is not enough to justify sending an internal file there.
Also consider downstream interpretation. Text extracted from a document may later appear in HTML, a spreadsheet or a database query. Use the appropriate escaping, parameterisation and validation for that destination. Prompt-injection controls do not replace conventional application security at these boundaries.

Make approval specific enough to be useful
A confirmation that says “Allow the agent to continue?” gives the reviewer little basis for a decision. Show the action, exact recipient, selected records, outgoing content and the reason it is necessary. Highlight details that originated in external material and still need verification.
Tie approval to the prepared payload and its version. If the agent changes the recipient or attachment after approval, the old approval must no longer cover the action. Recheck permissions at execution time as well, because a user's role or access may have changed while the workflow was waiting.
Keep the user experience proportional to the task. Routine read-only extraction within an approved scope may proceed without repeated prompts. An action that shares internal information or changes an important record needs a different boundary. Requiring a click for every harmless step can train reviewers to accept without reading.
When the application blocks an action, explain what was withheld and how a person can resolve it. The system should preserve the legitimate comparison work while isolating the suspect part. A blanket failure message makes staff more likely to bypass the product entirely.
Test the boundary, including indirect paths
Use an isolated test environment and harmless test data. Place instruction-like content in permitted sample files, retrieved pages and tool results, then check whether the agent stays within the authorised task. Include cases where the text claims to be a policy update or asks another agent to pass along a new instruction.
Inspect actual tool requests and downstream records. It is not enough for the assistant to say it ignored the injected content if it still changes a recipient, includes an unrelated attachment or writes an unverified value. Check that the server rejects prohibited operations independently of the model's response.
Track false positives too. A document may legitimately discuss instructions, policies or security incidents. The product should be able to summarise that content as subject matter without treating it as an operational command or unnecessarily refusing the entire task.
Preserve useful incident evidence without spreading sensitive inputs into unrestricted logs. Define who reviews a blocked attempt, when a connector or workflow is paused and how corrected cases enter the regression set. Retest after changes to models, tools, extraction or memory, since each can create a new path for outside content.
For the wider access model, use agent permissions and approvals. For deciding whether safeguards work in the full product, connect these cases to business-outcome evals.
Talvyn Labs can develop an AI product with explicit data boundaries, limited tools, inspectable approvals and tests based on the documents your team actually handles. Bring the intended workflow and actions the agent must perform. We can define the control points and build the system so useful automation does not depend on trusting every sentence it reads.
Connect your agent to real work with enforceable boundaries
Let Talvyn Labs design limited tools, data paths and inspectable approvals, then test the workflow against untrusted documents before release.
Build your controlled business agent