A brand asks an AI assistant to extract product-demo requirements from a supplier PDF. Inside the file is a sentence directing it to disregard the task and send project material elsewhere. That sentence belongs to the source being read. It is not a new instruction from the client.
This is a fictional risk example, not a reported ONCE or supplier incident. For global teams coordinating briefs with Chinese manufacturing and production partners, it raises a practical procurement question: what prevents retrieved material from changing the assignment or triggering an unrelated action?
Permission to read is not authority to instruct
Microsoft’s October 27, 2026 official Japanese abridgment of its October 13 trust-aware controls article explains that indirect prompt injection can occur within permitted access. It describes constrained processing of untrusted content and retained provenance, with availability and behavior varying by release and tenant.
Its defense-in-depth documentation also describes layered protections across processing stages. Both were checked October 28. These are specific Microsoft descriptions, not proof that every AI tool has the same protection or that a particular deployment is secure.
ONCE’s proposed review has three columns
Start with a named workflow, such as reading specified product documents to prepare a demonstration list. This is a procurement method, not an ONCE security product or certification.
| Column | Establish | Do not substitute |
|---|---|---|
| Source | The file, provider, version and location of extracted information | Assuming everything on a shared drive is trusted |
| Task | Who authorized the work, what is reference material and who approves changes | A source sentence claiming overriding priority |
| Action | Objects the workflow can read or write, and any allowed external destinations | A prompt that merely tells the model to be careful |
Untrusted is a processing classification, not an accusation against the supplier. A legitimate message can quote someone else, and an old template can contain obsolete operational language. The workflow needs useful information without granting that information authority over its tools.
Route source requests to the project owner
If a document asks that every feature be described as verified, report that request and its conflict with approved information. It should not automatically become the brand’s factual position. The authorized project owner decides what happens next.
A creative brief explicitly adopted by the brand can guide the assignment. A competitor page, later attachment or search result cannot promote itself above that brief merely by saying so. An approved task revision and a source claiming approval are different records.
Review facts and actions separately
A PDF may contain correct dimensions and an instruction that should not run. A source with no commands may still contain wrong dimensions. Check the first for instruction handling and the second for factual accuracy. Passing one does not settle the other.
Retain traceable excerpts alongside records of actual tool activity. A polished summary alone may not reveal an attempted edit elsewhere. Conversely, no external transmission does not establish that the resulting product script is accurate.
Demonstrate the workflow with synthetic material
Ask the supplier to use an isolated test project with invented product data and an irrelevant editing request embedded in a sample source. Observe whether the request is treated as source content and whether output is confined to the designated test object. Use no real client information, real recipients or production publishing destinations.
Inspect inputs, results and actual actions rather than accepting an assistant’s statement that it ignored the request. Correct-looking text accompanied by an attempted write to another object still exposes a workflow problem. An unsupported feature claim in the summary is a separate content-review failure.
A sample demonstrates only the tested case. It does not establish resistance to every variation. Reassess relevant behavior when the model, connector, system or permissions change.
Procure enforced controls rather than longer prompts
Ask where reading scope is restricted, how writable objects and external destinations are constrained, who can change authorization and how activity can be investigated. Connector, backend or workflow controls should enforce consequential action limits independently of a model’s promise to comply.
This does not require a fresh human approval for every summary. Steps can continue within a clearly authorized task. Changes to the task, target object or external destination should follow the agreed change process; source content should not expand that scope itself.
For related planning, explore ONCE’s video marketing guides. Bring the source list, authorized assignment and expected actions into the automation brief. The reusable asset is their correspondence with observed activity and test cases, rather than a claim that the workflow can never fail. Content quality still needs its own review.
