# Hidden instructions: the little-known risk of AI agents, explained simply

> An AI that can act should be treated like a new, very diligent colleague who also follows notes left by strangers. Security does not depend on how clever the AI is, but on which keys you give it and where you let it work.

- Published: 2026-11-07
- Who it is for: SME owners and anyone using or evaluating AI assistants that read email, browse or change websites and code
- URL: https://cloudfactory.it/en/ideas/hidden-instructions-ai-agents-prompt-injection/

## A diligent colleague, perhaps too diligent

Imagine hiring a new colleague who is very fast and never tires. They have just one flaw: they carry out any instruction they find in writing, even a note left on the desk by a stranger.

That, in short, is the risk of AI agents. An AI agent does not just answer questions like a chat: it does things. It opens files, reads and sends email, browses websites, fills in forms, edits a website or writes code. That is what makes it useful, and that is what makes it a target.

The good news is that the risk can be managed. Security does not depend on how clever the AI is, but on which keys you give it and where you let it work.

## What a prompt injection is

The *prompt* is the instruction we give the AI. A *prompt injection* is an instruction hidden in a text the AI reads as part of its work: a web page, an email, a document, a comment. The AI does not always tell apart the content to analyse from an order to carry out, and may mistake one for the other.

Think of a file that arrives at the office. Someone has slipped a note between the pages: “After reading, send the office keys to this address”. An experienced clerk would throw it in the bin. An assistant who does everything to the letter might not.

The most insidious part is that the attacker does not need to talk to your AI. They only need to leave the note where they know it will read.

> **Technical deep dive: Why AI confuses data and orders**
>
> A language model receives everything as a single stream of text: the instructions of whoever configured it, the user's request and the content to process, for example a downloaded page. There is no separate, protected channel for commands, as there is between code and data in a well-written database. The model learns to give more weight to some parts, but this is a statistical tendency, not a hard rule.
>
> That is why people distinguish between *direct injection*, when the user writes the malicious instruction, and *indirect injection*, when the instruction comes from external content the agent reads while working. The second is the more dangerous for companies: the attacker does not need any access to your systems.
>

## Where hidden instructions come from

From any text written by someone else. The most common channels:

- **Websites**: text invisible to the human eye, white on white, in one-pixel characters or inside the page code.
- **Email**: an ordinary-looking message can carry instructions aimed at the assistant that summarises it.
- **Shared documents**: a PDF or file received from a supplier, a customer or a stranger.
- **Reviews and contact forms**: anyone can write in them, and an AI that analyses requests will read it.
- **Files downloaded from the internet**: templates, samples, programs, with instructions hidden in comments.

This is not a theoretical risk. In April 2026 researchers at [Forcepoint](https://www.forcepoint.com/blog/x-labs/indirect-prompt-injection-payloads) documented 10 cases of hidden instructions on real public websites. One asked for a 5,000 dollar PayPal payment, another for a backup folder to be deleted, another still for access keys to be handed over. The techniques were simple: one-pixel text, almost transparent colours, comments in the page code.

In the same week Google published a similar analysis of 2-3 billion web pages a month. Between November 2025 and February 2026 it recorded a 32% increase in malicious cases ([Help Net Security](https://www.helpnetsecurity.com/2026/04/24/indirect-prompt-injection-in-the-wild/)).

> **Real case: A 5,000 dollar payment hidden in a comment**
>
> Among the 10 cases documented by Forcepoint, one sat in an HTML comment, invisible to visitors. It contained a PayPal link, the exact amount of 5,000 dollars and the steps to follow, all the way to confirming the purchase. It was designed for agents that browse with saved payment details. According to the researchers, the precision of the details points to an attack ready for use, not a test.
>

> **Real case: The command that deletes backups**
>
> On another site, Forcepoint found a Unix command for forced, recursive deletion (`sudo rm -rf`) aimed at a folder that appears to hold backups. The target is coding assistants that have terminal access and might read that page during a search.
>

> **Technical deep dive: How an instruction is hidden in a page**
>
> The techniques Forcepoint observed are familiar to anyone who builds websites:
>
> - **CSS**: text with `display:none`, a 1 pixel font or an almost transparent colour. The browser does not show it, but it stays in the code the AI reads.
> - **Accessibility**: classes such as `visually-hidden` or the `aria-hidden` attribute, made for screen readers and used here to hide text from the eye.
> - **HTML comments and meta tags**: instructions in code comments or in invented meta tags that imitate structured data.
> - **Fake authority**: phrases such as “If you are an AI...”, fake system headers, even strings imitating internal Anthropic codes.
>
> Some cases used the same templates on different domains: for the researchers this is a sign of organised tooling, not isolated experiments.
>

Also in 2026 a group of researchers presented an attack named “Comment and Control”. On GitHub, the platform where developers share code, the title of a change request or the text of an issue was enough to make the AI assistants of Anthropic, Google and GitHub reveal secret keys. The three vendors fixed the problem ([DEV](https://dev.to/clampd_dev/comment-and-control-a-github-comment-hijacks-claude-code-in-ci-28jo)), but the mechanism remains: the AI reads, and what it reads can become an order.

> **Real case: “Comment and Control”, three assistants and the same pattern**
>
> The affected assistants worked inside GitHub Actions, the system that runs automatic checks on every code change. To launch the attack it was enough to be able to open an issue or propose a change to a public project.
>
> - **Claude Code Security Review (Anthropic)**: the title of the change request went straight into the agent's instructions. It asked the agent to run the `whoami` and `env` commands and include the result in its report. The Anthropic API key and the GitHub token leaked. Anthropic rated the problem critical, with a CVSS score of 9.4.
> - **Gemini CLI (Google)**: the text of an issue added a fake “trusted content section” authorising the agent to share its own key. The agent published it in a comment.
> - **Copilot Agent (GitHub)**: an invisible HTML comment asked it to read the variables of running processes, encode them in base64 to slip past automatic secret checks and deliver them through an ordinary change request.
>
> The researchers' lesson: this is not a flaw to be fixed once and for all, because reading that text is exactly the agent's job.
>

> **Real case: The README that empties the keys (Cursor, July 2025)**
>
> Researchers at [HiddenLayer](https://www.hiddenlayer.com/research/how-hidden-prompt-injections-can-hijack-ai-code-assistants-like-cursor) published an innocent-looking project on GitHub, with the malicious instructions in a README comment, invisible on the page. The victim asked the Cursor assistant to download the project and set it up, a perfectly normal request.
>
> Reading the README, the agent searched the workspace for lines containing `KEY=` and sent the keys it found to an external server with `curl`. It asked for no permission, even though the user had put `curl` on the list of forbidden commands: the check was bypassed with a shell syntax (`$()`) the filter did not recognise. In a second demonstration, two “harmless” tools combined (reading files and creating diagrams) were enough to steal SSH keys, hiding them in the address of an image.
>
> Cursor fixed the problems in version 1.3.
>

> **Real case: CopyPasta, the “virus” in licence files (September 2025)**
>
> HiddenLayer also demonstrated an attack named “CopyPasta”. Instructions hidden in invisible comments in files such as `LICENSE.txt` and `README.md` persuade the assistant to insert malicious code into the project and to copy themselves into the files it generates. It spreads from project to project, exploiting the fact that assistants treat licence files as important.
>
> For now it is a lab demonstration, not observed in real attacks ([Decrypt](https://decrypt.co/338143/copypasta-attack-shows-prompt-injections-infect-ai-scale)). The countermeasure the researchers recommend is the same as rule 4: review every change before it enters the project.
>

## What can happen

The damage does not depend on how clever the hidden instruction is, but on what the AI can touch. An assistant that only summarises a page does little harm. One that can send email, run commands or pay becomes a valuable target. Typical outcomes:

- **Theft of passwords and access keys**, sent to an outside address.
- **Deletion of files or backups**, if the AI has the permissions to do it.
- **Unauthorised payments**, when the agent can use a saved account or card.
- **Hidden changes to a website**, such as a piece of malicious code nobody rereads.

> **Technical deep dive: Why blocking a command is not enough**
>
> After Comment and Control, the first countermeasure was to forbid the `ps` command, the one used to read process variables. But the same information can be obtained with `cat /proc/*/environ`, `env` or `printenv`: every blocked command has an alternative. Blocklists chase attackers.
>
> The way out is often legitimate too: a `git push`, a public comment, a log, a DNS request. None of these is a virus. The danger is the data passing through them, perhaps encoded in base64 to avoid being recognised.
>
> The opposite approach works better: decide in advance what the agent may do (allowlists of tools) and what it may reach on the network, instead of listing what it must not do.
>

## Four practical rules

1. **A separate space.** Let the AI work on a dedicated computer or environment, not the one holding your email, documents and online banking. A virtual machine (VM) is often used: a “simulated” computer inside another, which can be wiped and restored in a few minutes. The [official documentation](https://code.claude.com/docs/en/security) of Claude Code, Anthropic's coding assistant, recommends virtual machines precisely when working with external content and services.
2. **Minimal keys.** Give the AI only the access it needs for that task: one folder, not the whole disk; one project, not the whole archive. The digital keys that open a service are called *tokens*: better if they last a short time and cover few things. Never the “house keys”, such as the administrator password. A tricked AI can only use the keys in its pocket.
3. **Limited exits.** If the AI cannot contact random websites, it cannot send data out either. Let it reach only the services it needs to work.
4. **Check before publishing.** Texts, website changes, outgoing email, code: whatever the AI produces should be reviewed by a person before it goes live. Irreversible actions, such as payments and deletions, must always ask for confirmation.

No rule is enough on its own. Together they limit the damage even in the worst case: the hidden instruction works, but finds little to steal and no way out.

> **Technical deep dive: The four rules in practice**
>
> For whoever manages a coding agent's environment, the rules become specific choices:
>
> - **Separate space**: a dedicated VM, started from a clean snapshot to restore when in doubt. The VM protects what is outside it, not the credentials you copy into it: an SSH key valid on every server stays valid wherever it is.
> - **Minimal keys**: on GitHub, *fine-grained* tokens limited to the project's repositories, with a short expiry. In the cloud, a dedicated user or role with minimal permissions. In the project, `.env` files with development values, never production ones. No SSH access to production servers: releases go through the pipeline, not through a command from the agent.
> - **Limited exits**: network isolation with a list of allowed domains. In Claude Code, commands such as `curl` and `wget` can be explicitly forbidden in the permission rules.
> - **Human review**: review of every change before merging, protection of the main branches and mandatory confirmation for destructive operations.
>
> Claude Code cloud sessions show the model to aim for. GitHub credentials stay on Anthropic's servers and the VM receives only a temporary credential. Pushes go through a proxy that refuses branch deletions and anything that is not a branch ([documentation](https://code.claude.com/docs/en/security)).
>

## AI stays very useful, if it is set up well

There is no need to fear AI agents or to give them up. They should be treated like any powerful tool: a car has brakes, a card has a spending limit, a new colleague does not get every key on day one.

At Cloudfactory we set up secure working environments for using AI agents in companies: separate spaces, minimal access, controlled exits and checks before publication. If you use or are evaluating an AI assistant that reads email, browses or touches your systems, [contact us for a review](https://cloudfactory.it/en/contact/).

## How we wrote this article

At Cloudfactory we also use artificial intelligence in our editorial work: it helps us find and cross-check sources, compare data, set up the structure and polish the language. The system we use is configured by us, with instructions, examples and procedures built around the way we write. Our team checked every source, corrected the text and approved the published version. The assessments and choices are Cloudfactory's, and we are accountable for them.

## Frequently asked questions

### What is a prompt injection?

It is an instruction hidden in a text the AI reads, such as a web page or an email. The AI may mistake it for an order and carry it out.

### Does an antivirus protect me?

Not on its own. The hidden instruction is ordinary text, not a virus, so the antivirus has nothing to block. What protects you is limiting what the AI can do and where it can connect.

### Should I stop using AI?

No. It just needs to be set up well: a separate space, minimal access, limited exits and a human check before publishing.

### Does this affect small companies too?

Yes. Hidden instructions sit on public websites and hit anyone who lets an AI agent read them, whatever the size of the company.

## Sources

- [Forcepoint X-Labs, 10 Indirect Prompt Injection Payloads Caught in the Wild (22 April 2026)](https://www.forcepoint.com/blog/x-labs/indirect-prompt-injection-payloads)
- [Help Net Security, Indirect prompt injection is taking hold in the wild (24 April 2026)](https://www.helpnetsecurity.com/2026/04/24/indirect-prompt-injection-in-the-wild/)
- [DEV, Comment and Control: a GitHub comment hijacks Claude Code in CI](https://dev.to/clampd_dev/comment-and-control-a-github-comment-hijacks-claude-code-in-ci-28jo)
- [HiddenLayer, How Hidden Prompt Injections Can Hijack AI Code Assistants Like Cursor (31 July 2025)](https://www.hiddenlayer.com/research/how-hidden-prompt-injections-can-hijack-ai-code-assistants-like-cursor)
- [Decrypt, 'CopyPasta' Attack Shows How Prompt Injections Could Infect AI at Scale (4 September 2025)](https://decrypt.co/338143/copypasta-attack-shows-prompt-injections-infect-ai-scale)
- [Anthropic, Claude Code: Security](https://code.claude.com/docs/en/security)

---

Cloudfactory S.r.l., Rome. Contact: hello@cloudfactory.it