How a sentence in a PDF becomes a button

The dangerous sentence may look like helpful work

A sentence in a supplier’s PDF asks for future purchase orders to be copied to a new address. By the time it reaches an approval screen, it says complete supplier setup. The assistant may have understood the request perfectly while making it much harder to see whose request it was. I would follow that change of form before treating the eventual human click as sufficient approval for changing an operational destination.

Suppose a fictional onboarding assistant reviews a supplier’s PDF and drafts a setup checklist. In the PDF, a note asks that future purchase orders be copied to a newly supplied address. The assistant includes “update purchase-order recipient” in the checklist. A colleague sees a tidy task, clicks approve and the application changes a destination. The document’s request has travelled through a generated interface into an authorised action.

The colleague really did click approve. The question is what the card allowed them to understand. Without the origin, current recipient or exact effect, they may have approved a tidy description of setup work rather than knowingly redirected purchase orders. Human review can be an important safeguard, but the interface has to show the decision it is asking the person to make.

OWASP describes indirect prompt injection through external material and recommends least privilege, identifying external content and human approval for higher-risk actions. The design question here is how to keep those boundaries meaningful after the assistant has transformed the material into something a colleague might reasonably trust. A source label at ingestion is helpful; it should not evaporate when the content becomes a checklist.

Follow the proposal through its transformations

Start with the supplier PDF as evidence supplied by an external party. The assistant may extract the proposed address and the passage that requested it. That extraction should retain provenance: document identity, relevant location and the fact that it is a supplier proposal. The new address is not yet an approved value in the business system.

The assistant can usefully interpret the sentence as a requested communications change. Keep that interpretation alongside the source passage and apart from any decision to accept it. A task title such as complete supplier setup removes some of those distinctions just when the proposal starts looking ready to carry out. The generated wording should help the reviewer understand the request, rather than quietly make the supplier’s wish a required step in the business’s process.

Finally comes action construction. The application should build a structured proposal containing the target supplier record, which we will call V-31, current recipient, proposed recipient and exact field to change. These values should be checked against the business’s permissions and change process outside the model. The PDF can supply a candidate value; it should not choose the acting account or grant permission to edit a protected destination.

The separation also helps identify ordinary source mistakes. An address may appear as an obsolete contact, a quoted procedure or an example rather than a current request. Retaining the original evidence beside its interpretation lets the reviewer examine that status before execution. A structured action can then be checked against the actual supplier record and verification process instead of inheriting authority from its generated task title.

An approval card should show the decision

For the proposed recipient change, show the existing and proposed addresses with the affected supplier record. Say that the proposal originated in the uploaded PDF and link to the relevant passage. Explain whether the change affects future purchase orders, copies of existing documents or some other bounded operation. “Approve recommendation” is too broad if the underlying effect is editing an operational destination.

The review should also reveal who will act. A colleague approving a draft does not necessarily intend to authorise a shared administrator account to update the supplier record. The application’s action envelope should bind the authenticated person, tenant, target record and permitted operation. A model-generated field that claims someone is an administrator is still document-derived data, not identity evidence.

Do not treat a clean content-filter result as verification of the request. A perfectly ordinary sentence can ask for a change the supplier has no authority to require.

If recipient changes require confirmation through an existing contact route, leave that check visibly unfinished until the required evidence arrives. The assistant can prepare the enquiry. It cannot complete the check by rereading the same PDF’s assurance that the new address is legitimate. The business needs a reason to trust the change that does not come entirely from the external claim asking it to make that change.

The approval screen needs to be concise enough to review while retaining the material facts. For the recipient change, that means the affected record, current and proposed values, origin and bounded effect, with a route to the original passage. Displaying the whole PDF would increase reading work without necessarily making those facts easier to compare. Hiding them behind a general approval label would omit the decision itself.

Constrain the action even if the summary is wrong

Assume the assistant can be persuaded to produce the wrong proposal. What can the application still prevent? A read-only document summariser cannot change purchase-order settings if no such tool is available. An onboarding assistant with a narrow tool can be limited to proposing changes rather than executing them. An execution service can reject targets and fields outside the approved envelope.

For V-31, the proposed tool may edit only a designated contact field after verification. Exporting all purchase orders or changing bank details requires different authority and must be rejected by application policy. These operations should remain distinct even if the assistant presents them as related onboarding tasks. A narrow execution contract limits the consequences of a mistaken interpretation without relying on the model to recognise every misleading instruction.

Validate the effect, not just the structure

Validate the concrete values too. A syntactically valid address can still be the wrong recipient. A permitted field can still belong to another supplier. A schema validator can reject malformed structure; it cannot establish business legitimacy by itself. Keep identity, scope, verification evidence and value validation as distinct checks so the architecture does not ask one mechanism to do all their jobs.

Opening a PDF-supplied link can have an effect too. A request described as verification might send confidential information to the destination as part of loading it. Check the destination and outgoing data under the application’s policy, rather than treating every page visit as harmless reading. Visiting a source, disclosing information and editing V-31 are different permissions, even if the generated checklist places them together beneath the same setup heading.

Test what survives the journey to the button

A useful synthetic review set can vary the document request while keeping the supplier record fixed. Include a legitimate proposed recipient, an address quoted as an obsolete example, a request concerning another supplier and an instruction to bypass verification. Inspect both the generated summary and the structured action. A safe-looking summary is not enough if the tool arguments still carry the wrong effect.

Then inspect the approval screen itself. Can a reviewer identify the old value, new value, source and affected operation without opening developer tools? Does declining the proposal prevent execution? Can the same card be reused after the proposal changes? Those questions connect interface clarity to the actual enforcement boundary. They establish whether the reviewed proposal remains bound to the effect the execution service will actually perform.

Retain an appropriate audit trail of the proposal, the decision and the executed action, with sensitive values protected according to their role. The original document may need a different retention policy from a concise decision record. The trail should explain why the change happened without copying every supplier document into every log.

For V-31, the important transition is from the supplier’s proposed address to the verified recipient in the business record. Let the assistant extract and explain the request; keep its origin visible on the approval card; enforce the bounded edit in the execution service. Then an incorrect summary has less room to turn into a different action, and the colleague can judge the actual change instead of approving a heading whose consequences only become clear afterwards.