Provenance Record

Clear News piece with sectioned structure (Overview, New Permissions, Repository Administrators and Approved Apps, Tokens/App Visibility/Credentials, Availability, What We Don't Know). Body 682 words raw and 682 with link URLs stripped (News range 400-1200). Title is 145 characters (counted programmatically; cap 150). No violations. No internal links: all links point to github.blog or docs.github.com (confirmed).

Snapshot check: manifest lists 3 sources, all status 200, file present, suspicious_patterns null for all. Decompressed and text-extracted each. source-0.html.gz (github.blog changelog 2026-10-13, full page body present): the entire changelog body (from 'We're releasing several GitHub Apps improvements today...' to 'Let us know what you think') was compared to a live curl fetch of the same URL on 2026-10-14 and is IDENTICAL, so the changelog has not changed since the snapshot. Verified against it: opening quote 'releasing several GitHub Apps improvements today that help developers move off of classic PATs, improve GitHub App management, and request fewer sensitive permissions' (verbatim); 'Two new repository fine-grained permissions have been added, available to both fine-grained PATs and GitHub Apps' (verbatim), which supports the title's 'for Apps and PATs' for BOTH permissions; repository_creation:write appears verbatim twice; installation_repositories appears once as 'installation_repositories: write' (with a space, in the permission list) and once as 'installation_repositories:write' (no space, in the API section); the title and article use the no-space form, which matches the changelog's own second usage and the canonical permission-name format, so acceptable; repository_administration:write was previously needed to create a repo and 'That permission also grants other repository administration features like deletion and transfer' (verbatim); creator is given access; 'An app using this permission still requires an organization administrator to install the app' (verbatim); the Add a repository to an installation org-level API and its removal API now support GitHub Apps and fine-grained PATs, previously only the coarse-grained repo scope; permission on a repository allows add/remove from any installation in the org; user callers must also be an org owner or administrator on the repository; 'Repository administrators can now edit an existing installation to add their repositories to an app without requiring organization owner approval' (verbatim); historical block of org-level-access apps and relaxation when the app is already installed in the org (approved by an organization owner); three sensitive permission sets (all organization-level permissions, Repository administration, Repository creation) requiring owner approval; pointer to 'Restricting GitHub App Installation to Organization Owners'; offline_access like OAuth apps, refresh token in addition to expiring access token, 'This is available in GHES 3.23'; Get an app API access patterns (same org regardless of visibility, internal apps within same enterprise, enterprise-owned app can fetch org-owned apps in that enterprise); dedicated Credentials tab 'sets aside space for our upcoming workload federation credentials' (verbatim); 'These improvements will be available in GHES 3.24, with the exception of offline_access support, which will be included in GHES 3.23' (verbatim). The changelog gives no rollout schedule, plan limits or defaults for GitHub.com, as the article states. source-1.html.gz (docs.github.com Refreshing user access tokens; real page body present, not a shell): contains verbatim 'When you request offline_access, you will receive an expiring user access token and a refresh token even if your app is configured not to use expiring user access tokens.' Confirmed. source-2.html.gz (docs.github.com permissions required for fine-grained PATs; full reference tables present): contains sections 'Repository permissions for "Repository creation"' (POST /orgs/{org}/repos, POST /repos/{owner}/{repo}/forks, etc.) and 'Repository permissions for "GitHub App installation repository access"' (PUT/DELETE /user/installations/{installation_id}/repositories/{repository_id}). The strings repository_creation and installation_repositories do NOT appear in this snapshot, as the writer disclosed; the article only claims two sections with those headings exist and 'correspond' to the permissions, which is a reasonable inference from endpoint content but is the writer's inference, not an explicit docs statement (minor; the docs list the user-level /user/installations path rather than the org-level API the changelog describes). No snapshot failed or was a shell; no live fallback was needed except the identical-content freshness check on the changelog.

All claims map to the changelog or docs snapshots and are attributed to GitHub ('the changelog says', 'GitHub says'). Title: 'for Apps and PATs' is supported for both permissions by 'available to both fine-grained PATs and GitHub Apps'. 'Saying Repo Admins Can Add Approved Apps' is supported by the changelog heading 'Repository administrators can more easily add approved GitHub Apps to repositories' and the body statement; 'approved' means approved by an organization owner for the org-level access (app already installed in the org), which the article body explains, including that three sensitive permission sets still need owner approval. The title is compressed but not misleading given the body qualification. The 'What We Don't Know' absence claim about auditing is acceptable (the changelog mentions only that the Get an app API 'enables organizations and enterprises to automate more of their GitHub App auditing and administration'). Freshness: changelog dated Oct 13, 2026, read Oct 14, 2026.

Accurate, well-attributed, correctly sized, sourced from allowlisted first-party domains (github.blog and docs.github.com already on the allowlist; no allowlist changes needed). Pattern scan clean. Signature and hash valid. APPROVE.