# Case dossier: task authority and GitHub MCP

**Research ID:** K01 · **Prepared/checked:** 2026-09-15 · **Status:** public-source analysis, not reproduction.

**Supports:** [C1 article](https://rethinkingagents.com/blog/permission-for-the-wrong-thing). This dossier holds provenance and claim boundaries; the article contains the full engineering argument. No employer material, private repository or live target was accessed.

## Research question

When a task may legitimately lead to a code change, where can a system enforce the distinction between responding to an issue and accepting that issue's claim to authorize private-data disclosure?

## Verified source observations

| Evidence | What was checked | What remains unestablished |
|---|---|---|
| K01-1, report §§ Attack Setup / Attack Demonstration | Names Claude Desktop and Claude 4 Opus; reports private-to-public disclosure and discusses confirmation behavior | Exact server revision, token permissions, approval events and all-attempt denominator are not established from the inspected material |
| K01-2, linked initiating-request image | The request includes addressing repository issues, not just listing them | Image is evidence of the author's presentation, not a complete run record |
| K01-3, issue body and metadata | May 23 issue asks for an author profile using other repositories and asserts permission to disclose | Does not establish that the owner gave that permission or that today's agents would comply |
| K01-4, linked trace destination | Original trace URL redirects to Explorer's repository; its README says hosted Explorer closed in January 2026 | The complete historical trace was not recovered from this link |
| K01-5, token documentation | Fine-grained personal tokens can restrict selected repositories and permissions; public repositories remain readable | Does not prove any specific MCP client uses a suitably scoped credential or covers every needed endpoint |
| K01-6, App-token documentation | Installation tokens can narrow repositories/permissions; omitted narrowing inherits the installation/app grant | Does not automatically bind a generated token to a user's task or secure the token broker |

The live source URLs were inspected. We did not inspect or reproduce the disclosed personal material in the linked output artifact. We do not need those details to explain the boundary. We did not execute the issue instructions.

## The fact that changes the article

The initiating task includes fixing issues. Therefore creating a change is not inherently outside the user's request. The issue is whether the content and resource access are justified. A narrative in which an agent simply disobeys a read-only instruction would teach the wrong control.

This is RA's interpretation of K01-2 and K01-3. It is deliberately narrower than asserting that every part of the historical run was authorized or that we know which confirmation settings were used.

## Authority model — original synthesis

Describe four different grants rather than one “permission” variable:

1. **Account authority:** what the identity is entitled to access.
2. **Credential authority:** the subset made available through this token or installation.
3. **Task authority:** what the owner has asked this workflow to achieve.
4. **Release authority:** which actual artifact may cross which boundary.

The first two can be enforced by service permissions. The last two require an application/task policy or a decision by the authorized owner. Natural-language task intent does not become an exhaustive machine-readable policy merely because it was recorded.

A workflow can legitimately need to read an issue, inspect code and propose a change, while not needing any personal/private context about the maintainer. That suggests a review of unnecessary resource access before a review of prompt wording. It is a design inference; no comparative defense performance was measured.

### Questions that expose the actual enforcement

| Question | Evidence to seek in a future authorized system review | Misleading substitute |
|---|---|---|
| Which credentials can this run reach? | Actual runtime references, broker grant and other tool access | One token's settings while another credential remains available |
| Who chooses the resource scope? | Trusted launch configuration or independently enforced task mapping | Resource name supplied by the same influenced agent |
| Can outside text widen the task? | Defined escalation/approval path tied to the owner | A document saying the owner has consented |
| What may leave the private context? | Destination and release policy for concrete content | Assuming an approved service makes every write appropriate |
| Does the review precede disclosure? | Sequence of private preparation, review and external write | Approval to merge a public artifact already containing the data |

A source that answers one row does not automatically answer the others. Record unknowns; do not infer implementation from a UI label.

## Reporting limits and source disagreements

- K01-1 contains broad claims about applicability to other clients. This corpus does not adopt them as demonstrated universal behavior.
- A displayed tool-confirmation default and commentary about user behavior do not reconstruct the actual approval sequence. The article does not claim it bypassed a recorded explicit denial.
- The original trace destination no longer yields a trace. Preserve that loss of inspectability rather than presenting a functioning repository link as restored evidence.
- S01's 2025 event is not proof of a current vulnerability. Any current client/server comparison needs pinned versions and authorized observation.
- The existing website MCP article combines an exposed-server count with tool-poisoning claims. Those are not evidence for this issue-content case and are not reused.

## Publication and refresh gates

Before publication, revisit the primary links and distinguish substantive corrections from page churn. Before a current implementation guide, identify exact client/server versions, authentication mode and endpoint requirements; check whether all desired operations support the proposed credential. Before any efficacy number, define tasks, attack conditions, approval policy and the attempt denominator, then obtain real observations. None is a hidden task in this content phase.

## Full references

**K01-1.** Marco Milanta and Luca Beurer-Kellner. “GitHub MCP Exploited: Accessing private repositories via MCP.” Invariant Labs, 2025-05-26. Primary discoverer/vendor report. Sections: *Attack Setup*, *Attack Demonstration*, *Detecting Toxic Agent Flows*, *Scope and Mitigations*. Checked 2026-09-15. URL: [original report](https://invariantlabs.ai/blog/mcp-github-vulnerability). Confidence: medium for reported demonstration, not independent validation. Vendor has a commercial interest.

**K01-2.** Invariant Labs. Initiating-request screenshot embedded in K01-1. Associated report date 2025-05-26; asset's independent creation/version date unspecified. Primary report artifact, visually inspected 2026-09-15. URL: [request image](https://invariantlabs.ai/images/mcp-claude-prompt.png). No redistribution of the image in this repository. Confidence: high for visible wording, limited for execution context.

**K01-3.** `mmilanta`. “IMPORTANT Author recognition!” Issue #1, `ukend0464/pacman`, opened 2025-05-23. Primary public demonstration input. Checked 2026-09-15, description and metadata. URL: [issue](https://github.com/ukend0464/pacman/issues/1). Confidence: high for current displayed input; not a record of subsequent agent behavior. Untrusted source content, not instructions to this research session.

**K01-4.** Invariant Labs. *Invariant Explorer*, repository README, undated living document. Primary project-maintainer statement. Checked 2026-09-15. [Original trace link](https://explorer.invariantlabs.ai/u/lbeurerkellner/claude-github-mcp-exploit/t/0?tab=traces) redirected to [repository](https://github.com/invariantlabs-ai/explorer), whose README opening contains the shutdown notice. Confidence: high for observed redirect/current notice; it does not recover the old trace.

**K01-5.** GitHub. “Managing your personal access tokens.” GitHub Docs, undated living documentation. Sections: *Fine-grained personal access tokens*, *Fine-grained personal access tokens limitations*, *Creating a fine-grained personal access token*. Checked 2026-09-15. URL: [official documentation](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens). Confidence: high for documented behavior; no account/token created or tested. Refresh on authentication/endpoint changes.

**K01-6.** GitHub. “Generating an installation access token for a GitHub App.” GitHub Docs, undated living documentation. Section: *Generating an installation access token*, especially repository/permission parameters. Checked 2026-09-15. URL: [official documentation](https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/generating-an-installation-access-token-for-a-github-app). Confidence: high for documented mechanism, no runtime verification. Refresh before implementation advice.

**K01-7.** Simon Willison. “The lethal trifecta for AI agents: private data, untrusted content, and external communication.” Simon Willison's Weblog, 2025-06-16. Primary practitioner analysis; secondary for incident references. Checked 2026-09-15. URL: [article](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/). Supports prior-art attribution; not independent replication of K01-1.