Your support AI employee reads a return request and the customer's attached note. The note claims that a manager approved an exception and asks the agent to skip the normal checks. If the agent accepts that claim as an instruction, a customer has changed how your store handles the return.
Prompt injection happens when input tries to redirect an AI system beyond its authorized task. For ecommerce agents, the practical rule is to keep customer content and retrieved documents in the role of evidence. Your application must decide what the agent may do, using store-owned rules and verified approvals.
How an instruction arrives inside ordinary content
An agent reads much more than the task you gave it. A support job may include an email thread, an attachment, and an order note. A supplier workflow may pull text from a PDF. Each source can contain language that tells the model to change its behavior.
OWASP distinguishes direct prompt injection from indirect injection. In an indirect attack, the instruction reaches the model through external material such as a website or file. A returns attachment can therefore carry an attempted instruction even when your employee's original task was legitimate.
A trusted integration does not make every field it returns trustworthy. Your help desk may authenticate the API response, while the customer still controls the message body. Keep those two facts separate. The transport tells you where the record came from; it does not give the author authority over your policies.
Keep customer claims separate from store authority
Consider a hypothetical skincare store. A customer reports a leaking bottle and attaches a note claiming a supervisor approved a replacement without a photo. The note also asks support to send the customer's full order history to an unfamiliar email address.
Your AI employee needs the damage report to understand the case. It can extract the affected item and look for the required evidence. It should treat the claimed supervisor approval as an unverified claim. The support application must find the actual approval in a store-controlled record before granting an exception.
The proposed email destination needs its own check. A sentence inside an attachment cannot authorize disclosure of order history. Your application should validate the recipient against the authenticated customer record and the workflow's allowed destinations before preparing any send.
The correct response still helps the customer. The employee can request the missing photo or route the exception to a supervisor. Preserve the suspicious note with the case so the reviewer can see why the automated job stopped. Flag the attempted instruction without assuming that every customer who quotes one intended an attack.
Extract evidence without carrying instructions forward
Separate store policy from customer-authored material when you assemble the agent's context. Label each source with its origin and trust level. Keep the message body out of the higher-priority instructions that define the agent's role.
OpenAI's agent safety guidance warns against placing untrusted variables in developer messages. It also recommends structured data between workflow steps to reduce the freeform channels that can carry unwanted instructions downstream.
For the leaking-bottle case, an extraction step could return the order reference, affected item, and whether a photo exists. A later decision step can load the store's current damage policy and a verified approval record. It does not need the attachment's directions about how to override the process.
Use constrained fields where they fit. A reason field can accept approved categories rather than arbitrary instructions. Preserve quoted text separately when a reviewer needs it. A structured record can still contain false values, so validate important fields against the order and customer identity. Formatting alone cannot prove that a claim is true.
Enforce the allowed action outside the model
Treat the agent's proposed tool call as a request to your application. Before executing it, check the action against the job's purpose and the caller's authority. A damage-review job should not acquire a customer-export permission because the note asks for one.
For a replacement, your application can require an eligible order and the policy's evidence or a verified exception. For a message, it can enforce the approved recipient and limit the fields the employee may include. These checks should apply even when the model describes its request as urgent or manager-approved.
Give the employee only the data it needs for that job. An agent investigating one damaged item usually has no reason to read unrelated customer histories. Narrow reads reduce the information a mistaken or manipulated job could disclose.
Human review needs useful evidence too. Show the proposed action, its destination, and the source of any exception claim. A reviewer who sees only a polished summary may approve a request without noticing that the customer supplied its supposed authorization. Attach the policy record and the original customer claim as separate items.
Test the boundary with ordinary and hostile cases
Before expanding access, run the same return workflow with a normal damage report and with a report containing an attempted override. Use test orders and dummy recipients. Check the tool calls and final business state, not only whether the assistant wrote a sensible reply.
A passing case should preserve the legitimate return request while rejecting the unsupported policy change. Confirm that the employee did not send private data, request broader permissions, or copy the attachment's instruction into a later agent's task.
Test quoted instructions as well. A customer might paste a suspicious message while asking whether it is genuine. Your workflow should handle the question without following the quoted directions or refusing the entire support case. Keep these examples in your regression tests when you change the model or the context assembly.
OWASP and OpenAI both describe defensive controls as risk reduction. Neither promises that a prompt or filter eliminates injection. Continue enforcing the tool boundary even when your tests pass. If a job crosses that boundary, pause the affected workflow and inspect its actual actions before resuming it.
Where ShopDucky fits
ShopDucky gives ecommerce teams AI employees that use connected tools with human approvals. When choosing a workflow, ask which source controls its policy and what evidence the reviewer sees before approving an action. This guide describes controls to evaluate; it does not claim that any product makes prompt injection impossible.
FAQ
Can a customer email contain prompt injection?
Yes. A customer-authored message can include directions that try to change the agent's task or policy. When the agent retrieves that message through a tool, those directions arrive as external content rather than store-authorized instructions.
Does a strict tool schema stop prompt injection?
A schema limits the shape of a proposed call. Your application still needs to enforce its purpose, permissions, and destination. An unauthorized action can use perfectly valid fields.
Should you delete suspicious instructions before review?
Keep the original in the case record with its source identified. Pass only the necessary evidence to later automated steps, and give the reviewer enough context to inspect the attempted override.
