docs: changelog for service accounts and GitHub Actions OIDC sign-in

src/content/changelog/api-key-scopes-every-plan.md

@@ -12,4 +12,4 @@ API keys limited to releases and patches are now available on every plan,
 including Free. They used to need a paid plan.
 
 - The console no longer disables the "Release and patch only" option on the Free
-  plan, for personal API keys or for service account keys.
+  plan. A service account's keys take no scope. They do what its role allows.

src/content/changelog/github-actions-oidc.md

@@ -0,0 +1,26 @@
+---
+title: Sign in from GitHub Actions without a stored key
+date: 2026-10-16
+version: 1.6.129
+area: CLI
+type: New
+docLink:
+  label: Sign in with OIDC instead of a stored key
+  href: /code-push/ci/github/#sign-in-with-oidc-instead-of-a-stored-key
+---
+
+On GitHub Actions, the CLI can now sign in as a service account with the OIDC
+token GitHub issues to each job, so there's no `SHOREBIRD_TOKEN` secret to leak
+or rotate.
+
+- Add a trust rule to a service account naming the repository, the workflow
+  file, and optionally a GitHub environment and a ref pattern. Only jobs that
+  match sign in.
+- In the workflow, grant the job `id-token: write` and set
+  `SHOREBIRD_PROJECT_ID`.
+- Adding a trust rule needs a Business or Enterprise plan. Existing rules keep
+  working after a downgrade.
+- When `SHOREBIRD_TOKEN` is set, the CLI uses it instead, so remove the secret
+  once the workflow signs in with a trust rule.
+- On the Enterprise plan, each sign-in is recorded in the audit log as
+  `service_account.sign_in`, with the run it came from.

src/content/changelog/service-accounts.md

@@ -0,0 +1,25 @@
+---
+title: Service accounts for CI and integrations
+date: 2026-10-15
+area: Console
+type: New
+docLink:
+  label: Service accounts
+  href: /account/service-accounts/
+---
+
+Organizations can now create service accounts: accounts that belong to the
+organization instead of a person, with keys that keep working when the person
+who set them up leaves or changes roles. They're available on every plan.
+
+- Each service account holds one role: Viewer, Developer, App Manager, or
+  Auditor. Its keys do what that role allows. A service account can't be an
+  Admin or Owner.
+- Keys expire after 1 year by default, or choose 30 days, 90 days, or never.
+- The audit log shows a service account's actions as its name followed by
+  `[bot]`, such as `GitHub Actions[bot]`, along with the key or trust rule it
+  used.
+- The new Auditor role reads the audit log and nothing else, for exporting it to
+  a SIEM without an Admin's key. The audit log needs the Enterprise plan.
+- The Owner and Admins manage service accounts, which don't appear on the
+  Members page.