It is no longer unusual for companies to delegate tasks to internal AI agents, telling them to read and summarize documents or review customer inquiries and draft replies. At this point, we urge you to pause and consider: what happens if malicious instructions are hidden inside the documents, web pages, or inquiry bodies that the agent reads? An AI cannot reliably distinguish between your explicit commands and instructions written inside text it happened to read.
The reality of this threat was demonstrated in July 2026 by a real-world case called "GitLost." An attacker succeeded in getting a GitHub AI agent to read the contents of private repositories and post them into public comments simply by planting a single sentence in a public GitHub issue. It required no code writing, no stolen passwords, and not even write permissions. We break down the mechanics of this "indirect prompt injection" vulnerability and what companies delegating tasks to AI must establish before rollout.
What GitLost revealed
Announced on July 6, 2026, by security firm Noma Labs, "GitLost" is a prompt injection attack targeting agentic workflows on GitHub. The method works as follows: the attacker embeds hidden instructions for AI agents inside what appears to be an ordinary public issue. When the agent reads the issue, it follows the hidden instructions, resulting in a demonstrated breach where it reads the contents of private repositories and posts them as public comments (InfoQ, Noma Security).
Crucially, all the attacker needed was the ability to open a single public issue. They did not touch any servers, require stolen credentials, or need write permissions to the target (The Register). Rather than a simple bug, this is explained as a risk pattern inherent to the design of AI agents themselves. While the risks of passing credentials to AI agents were discussed in Before handing credentials to AI agents, this issue is of a different nature. It is a scenario where an agent holding legitimate permissions is manipulated by external text into abusing those very permissions.
Why filters cannot stop it
One might think that filtering out dangerous inputs would suffice, but that will not stop indirect prompt injection. The reason lies in the conditions that make this attack possible: whenever untrusted external text, access to private data, and public output destinations coincide, an exfiltration pathway is already formed.
AI agents receive both your instructions and the commands found in read issues or web pages as identical "text." While a human can spot that someone wrote a suspicious line, agents have no mechanism to reliably tell the two apart. Consequently, an infinite number of phrasings can bypass filters meant to block malicious sentences. This vulnerability broadens the more agents are connected to external data and tools, such as via MCP, because expanding connection points increases the opportunities for agents to ingest instructions written by third parties.
Therefore, the consensus among security experts is that defensive focus should not be on detecting injection itself, but on building an architecture where no harm occurs even if injection happens—specifically through narrowing permissions, isolating processing, inserting human verification, and restricting public outputs.
Key considerations for running in-house AI agents
If your company delegates workflows to AI agents, incorporate the following three points into your operating principles.
First, minimize permissions granted to agents. Avoid granting broad access "just in case" and restrict privileges strictly to what the task genuinely requires. The more an agent holds both read access to private data and write capabilities to external destinations, the easier an exfiltration path becomes. Second, treat all text originating externally as potentially hostile input. Design workflows under the assumption that inquiry texts, ingested web pages, and issues or comments written by third parties may contain embedded instructions for agents. Third, insert human review just prior to publishing or external transmission. Ensuring there is no unmoderated path from agent output to external or public endpoints serves as your final line of defense.
| Defense focus | Concrete measure |
|---|---|
| Permission | Grant only the minimum permissions required for work; avoid combining read access with external output capabilities |
| Input | Treat externally sourced text as hostile input |
| Output | Insert human review prior to public release or external transmission |
Controls to verify during adoption and vendor procurement
When outsourcing AI initiatives or automation, the essential checkpoints remain identical: What scope of permissions will be granted to the agent? How is the system designed regarding which inputs to trust and to what extent? Is there any pathway where agent output reaches the outside world without human review? Whether a vendor can clearly articulate these three points during the design stage is the dividing line between safe and risky partnerships. Additionally, clarifying boundaries on what data can be given to AI in tandem with the perspective of which country's servers process business data helps eliminate oversights.
First things to decide: permissions and output destinations
What GitLost demonstrated is that AI agents carry a blast radius when manipulated that matches their convenience. That blast radius is determined not by model intelligence, but by the permissions you assign and how output destinations are architected. Restricting these to the absolute minimum is far more effective than any attempt to filter injections.
If you wish to consult on designing secure in-house AI agent operations or assessing vendor controls, please reach out via our consultation on development, AI, and automation. Centered on auditing permission designs and output pathways, we propose safe operational frameworks built on the premise that incidents can happen.
