GitHub Connector Setup & RBAC

The GitHub MCP connector allows agents to read code, create pull requests, and review issues inside designated repositories — without giving the agent broad organisation-level write access.

Setup Variables

• Organization: The target GitHub organization name.
• Repository Allowlist: Restrict agent access to specific repositories by name pattern (e.g. frontend-*, service-api).
• GitHub App Reference: Credentials securely hydrated server-side from the MakeYourMCP vault — the GitHub App private key is never passed to the LLM context.

Why GitHub Needs RBAC in AI Agent Pipelines

Coding agents with unrestricted GitHub access represent one of the highest-risk AI integration patterns. An agent that can push to main, merge PRs without review, or read across all private repositories can: (1) introduce malicious code via prompt injection attacks, (2) exfiltrate proprietary source code through LLM context leakage, and (3) break production deployments if push access is not gated. MakeYourMCP enforces repository allowlists, branch protection rules (requiring human approval for pushes to protected branches), and action-level scoping so agents can only do what their role explicitly permits.

Example RBAC Policy

version: "mcp/v1alpha1"
metadata:
  id: "policy_github_code_review_agent"
  name: "Code Review Agent — Read + PR Comment"

rules:
  - id: "rule_github_read_repos"
    role: "code_review_agent"
    resource: "github_org.repo.frontend-*"
    actions:
      - "read"
      - "list_issues"
      - "list_pull_requests"
    approval:
      required: false

  - id: "rule_github_pr_comment"
    role: "code_review_agent"
    resource: "github_org.repo.frontend-*"
    actions:
      - "create_pr_comment"
    approval:
      required: false

  - id: "rule_github_block_push_to_main"
    role: "code_review_agent"
    resource: "github_org.repo.*.branch.main"
    actions:
      - "push"
      - "merge"
    effect: "deny"

Common Pitfalls

• Using a personal access token instead of a GitHub App: Personal access tokens give an agent the same permissions as the individual developer — including all private repos they can access. Always use a GitHub App with narrowly scoped installation permissions so access is bounded to the specific repositories the agent needs.
• No deny rule on protected branches: Without an explicit effect: "deny" rule onmain and release/*, a sufficiently creative agent might find a code path to push directly. Defense in depth means both an MCP policy deny AND native GitHub branch protection rules.
• Allowing read access to all private repos: Scope the repository allowlist to the specific projects the agent needs. A wildcard * on the org allows the agent to read confidential roadmap, compensation, and security repositories alongside the repos it legitimately needs.

See Also

• PostgreSQL Connector Setup Guide — database access for data-driven code agents
• Slack Connector Setup Guide — post PR summaries and alerts to Slack
• Salesforce Connector Setup Guide — CRM integration alongside code agents
• Snowflake Connector Setup Guide — analytics alongside engineering agents
• Policy YAML Schema Reference — full policy declaration specification
• Full Documentation Index
• Securing the Model Context Protocol — supply-chain threat vectors for coding agents
• MakeYourMCP Security & Trust Center — full security architecture overview

← Back to documentation index