Hidden instructions in documents AI reads: separate data from permissions
Documents are data, but their text can issue instructions
When an organization lets AI read emails, PDFs or supplier documents, the task involves more than extracting facts. Some text may try to steer the system into actions the task owner did not request, such as changing its response or sending data to another recipient. Before connecting AI to systems that act on people's behalf, define which documents are supporting data and who can authorize actual actions.
Recognize instructions carried by external content
OWASP calls instructions embedded in external documents, websites or emails indirect prompt injection. A conceptual example is a quotation document telling an assistant to send internal information to a new address. Being inside a file the AI needs to read does not give its sender authority over organizational data. This differs from summarizing a number incorrectly: it concerns changing the task or the scope of action.
Define the task before the system reads
Write a verifiable scope, such as reading documents to summarize items for review without adding recipients or changing source records based on file contents. Separate incoming information from user-authorized instructions, and specify who reviews requests outside that scope. Telling AI to ignore unusual instructions is only one measure; a warning in a prompt should not replace permission controls.
Control permissions in the system and its tools
Start with read access to the necessary dataset, and separate email sending, record editing and data export tools from document reading. The system invoking tools should check recipients, records and scope against the authorized task, rather than letting file contents expand permissions. Actions with significant effects on data or other people should have a responsible person review the actual action before execution, not just the AI's summary of it.
Test observable effects
Before launch, use dummy documents and a test outbox disconnected from real recipients. Include situations in which a document tries to change recipients or request unrelated data, then check for tool calls, transmissions or record changes. A response that appears to refuse is insufficient if the underlying system has already acted. Record the document version, expected outcome and actual outcome, while keeping secrets and sensitive data out of test logs.
Start with one organizational workflow
For a discussion with Chawinnix about AI/Automation and IT security, choose one document-based workflow. Identify file sources, the data the system may read, intended follow-up actions and the people responsible at each stage. This helps define system boundaries and tests around real work. Dividing permissions and checking outcomes can reduce risk, but does not guarantee prevention of every hidden instruction.
