Recommendation
Use a pull_request_target GitHub Action that runs only when an authorized human issues a explicit trigger (e.g. a comment `/summarize` or a specific label). The workflow must never execute untrusted code from the PR itself, must use the least-privileged GITHUB_TOKEN permissions, and must funnel any external AI requests through a hardened backend (or use an approved first‑party Copilot integration) so secrets and code leaves the runner only in controlled ways.

Why this pattern
- pull_request_target lets the Action run code from the base branch (trusted) so you can enforce logic that validates the commenter and request. Do NOT checkout PR code from the PR branch or run arbitrary workflows from the PR.
- Explicit-trigger + commenter authorization controls noise and prevents automated spam summaries.
- Proxying AI calls through your backend or a GitHub App enables audit logging, short‑lived credentials, and DLP controls rather than storing API keys in the repo.

Decision criteria (when to choose which option)
- Use GitHub Copilot (native) when: your org already has Copilot for Business and you want the simplest integration and are comfortable sending diffs to GitHub. Budget: moderate; Privacy: medium.
- Use an external LLM (ChatGPT or private model) via your backend when: you need fine data governance, audit trails, or on‑prem inference; team size is large or compliance requires no third‑party code access. Budget/ops overhead: higher.
- Use self-hosted runner when: you must keep code in your VPC or disallow outbound traffic from CI.

Practical checklist (concrete steps)
1) Trigger and validation
- Trigger: workflow_dispatch or issue_comment with expected command (e.g. `/summarize`).
- Validate commenter: call GET /repos/:owner/:repo/collaborators/:username or org membership API to ensure commenter is a member/maintainer.
- Optionally require a repo label (e.g. `ai-summary-ok`) for automation.
2) Use pull_request_target and avoid checking out untrusted code
- Use pull_request_target so your workflow code is sourced from base branch (trusted).
- Do NOT run actions/checkout on PR head. Instead fetch diffs via the REST API: GET /repos/:owner/:repo/pulls/:number/files or /repos/:owner/:repo/compare/:base...:head to assemble changed hunks.
3) Least-privilege permissions
- Set workflow permissions at top: permissions: contents: read, issues: write (for comments), pull-requests: read. Avoid repo:write or secrets access.
4) AI call controls
- Route prompts to an internal backend service that: authenticates via OIDC or GitHub App, strips secrets and large blobs, enforces rate limits, logs requests and responses.
- If you must call Copilot or ChatGPT directly, keep keys out of repo and use GitHub Secrets with restricted access; prefer short‑lived tokens / OIDC where supported.
5) Post result and metadata
- Post summary as a PR comment and include provenance: model used, prompt (sanitized), timestamp, and author (bot name). Allow maintainers to edit or dismiss.
6) Audit & opt-out
- Keep an allowlist of repos/teams that may auto-summarize. Provide an opt-out label or config file (.github/ai-summary.yml) to disable per-repo.

Best-for / Avoid-if
- Best-for: teams who want controlled, on-demand PR summaries without auto-noise and who can enforce commenter membership.
- Avoid-if: you require automatic summaries for every PR from forks with zero human gating (hard to do securely) or cannot run any outbound requests.

Tools
If you already use GitHub Copilot for Business, integrate via an approved backend or GitHub App (cta: github-copilot). For alternatives or greater control, use an internal ChatGPT/OpenAI proxy.

If you want, I can draft a minimal YAML workflow and the small Node/Python script that: validates commenter, fetches diffs, sanitizes, and posts the summary as a PR comment.

Compare GitHub Copilot and Cursor