What Happened
Noma Security discovered GitLost, a prompt injection attack exploiting GitHub's preview Agentic Workflows to leak private repository data. The attack is simple: an attacker submits a crafted GitHub issue to a public repository. When the AI agent processes that issue, it follows embedded instructions to access and leak sensitive data from private repositories the agent can read.
This attack doesn't require compromising credentials or exploiting a traditional vulnerability. It manipulates the AI agent's decision-making process through natural language instructions hidden in a seemingly legitimate issue report.
Timeline
The specific timeline of GitLost's discovery hasn't been disclosed, but the attack pattern follows a predictable sequence:
- Attacker identifies a target organization using GitHub's Agentic Workflows.
- Attacker crafts a GitHub issue containing prompt injection instructions.
- Attacker submits the issue to a public repository monitored by the AI agent.
- AI agent processes the issue and executes the embedded instructions.
- Agent accesses private repository data it has legitimate permissions to read.
- Agent exfiltrates that data according to the attacker's instructions.
This can happen within minutes of issue submission, with no alerts triggering because the agent is performing actions within its granted permissions.
Which Controls Failed or Were Missing
The GitLost attack reveals three critical control failures:
No input validation for AI agent prompts. The AI agent processed external input from public GitHub issues without sanitizing or validating the content for malicious instructions. This is like running user-supplied code without inspection.
Overly permissive agent access. The AI agent had read access to private repositories when it only needed access to process public issues. This violates the principle of least privilege. The agent's permission scope didn't match its actual job function.
Missing trust boundary enforcement. The system treated external, untrusted input (public GitHub issues) the same as internal, trusted commands. There was no architectural separation between the agent's public-facing interface and its access to sensitive resources.
What the Standards Require
OWASP ASVS v4.0.3 Requirement 5.3.8 states: "Verify that the application protects against Server Side Request Forgery (SSRF) attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields." While this focuses on SSRF, the principle applies to AI agents: validate untrusted input before it influences system behavior.
ISO/IEC 27001:2022 Control 8.3 requires organizations to restrict access rights according to the principle of least privilege. An AI agent processing public issues doesn't need read access to private repositories. If your agent has broader permissions than its function requires, you're out of compliance.
NIST 800-53 Rev 5 Control AC-3 (Access Enforcement) mandates that systems enforce approved authorizations for logical access. This includes ensuring that subjects (AI agents) only access objects (repositories) according to an approved security policy. An AI agent that can be tricked into accessing resources it shouldn't is failing access enforcement.
NIST 800-53 Rev 5 Control SI-10 (Information Input Validation) requires checking the validity of information inputs. For AI agents, this means implementing guardrails that prevent prompt injection attacks from overriding intended behavior.
Lessons and Action Items for Your Team
Audit your AI agent permissions today. List every AI agent, bot, or automation tool in your environment. Document what each one can access. Then ask: does it need that access to do its job? If your GitHub bot can read private repos but only needs to triage public issues, revoke that access immediately.
Implement strict input validation. Treat every external input to an AI agent as potentially malicious. This means:
- Strip or escape special characters and formatting.
- Implement allowlists for acceptable input patterns.
- Use separate processing pipelines for trusted vs. untrusted input.
- Never pass raw external content directly to an AI agent's decision-making layer.
Enforce trust boundaries at the architecture level. Design your AI agent deployments with clear separation between untrusted and trusted zones. An agent that processes public input should not have direct access to sensitive resources. If it needs information from private repos, it should request that data through an intermediary service that validates the request against a policy.
Monitor AI agent behavior. Set up logging that captures:
- What external inputs the agent received.
- What internal resources it accessed.
- What data it transmitted externally.
- Any unusual access patterns or permission escalations.
Configure alerts for agents accessing resources outside their normal behavior profile.
Document your AI agent trust model. Write down which agents can access what resources and why. Include this in your security documentation and review it quarterly. When you add new AI capabilities, explicitly define trust boundaries before deployment.
Test your agents with adversarial inputs. Before putting an AI agent into production, try to trick it. Submit inputs designed to make it leak data, access unauthorized resources, or behave unexpectedly. If you can manipulate it, so can an attacker.
The GitLost attack shows that AI agents aren't just tools; they're potential attack vectors. Noma Security's research highlights that AI agents can become unintended bridges between untrusted external content and sensitive internal resources. Your compliance posture depends on treating them as such and implementing controls accordingly.
If you're running AI agents with access to sensitive data, address this now. The attack pattern is public, the technique is straightforward, and the impact is direct data exfiltration. Don't wait for your incident response team to learn about this the hard way.
