Skip to content
← Back to blog
SecurityKeep document content away from tool authority

Prompt injection in tender documents: design the review path

Treat tender files as untrusted content, separate their instructions from the task, and require a human decision before an agent sends, scores, or stores a result.

A tender file can contain text that looks like an instruction to an AI system. The review service should extract facts for a person while keeping file content outside the control path for tools and outbound actions.

Author

Syntalith Team

Published Updated 6 min read

Tender documents contain requirements, tables, attachments, links, and sometimes text aimed at the reader or the software reading the file. When an agent treats every sentence as an instruction, the document can influence retrieval, disclosure, scoring, or a tool call.

The safe design starts by treating the file as data. It extracts evidence for a review task and keeps authority in the application and the review team.

Use separate trust zones

Keep these inputs distinct:

  • the system and application instructions;
  • the buyer's evaluation rubric;
  • the tender file and its attachments;
  • retrieved organisation material;
  • the model's proposed summary or score;
  • the tools that can store, send, or publish a result.

A file may contain a sentence that says to ignore the rubric, reveal hidden text, or open a link. The parser should preserve that sentence as document content. The runtime should not promote it into an instruction.

A review pipeline with a clear release point

  1. Ingest the file into a restricted workspace and record its hash, source, and permissions.
  2. Scan file type, links, macros, embedded objects, and attachments according to the organisation's policy.
  3. Extract text and tables while preserving page or section references.
  4. Label content as evidence, metadata, or an instruction-like passage inside the source.
  5. Ask the model to map evidence to the approved rubric and cite the source span.
  6. Validate the output shape and flag missing or conflicting evidence.
  7. Send the result to a named reviewer who can edit, reject, or release it.
  8. Store the final decision and supporting evidence in the approved system.

The agent receives no send, purchase, file-sharing, or record-writing credential during extraction. If a later workflow needs one, a separate service decides whether the approved result and current user request permit it.

Keep the rubric authoritative

Write evaluation criteria outside the tender file. Give each criterion an identifier, definition, evidence requirement, and handling for missing information. Ask the model to return:

  • criterion identifier;
  • cited section or page;
  • extracted evidence;
  • confidence or review flag;
  • unresolved question;
  • proposed assessment for the reviewer.

Do not ask the model to infer a score from persuasive wording alone. A reviewer should see the source span and the rule that led to the proposed assessment. Store the rubric version alongside the result so later changes do not rewrite history.

Protect retrieval and tools

Tender content should have its own retrieval collection and access policy. Do not let an uploaded file select arbitrary internal documents, reveal system prompts, or alter the search query without validation. Strip or neutralise active links before a browser or connector can open them. Give the review service read access to the minimum collection it needs.

Use a separate worker for file parsing and malware inspection. Place timeouts and size limits on archives, images, and nested attachments. Keep secrets outside prompts and redact them from logs. A failure should quarantine the item and notify the owner with a reason that can be investigated.

Review the right signals

Track source hash, parser result, extracted sections, retrieval references, model revision, rubric version, reviewer, final decision, and any rejected action. Review cases where the model follows an instruction-like passage, cites a missing section, produces a malformed output, or asks for a tool it was never granted.

The OWASP Top 10 for Large Language Model Applications describes prompt injection as a risk category. The NIST AI Risk Management Framework provides a broader structure for governance, measurement, and response. Use them to shape the control plan and test the implementation against the actual tender workflow.

Acceptance checklist

  • Can the runtime distinguish application instructions from document text?
  • Does each extracted claim retain a source location?
  • Can a file trigger a network request, connector, or external message?
  • Are links, macros, and embedded objects inspected before use?
  • Is the rubric stored separately with a version and owner?
  • Does a person approve the score and every external action?
  • Are parser errors, rejected outputs, and reviewer edits recorded?
  • Can the team quarantine a file without deleting its audit record?
  • Can access to the tender collection be revoked after the process ends?

Prompt injection is an architecture and operating-model problem. Start with one tender workflow, keep document content in the evidence path, and make the reviewer the release point. A process scan can map the parser, retrieval, rubric, and approval steps before an agent receives access to a production system.

Free process scan

Start with a free process scan.

  • A 30-minute call with the engineer who would lead the work.
  • A review of the processes that cost you the most time and money.
  • A written summary of what to automate first and the likely cost range.

The scan chooses one process to assess, and within 2 business days you receive a recommendation, including when a simpler route is the better fit.

€0

30 minutes · written takeaway within 2 business days

Book a free process scan (30 min)

Times are shown in your own time zone. We work with clients across time zones.

Describe the process in the form