run_5bd2530a653379d4

input

{
  "request": "Triage Jira ticket MZCLD-3792: Fine-grained tokens policies",
  "references": [
    "https://mozilla-hub.atlassian.net/browse/MZCLD-3792"
  ],
  "sourceContext": {
    "issue": "MZCLD-3792"
  }
}

summary

MZCLD-3792 is a Backlog ticket questioning whether the current GitHub fine-grained personal access token (PAT) policy — which routes any fine-grained token request scoped to a Mozilla-owned repository to GitHub admins for approval — is still the right approach, or whether it should be revised. There is no linked runbook/design doc, no comments, and no assignee activity yet, so this is an open policy question needing discussion/decision rather than an active bug or incident.

findings

• Ticket is a policy question, not a bug/incident: it asks whether the existing approval-required workflow for fine-grained GitHub tokens accessing Mozilla repos still makes sense.
• Ticket has had no engagement since creation — no comments, status remains Backlog — suggesting it needs to be routed to whoever owns GitHub org admin policy for a decision.
• No linked Confluence runbook or design doc was referenced in the ticket, so there's no existing documented policy to validate against within this ticket; any prior policy rationale would need to be sourced from GitHub org settings or a separate internal doc not linked here.

proposed actions

Thanks for flagging this. To move this forward, could we clarify a few things:

1. Current state: GitHub's fine-grained PAT approval requirement for org-owned repos is an org-level security setting (Settings > Personal access tokens > Fine-grained token policies) that requires admin approval by default. This is intentional — it gives admins visibility/control over which tokens can access which repos, which classic PATs don't provide.
2. Question to resolve: is the friction (admins having to review/approve each request) worth the security benefit, or is it causing enough delay/toil that we should consider alternatives (e.g., pre-approving specific repos/orgs, delegating approval to a subset of admins, or setting an expiration-based auto-approval for low-risk repos)?
3. Suggested next step: pull recent approval request volume/turnaround time from GitHub org audit log to quantify the actual burden before deciding to loosen the policy. If volume is low, current policy is likely fine as-is; if it's a bottleneck, we can scope a policy change (e.g., allow auto-approval for public/non-sensitive repos while keeping manual review for repos with secrets or elevated permissions).

Recommend keeping this in Backlog until we have approval-volume data, then revisit as a small policy-change task. Please assign to whoever owns GitHub org security settings (Cloud Ops/IT) for the audit-log pull and decision.

tool calls

[
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3792"
    },
    "result": {
      "key": "MZCLD-3792",
      "summary": "Fine-grained tokens policies",
      "status": "Backlog",
      "description_text": "Currently if you try and create a fine-grained token with access to a Mozilla repository it sends a request to the GitHub admins. Does this make sense to do still? Or should we make changes to this policy?",
      "comment_count": 0,
      "comments": []
    }
  }
]

log