Skip to content

Early access Governed MCP calls open to beta partners in March 2027. The MCP tracker and scanner are free to use today.

Join the waitlist

Use cases / Agents on GitHub

A public GitHub issue can talk your agent into leaking private data.

Your agent reads issues anyone can write, and it works with a token that may also open your private repositories. Here is what you can limit in GitHub, and what Stackduke checks.

Join the waitlistWhat Stackduke covers
An agent reads a public issue and a private repository, then calls create_pull_request Two repositories: the public acme/public-site, with an open issue that carries hidden instructions, and the private acme/plans. An Agent reads the issue, then reads a file from the private repository, then calls create_pull_request on the public repository. A Stackduke rule holds pull requests on acme/public-site, so the call stops at the check and waits for a person.PRIVATEACME/PLANSPUBLICACME/PUBLIC-SITESTACKDUKERULE: HOLD PRsON PUBLIC-SITECREATE_PULL_REQUESTWAITS FOR A PERSONAGENT

Why it goes wrong

Anyone can write what your agent reads.

The token decides what your agent can open. The text it reads decides what it tries to do. On GitHub, anyone can write text your agent will read.

Instructions can hide in an issue

Issues, pull requests and files reach the agent as plain text. Anyone who can post in a public repository can leave instructions there.

Source: Invariant Labs, May 2025

One token opens every repository

If one token reaches both public and private repositories, the agent can read from one and write to the other in the same session.

A reviewed pull request can still change

Someone can push a new commit after a pull request is approved. GitHub lets a merge name the exact commit that was reviewed, and refuses the merge if the pull request has moved on.

Source: GitHub's REST API documentation, merge a pull request

What was reported

Private data, posted in a public pull request.

Invariant Labs showed this in May 2025, on agents connected to GitHub’s MCP server.

Source: Invariant Labs, May 2025

  1. 01

    Someone plants an issue

    Invariant Labs opened an issue in a public repository, with instructions for an agent written into it.

  2. 02

    The owner’s agent reads it

    The owner asked their agent to look at the open issues in that repository, and it read this one.

  3. 03

    It opens the private repositories

    Doing what the issue said, the agent took data from the owner’s private repositories.

  4. 04

    It posts the data in public

    It put that data in a pull request on the public repository, where anyone could read it.

With Stackduke

A person reads the pull request before it goes up.

Stackduke checks each call before GitHub sees it. Your rule says any pull request on acme/public-site, your public repository, waits for a person. So the whole pull request, text and all, goes to someone on your team first. Stackduke checks each call on its own, so it does not know the text came from a private repository. The person reading it can see that, and turn it down.

What it covers

What Stackduke covers.

Stackduke

Each MCP call is checked against your rules before it runs.

  • Your agent’s MCP calls go through Stackduke, so each one is checked before it reaches GitHub.
  • Your rules decide each call by agent, tool, repository and what the call contains: let it through, hold it for a person, or block it.
  • A person approves the exact call they saw, and only that call runs.

Free tools

Open source or public, and free to use.

  • The tracker shows what changes in the official MCP servers it follows, including new tools that write.
  • The open-source scanner labels each tool a server offers, so you can see which ones write.

Not covered

Stackduke does not do these. Plan for them another way.

  • Following data from one call to the next. Stackduke checks each call on its own, so it does not link a read from a private repository to a later write to a public one.
  • Scanning issues and files for hidden instructions while the agent works.
  • Managing your GitHub tokens. Set their limits in GitHub, as below.

What you can do now

Limit it in GitHub too.

GitHub has its own settings for this, described in its documentation. We recommend a separate fine-grained token for each agent, read-only unless it needs to write, and one repository per session where your client allows it.

GitHub’s MCP serverSettings for one agent

  1. Personal access token

    type
    fine-grained
    repositories
    only what it needs
    permissions
    only what it needs

    Sign in with a fine-grained personal access token limited to the repositories and permissions the agent needs.

    Source: GitHub's MCP server README

  2. Read-only mode

    /readonlyorX-MCP-Readonly

    Use the read-only mode when the agent only needs to read: the /readonly address or the X-MCP-Readonly header.

    Source: GitHub's remote server documentation

  3. Toolsets

    X-MCP-Toolsetsor/x/<toolset>

    Turn on only the toolsets the agent needs, with the X-MCP-Toolsets header or an /x/<toolset> address.

    Source: GitHub's remote server documentation

Go deeper

Further reading

  • Concept

    How approvals work

    What a person sees when a call waits for them, and what their approval covers.

Let agents work on GitHub. Decide what goes public.

Join the waitlist to try it.

Join the waitlist

Stackduke is not affiliated with or endorsed by GitHub or Invariant Labs. Their names are used here only to describe their products and public reports.