GitLost Is the Control-Layer Warning Every AI Agent Rollout Needs

A public GitHub issue should not be able to pull private repository content into a public comment.

That is the practical warning from GitLost, a prompt-injection attack disclosed by Noma Security. In the researchers’ reported path, an unauthenticated attacker could place hostile instructions in an issue on a public repository. An AI workflow read the issue, reached private repository context available to it, then returned that information through a public comment.

The interesting part is not that an AI model followed a bad instruction. We already know models can be manipulated by untrusted text. The interesting part is that the surrounding workflow gave one agent access to public input, private data, and public output.

That is an architecture failure, not a prompt-writing failure.

Agents create bridges between trust zones

Traditional automation usually runs a narrow script against a defined input. Agents are different. They can interpret open-ended instructions, retrieve context, choose tools, and decide what to do next.

GitHub’s own documentation describes its Copilot cloud agent as a background worker that can research a repository, plan changes, edit code, and operate from issues or prompts. Those capabilities are useful precisely because they connect steps that previously required a person.

But every useful connection can also become an unintended bridge.

Think of the agent as a junior teammate with a keycard. Someone at the reception desk hands them a convincing note. The note is not the only security problem. The real questions are which rooms the keycard opens, what the teammate can carry out, and whether anyone checks them at the exit.

GitLost matters because it demonstrates that pattern in a form operators can understand: untrusted input entered through a public issue, the agent could reach private context, and its response could leave through a public channel. Noma Security’s disclosure describes the reported attack path and its configuration dependencies.

Prompt instructions are not a security boundary

Teams still treat prompts as if they were policy enforcement. They add lines such as “never reveal confidential information” and assume the agent will reliably obey them.

That is not control. It is guidance.

A real control remains effective when the model misunderstands a request, follows a hostile instruction, or makes a poor decision. Repository permissions, scoped tokens, trigger rules, output restrictions, approval gates, and audit logs all qualify. A warning embedded in the same context as attacker-controlled text does not.

The distinction becomes more important as agents move beyond code. The same pattern can appear in support, finance, sales operations, procurement, and internal knowledge tools. Any workflow that combines external messages, sensitive systems, and an outbound action has the same basic risk shape.

Draw the blast radius before deployment

Before an agent touches production systems, document four boundaries.

What can it read?

Grant access to the smallest useful set of repositories, documents, records, and secrets. Organization-wide access is convenient, but convenience is not a reason to create an organization-wide incident path.

What can it write?

Separate internal drafts from external actions. An agent that can read sensitive material should not also be able to publish comments, send emails, update customer records, or upload files without a deliberate gate.

Who can trigger it?

Public issues, inbound email, support tickets, uploaded documents, and pasted web content are untrusted input. Treat them as hostile even when they look routine.

Where can its output go?

Map every exit: public comments, pull requests, chat messages, webhooks, logs, and generated artifacts. A private-data control is incomplete if the agent can quietly copy the data into an overlooked output channel.

The operator playbook

The immediate response is not to ban agents. It is to stop deploying them as unusually persuasive scripts with oversized permissions.

Use narrowly scoped credentials. Keep public-input workflows away from private contexts by default. Require human review before sensitive output crosses a trust boundary. Log the original input, retrieved resources, tool calls, and final output. Then test the workflow with hostile instructions before real users do.

GitHub’s access-management guidance makes clear that agent availability and behavior depend on repository and organization policy. Operators need to treat those settings as part of the security architecture, not an administrative detail.

The grounded takeaway is simple: AI agents are becoming infrastructure. Secure them like infrastructure. Define the blast radius, enforce boundaries outside the prompt, and assume every public input will eventually be used to test the limits of the system.