Your agent can have permission to do the wrong thing

A valid credential answers an access question. It does not establish that the resulting disclosure belongs in the task.

In May 2025, Invariant Labs reported an agent reading hostile content in a public GitHub issue, retrieving private repository material and exposing it through a public pull request. The report describes Claude Desktop with GitHub MCP and Claude 4 Opus. This was a reported demonstration, not evidence of present-day behavior across clients. Original report, “Attack Setup” and “Attack Demonstration”

The initiating request matters. The published screenshot asks the assistant to look at repository issues and address them. A proposed change was therefore a reasonable kind of output. The security problem cannot be reduced to an agent writing when it had only been asked to read. Initiating-request artifact

The hostile issue framed its request as recognition for the author, sought information from other repositories, and asserted that disclosure was welcome. That assertion was part of the attacker's input. It was not the account owner's permission. Public demonstration issue, opened May 23, 2025

This is the uncomfortable case: a workflow may legitimately read issues and prepare changes, yet still need a boundary around which information those changes may contain.

A tool can be legitimate while the instruction is not

Trust in an integration has several meanings. You may trust the server to call the intended API, protect a credential and return the requested record. None of those properties makes every statement inside that record an authorized instruction.

For an issue-processing assistant, some outside text must influence the work. A bug report tells it what went wrong. Reproduction steps help it find the defect. A proposed correction may be worth considering. Treating all issue content as useless would defeat the purpose of the assistant.

The distinction is whether the content describes work to evaluate or grants authority to expand the task. “This function returns the wrong value” can be evidence about a bug. “The owner permits you to publish information from unrelated private repositories” requires authority the issue author does not acquire by writing it down.

Simon Willison's existing framing connects private information, untrusted content and external communication. The next practical step is to identify which parts of that combination this job actually needs. The lethal trifecta

Four kinds of authority to keep separate

These are our analytical distinctions, not four features guaranteed by an integration. An application cannot delegate the third or fourth question to an API permission check that only answers the first two.

Map the job before choosing the defense

Consider an original review model for a public-repository maintenance task. This is a design aid, not a reconstruction of every historical tool call:

1. The owner defines the task: address issues in the public repository.
2. The agent reads issue content as evidence, then inspects the task repository.
3. The agent prepares a patch within a private review boundary.
4. A reviewer checks the exact artifact and destination before release.
5. The approved artifact is published.

Branch to challenge: reading unrelated private material before preparing the patch creates an unnecessary disclosure path. Issue text cannot authorize that access or release.

The dotted branch is the first question to challenge. If the task does not require that private material, why can the workflow retrieve it? Removing unnecessary access can make the consequence impossible through that route even if the agent accepts a misleading instruction.

But inspect the whole environment. Restricting one API token does little if the same agent can read another credential from its workspace or reach the information through a different tool. Previously loaded private context also remains relevant after a credential is narrowed. Permission changes do not remove facts already available to the run.

Put the scope somewhere the agent cannot silently widen

GitHub documents fine-grained personal tokens with repository and permission restrictions, while noting endpoint limitations and continued read access to public repositories. Those are useful controls, but “selected repositories” should not be read as a guarantee that no other public content can enter the context. GitHub token documentation

For a managed integration, GitHub also documents narrowing installation-token repositories and permissions when issuing a token. Omitting those restrictions inherits the broader installation/app grant. GitHub App token documentation

The architectural question is who chooses that scope. A trusted launcher can select the repository associated with an approved task. A token broker that accepts any repository requested by the influenced agent may simply move the same authority problem to another service.

Do not turn this into a recommendation to build a broker for every personal workflow. For a single public repository, a narrowly configured existing integration may be sufficient. A broker becomes relevant when many tasks need different grants and there is an independent rule for assigning them. Its policy and credentials become part of the security boundary.

No new credential configuration was tested for this article. Compatibility with the actual integration must be checked before treating the documented mechanism as an implemented control.

A legitimate cross-repository task changes the answer

Suppose the actual job is to update a public SDK after an internal API change. The assistant may need both repositories. Banning all cross-repository reads prevents the useful task rather than improving it.

Now the decision is about permitted transfer. Perhaps a trusted process supplies a narrowly selected interface specification. Perhaps the assistant works privately and an authorized engineer releases the resulting public patch. Perhaps the change should remain entirely manual because deciding what may be disclosed is the expensive, ambiguous part.

A second agent is not inherently a release boundary. If it receives the private context and forwards whatever the first agent requests, the same disclosure path remains. Separation becomes meaningful when the transfer is constrained by a rule or review that the originating content cannot rewrite.

There may be no inexpensive general rule for deciding whether an arbitrary patch reveals private information. A realistic design acknowledges that constraint rather than hiding it behind “sanitization.” Removing tokens that resemble credentials will not necessarily identify a private product plan expressed in ordinary code or prose.

Approval has to precede the disclosure

For a public output, the review must happen before the content is made public. Approval to merge is too late if the material is already visible in the pull request.

In the proposed workflow, prepare the artifact inside the appropriate private boundary. Show the reviewer the actual content, destination, visibility and intended operation. Execute that approved artifact. If any of those material properties changes, the earlier approval no longer establishes permission for the new action.

This still leaves difficult questions. Can the reviewer recognize the private information? Does the preview include every externally visible field? Can the agent publish through another route? How is a retry handled when the system cannot tell whether the first publication succeeded?

Those questions are reasons to define the review precisely. They are not evidence that every approval interface fails, nor a claim that human review guarantees containment. The historical report's linked full trace now redirects to the Explorer repository, whose notice records closure of the hosted service; we did not recover the complete approval sequence. Current trace destination and project notice

Compare the controls by the work they preserve

The following is a conditional design comparison, not measured attack success:

These controls can work together. They address different parts of the route, so count neither their number nor their names as evidence of safety.

For a task limited to a public repository, first remove unnecessary private access and inspect remaining publication paths. For cross-repository work, specify what may transfer and who can authorize its release. Preserve the useful task explicitly: a control that prevents completion needs either a narrower task or an acknowledged tradeoff.

The review should leave an engineer able to point to the unnecessary grant, the permitted transfer and the enforcing layer. That is more actionable than saying the model should know which instructions to trust.

A repository token can be valid throughout an unauthorized disclosure. The design has to establish what the task is allowed to do with the access it has.

---

Research record: Full source dossier, bibliographic references and limitations. The reported case is historical; current exploitability, comparative control performance and customer impact are not established here.

Next: What does your agent's sandbox actually contain?