GitHub's AI Agent Leaks Private Repos via Prompt Injection

GitHub's AI coding agent will expose private repository contents when a user simply asks it to, according to a security disclosure published today. The attack requires no exploit code, just a conversational prompt, which makes this a textbook authorization failure at the agent layer.

Why it matters

This is not a traditional data-breach vector. The user is already authenticated. The problem is that the agent conflates "user is logged in" with "user may read any repo the agent can access." That is a scope-collapse bug, and it is endemic to how most agent systems are built right now.

"If your agent can read it, assume a motivated user will eventually ask for it."

For teams shipping LLM features on top of GitHub, internal tooling, or any data store, this is the concrete proof-of-concept that has been missing from the "agents are risky" conversation. Signal source

What changes in practice

• Authentication is not authorization. An agent acting on behalf of a user should only access the resources that user is explicitly permitted to access in the current session scope, not everything the agent's service account can touch.
• Conversational framing bypasses intent filters. Asking "nicely" is enough because most agents do not have adversarial-input classifiers on outbound data, only on inbound instructions.
• Private data in context is private data at risk. Any time an agent loads repo contents, file trees, or secrets into its context window, that data is one prompt away from being surfaced.
• Tool-level scoping is the missing control. If the GitHub integration tool returns full file contents by default, no amount of system-prompt instruction will reliably prevent leakage under adversarial prompting.

This sits alongside a broader pattern of agent security issues surfacing as agentic products move from demos to production.

How to use it

1. Audit every tool your agent can call. List what data each tool can return and ask whether the current user should be able to receive that data in all cases.
2. Apply least-privilege at the tool level, not just the API level. Scope tokens and credentials to the minimum required for the task, not for the agent's full operational envelope.
3. Add output classifiers for sensitive patterns. Before the agent returns a response, run a lightweight check for repo names, file paths, secrets patterns, and PII that should not be in scope.
4. Test your own agents adversarially. Ask them directly for data they should not have. If they comply, your authorization layer is in the agent's prompt, not in your infrastructure, and that is not a real boundary.
5. Follow prompt injection mitigations for any agent that ingests user-controlled content alongside privileged data, since the two attack surfaces compound each other.

The disclosure is a gift: it is a low-complexity, high-clarity example you can use to justify hardening work to stakeholders who still treat agent security as a theoretical concern.

If your agent has access to sensitive data, treat every user as a potential adversary and enforce authorization at the tool boundary, not in the system prompt.