Tokens and Authentication

Every tool call hits the GitHub API with the token you provide. Scoping that token correctly is the first line of defense. You have two main options: a fine-grained personal access token you manage yourself, or short-lived tokens minted by Vercel Connect.

Create a fine-grained token

Fine-grained personal access tokens let you restrict access per repository and per permission category. This is the recommended type for any production assistant.

1. Go to github.com/settings/personal-access-tokens/new
2. Select only the repositories your agent needs
3. Enable permissions based on the preset you plan to use (see matrix below)

Map permissions to presets

Reactions (listIssueReactions, addIssueReaction, listCommentReactions, addCommentReaction) are covered by the Issues permission and need no scope of their own.

repo-explorer and maintainer also include gist read (and, for maintainer, write) tools. Gists aren't tied to a repository. GitHub only grants gist access to GitHub App user access tokens, never installation tokens, so give the PAT the "Gists" account permission separately, and expect gist tools to fail over Vercel Connect (see below).

notification-inbox and maintainer include listNotifications and markNotificationRead. Notifications belong to a user rather than a repository, so they need the "Notifications" account permission on the PAT and, like gists, fail with a Connect-minted installation token.

Releases are covered by the Contents permission on GitHub Apps: repo-explorer, release-manager, and maintainer need no separate scope for listReleases, getLatestRelease, or getRelease.

Mint tokens with Vercel Connect

For agents deployed on Vercel, Vercel Connect replaces long-lived PATs entirely. You attach a GitHub connector (a Vercel-managed GitHub App) to your project, and your server code requests a short-lived, scoped token at runtime, with no secret to store, rotate, or leak.

import { connectGithubTools } from '@github-tools/sdk/connect'
import { generateText } from 'ai'

const { text } = await generateText({
  model: 'anthropic/claude-sonnet-4.6',
  tools: connectGithubTools('github/my-connector', { preset: 'code-review' }),
  prompt: 'Summarize the open PRs on my-org/my-repo.',
})

import { getToken } from '@vercel/connect'
import { createGithubTools } from '@github-tools/sdk'

const tools = createGithubTools({
  token: () => getToken('github/my-connector', {
    subject: { type: 'app' },
    scopes: ['contents:read', 'pull_requests:read'],
  }),
  preset: 'code-review',
})

The provider is invoked at each tool execution, so short-lived tokens stay fresh across a long agent run. Note that in durable workflows the resolved token string is captured in the step arguments. A retried step reuses the token it was first invoked with rather than requesting a new one.

Call getToken per request rather than caching the string yourself. The SDK keeps an in-process cache and refreshes tokens as they approach expiry. For multi-tenant connectors (one connector installed on several GitHub organizations), pass installationId to target a specific installation. When you need a different connector per environment or tenant rather than the same connector with a different installation, connectGithubTools / connectGithubToken also accept a () => string | Promise<string> resolver in place of a connector name, see Vercel Connect: dynamic connector selection.

Why Connect over a PAT

import githubExtension from '@github-tools/eve-extension'

export default githubExtension({ connector: 'github/my-connector', preset: 'maintainer' })

Apply least-privilege step by step

External references

• Fine-grained PAT permissions
• Managing personal access tokens
• Vercel Connect documentation
• Vercel Connect SDK reference