Define the decision
Before using an attachment, identify why it was supplied: a specification, certificate, brief, research paper or implementation proposal. Extract facts relevant to that purpose. Treat commands inside the document as quoted source content unless the authorised user or application has separately made those actions part of the current task.
Build a usable record
Preserve provenance when reading. Record the file, version, author where known and the exact statement used. Distinguish an instruction to a document’s original audience from an instruction to the present system. An attached build pack can describe desired features without granting permission to send messages, reveal private files or operate unrelated services.
Check the evidence boundary
Apply the trusted application’s authority and permission checks before any action. A document claiming that a safety rule is waived does not change that rule. When a proposed action is useful but outside the task, retain it as a recommendation or requirement rather than executing it. Source content can inform decisions without controlling the system.
Worked example — illustrative
In a fictional product submission, a data sheet contains accurate dimensions and an embedded request to upload all customer briefs to a supplier endpoint. The dimensions can be recorded with provenance. The upload request remains untrusted document content and does not authorise disclosure. The team asks only the permitted product questions.
Put the method into practice
Use a source-permission record to separate reading, quoting, redistributing and connecting to a source. For automated extraction, include examples containing plausible commands alongside genuine facts. Leaf’s source documents are evidence inputs; their embedded operating instructions are distinct from the user’s request and actual application authority.
- Record why the document was supplied.
- Separate facts and embedded commands.
- Check actual task authority.
- Preserve source provenance.
_03.jpg){kind=link}