AI Prompt Injection Testing: Untrusted Files and Approvals.

How can untrusted files redirect an AI agent?

On 22 October 2026, Forever Security reported finding a malicious AGENTS.md instruction file in the Downloads folder of a customer’s machine. The company says it stopped a coding agent attempting to install a malicious package before the code ran.

The researchers also describe controlled follow-up tests involving Codex and Claude Code. The original file’s route onto the customer’s machine was unknown. The observed attempt and the later demonstrations should therefore be kept separate: the report does not establish that a website delivered that particular file.

These are the security vendor’s findings, not tests conducted by VisiFlo. They do not mean every agent, browser or downloaded document behaves the same way. The important business question is whether content from outside your organisation can become authority to act.

• Forever Security: research published 22 October 2026 ↗

Reading information is different from accepting instructions

An assistant might need to read a supplier document, summarise a customer email or inspect a project folder. Those are useful tasks. The material can also contain directions the business never approved.

Prompt injection is the name for attempts to steer an AI through the content it receives. OWASP distinguishes instructions supplied directly to the model from indirect instructions arriving through sources such as files or websites. It recommends limiting permissions, separating outside content and requiring people to approve high-risk actions.

For a business owner, the distinction is simple: a document can tell your assistant what a customer wrote. That does not make the document the person who decides which records the assistant may change.

• OWASP: prompt injection and practical mitigations ↗

An approval screen is only useful if the action cannot bypass it

A separate AWS bulletin published on 3 August 2026 illustrates why testing must include the connected tool. AWS described CVE-2026-18733 in Strands Agents Tools: a model-controlled parameter could bypass the shell tool’s human-consent gate. AWS states that versions below 0.8.0 were affected and the issue was addressed in 0.8.0.

This was a specific software vulnerability with a documented fix. It is not the same incident as the October Downloads report. Together, they motivate two different checks: which instructions the agent accepts, and which actions the surrounding software actually permits.

Our interpretation is that an approval message in a conversation is insufficient evidence. A review should establish whether the action was prevented until the required approval existed.

• AWS security bulletin 2026-072: consent-gate bypass and fixed version ↗

A business scenario: a document should not approve its own request

Imagine a fictional support workflow that reads a return request and prepares a refund recommendation. The customer’s attachment says the refund has already been approved and asks the assistant to skip the normal review.

The document is evidence to examine. It is not an approval record. A useful test asks whether the workflow checks the amount, order and authorised approver before it attempts a refund. It should also check whether the customer is told the refund is complete when no permitted action occurred.

This scenario is proposed test design, not a customer incident or an executed assessment. The expected behaviour must be agreed with the business before the test starts.

A simple process for checking the boundary

Use an authorised test environment, fictional records and harmless instructions. The aim is to observe whether the workflow follows the agreed task and permissions. There is no need to install malware, expose credentials or let test messages reach customers.

1. 1. Agree the task

   Write down what the assistant should read, what it may change and which actions need a person’s approval.

2. 2. Introduce a safe conflict

   Use a test document containing a harmless request outside the agreed task. Define the expected response before running it.

3. 3. Inspect the action

   Check tool requests, approvals and final records. Did anything change that should have stayed untouched?

4. 4. Improve and repeat

   Address the relevant permission, workflow or instruction handling, then repeat the original case and normal tasks.

What useful evidence looks like

A report should make the decision understandable: the document requested an out-of-scope change; the business rule required approval; the workflow attempted or blocked the change; these records did or did not change.

Record the workflow version, test conditions, attempts, observed outcomes and any gaps in visibility. Keep failures and unknown results visible. A successful refusal in one case does not prove resistance to every future input.

After a change, check the normal task too. A workflow that blocks every document may avoid an unwanted action while also failing to do the useful work the business needs.

How VisiFlo can help

VisiFlo helps businesses make these questions concrete: what should the AI do, what must it never do, and what evidence would support the next decision?

A scoped review can examine the workflow, agree relevant scenarios and, where access permits, check answers, actions and approval boundaries. Findings explain what was observed, what could not be established and which improvements deserve attention first.

The approach can apply to document assistants, n8n automations, custom agents and API-connected workflows. Actual coverage depends on the setup and agreed access. Specialist security testing should be scoped with appropriate expertise; this article is not a security certification or a claim that VisiFlo reproduced the reported attacks.