How to Connect GitHub to an AI Agent (2026)

Before any of the setup, one question decides how much of this matters: does your agent need to push code?

Most do not. Triaging issues, replying to a review, labelling, opening a pull request from a branch, summarising a diff — none of that requires the ability to write to a protected branch. Teams tend to grant push access because it is the default shape of a token, not because the use case needs it.

Start from the opposite end. Work out the smallest write the agent genuinely needs, grant that, and widen later if you must. Nobody has ever successfully narrowed a token after people came to depend on it.

What the agent probably needs

In our catalog the operations that come up for a triage or review agent are small and specific:

Notice the last one. It appeared at the top when we searched for "create an issue in a repository," ahead of github.issue.create, because semantic search returns the nearest match and reporting a vulnerability is also creating a report about a problem. They are not the same thing, and one of them notifies maintainers of a security issue.

Which is the practical argument for reading the result before allowing it:

npm install -g swytchcode
swy login
swy init --mode=sandbox

swy get github
swy discover "create an issue in a repository" --project github
swy info github.issue.create        # confirm it is the operation you meant
swy add method github.issue.create  # allow exactly this one
swy auth connect github

An ordering detail worth knowing: swy discover searches the whole catalog, but swy info only works on a provider you have already fetched, so swy get github comes first or info will report a real operation as missing.

Only methods added with swy add method can run. If the agent decides to delete a branch, the call fails at the runtime before a request reaches GitHub. That is an absent capability rather than an instruction the model might reinterpret.

Fine-grained tokens, not classic ones

GitHub offers both, and for an agent the difference is the whole ballgame.

A classic personal access token is scoped by capability across everything the user can reach. Grant repo and you have granted it on every repository that account touches, including the private ones in other organisations.

A fine-grained token is scoped per repository with per-permission settings. For an agent, that means you can grant issue write on one repository and nothing anywhere else. That is a reviewable permission; repo is not.

A GitHub App is the stronger version of the same idea for anything multi-tenant, because installation is per organisation and permissions are declared up front. If your product connects to customers' GitHub accounts rather than your own, that is the route, and the credential architecture behind it is in multi-tenant OAuth for AI agents.

Either way the credential belongs outside your project. With a brokered setup it lives in ~/.swytchcode/credentials.db and is injected when a call executes, so it never enters the model's context and a prompt injection asking for it finds nothing to return. That separation is credential brokering.

Branch and pull request, not push

If the agent does write code, make it open a pull request.

This is not caution for its own sake. A PR is a review gate your team already operates, with CI already attached. Routing agent changes through it means you get the existing safety machinery for free, and you get a diff a human reads before anything lands.

Direct pushes to a protected branch skip all of that, and the recovery story is a force-push and an apology. If the agent must push, push to its own branch, and let branch protection do the rest.

For the operations that genuinely are irreversible — deleting a branch, closing someone else's PR, publishing a release — a threshold rule is better than trust:

{
  "id": "release-guard",
  "target": ["github.issue.create"],
  "when": { "field": "repository", "operator": "in", "value": ["infra", "billing"] },
  "action": {
    "type": "REQUIRES_APPROVAL",
    "message": "Changes to sensitive repositories need approval"
  },
  "approval_timeout": "2h"
}

A rule in version control, evaluated at execution time. The reasoning is in a prompt is not a policy and policy-as-code for AI agents.

Repository content is untrusted input

Worth saying plainly, because it is specific to this integration.

Issue bodies, pull request descriptions, code comments and README files are text that anyone with a GitHub account can write. An agent that reads them is reading attacker-controlled content. If that agent also holds a write credential, an issue filed by a stranger is a path to action.

This is not hypothetical reasoning about models in general; it is the ordinary consequence of letting a public repository's contents reach something that can act. The practical response is the same as everywhere else: narrow what the agent can do, because what it reads is the part you cannot police. Longer version in a security checklist before connecting any AI assistant to company data.

Rate limits punish bursts

GitHub applies secondary rate limits on top of the hourly budget, and they target exactly the pattern an agent produces: a lot of requests in a short window, often against the same endpoint.

An agent asked to triage three hundred open issues will burst, get throttled, retry, and burst again. Two things help: pace the work rather than fanning it out at once, and make sure a 403 with a secondary-limit message triggers a backoff rather than an immediate retry. An agent that retries hard on a rate limit extends its own outage.

Also worth knowing that a retried write here is a duplicate comment or a duplicate issue rather than an error, which is the same class of problem as a retried payment. See idempotency explained.

Keeping a record

swy audit network   # what ran, with status and timing
swy audit policy    # what was denied or held, and by which rule

GitHub's own audit log covers what happened in GitHub. It does not record the calls your agent attempted and was refused, and those are the rows that answer "why did it try to touch the billing repo." The fields worth keeping are in logging every API call an agent makes.

FAQ

How do I connect GitHub to an AI agent?

Create a fine-grained token scoped to the specific repositories involved, or a GitHub App if you are connecting to other people's accounts, then allow only the operations the agent needs. With the Swytchcode CLI: swy get github, swy discover "create an issue in a repository" --project github, swy info github.issue.create, swy add method github.issue.create, swy auth connect github.

What GitHub permissions should an AI agent have?

The narrowest write that makes the use case work, on the smallest set of repositories. Most agent work — triage, labelling, commenting, opening pull requests — needs read plus one or two narrow writes, not push access to protected branches. Grant issue write on one repository rather than repo across an account.

Should I use a fine-grained token or a classic token?

Fine-grained, for an agent. A classic token with repo applies to every repository the account can reach, including private ones in other organisations. A fine-grained token is scoped per repository with per-permission settings, which is something a security review can actually sign off.

Can an AI agent push directly to main?

It can if you give it that, and it is usually the wrong choice. Have it push to its own branch and open a pull request, so your existing review and CI gates apply to its changes the same way they apply to a person's. Branch protection then does the rest.

Is it safe to let an AI agent read GitHub issues?

Reading is low risk by itself, but issue bodies are text anyone can write, so an agent reading them while holding a write credential has a path from reading to acting. Limit what it can do rather than trying to sanitise what it reads.

Why is my GitHub agent hitting rate limits?

Secondary rate limits target bursts of requests in a short window, which is the natural shape of an agent working through a backlog. Pace the work, and make sure a secondary-limit response triggers a backoff rather than an immediate retry, which only extends the block.

How do I audit what an AI agent did on GitHub?

Use GitHub's audit log for what landed, and a log from whatever executed the calls for what was attempted, including refusals. An agent's own chat history is not an audit trail, because it records what the model believed it did and omits the calls that never reached GitHub.

Setup commands come from the Swytchcode CLI docs, and the operation identifiers above were read from the live catalog. GitHub's token types and rate-limit behaviour are described from GitHub's own documentation rather than linked.