This week at a glance
The through-line this week is that the question in CI/CD has moved from “what code runs” to “who is allowed to make it run”. GitHub made its workflow execution protections generally available on 17 September after a preview that opened in June, and DevOps.com’s write-up on 21 September puts the date that matters in front of everyone: enforcement of the new default pull_request_target restrictions begins on 2 November. Rules now target specific workflow files rather than whole repositories, actor rules can name individual users, repository roles, GitHub Apps, Copilot and Dependabot, and an evaluate mode lets an admin see what a policy would block before it blocks anything. On the same day GitHub gave Enterprise Cloud customers a credential inventory export covering SSH keys, classic and fine-grained personal access tokens, OAuth app tokens and GitHub App credentials, each with owner, scopes, dates and a last-used timestamp. Read together, the two releases put the control surface where GitHub is now betting on it, with the pipeline incidents the piece cites — tj-actions/changed-files, Nx and trivy-action — as the backdrop: the identity behind the run and the credential it held.
The second thread is guardrails around the coding agent itself, and it runs in two directions. Inward, tools are putting gates in front of what an agent may do: Gemini CLI 0.61.0 now requires confirmation before the agent edits build configuration files, before it runs build or test commands after such an edit, and before shell commands whose arguments came from untrusted content such as web search results or MCP server responses; Prismor, a free open-source layer, checks each tool call from Claude Code, Codex or Cursor against policy and scores npm and pip installs before they happen. Outward, the question is what the tool vendor takes: Z.ai found its ZCode product had been packaging entire user workspaces — full project histories included — and uploading them to Alibaba Cloud without consent. The company says the data has been deleted and has open-sourced the product; neither the deletion nor the commissioned audit has been independently verified.
Around those two threads, the tooling stack for directing agents is filling in. JetBrains announced JetBrains Air on 22 September, bundling an agentic IDE experience, Air Teams for workflows that mix developers and agents, and Air Governance — the renamed JetBrains Central — for policy, audit and cost. Lovable’s OJ rewrites only Vite’s dev-server layer in Rust, and Lovable reports it using 115 MB of memory against 1,751 MB for Vite’s bundled mode on a 10,000-component test app. The human side of the same shift runs through the index: a survey in which 47% of roughly 12,000 employees said they now spend more time directing AI than doing the work, and a separate figure that only 17% of those whose roles changed were promoted. For the security programme the practical output of the week is a checklist: Mandiant’s CI/CD hardening guidance, which is worth reading as the control list the GitHub features plug into.
On our watch list
- Whether 2 November breaks pipelines that relied on
pull_request_target. GitHub’s new default restrictions begin enforcing that day. Evaluate mode exists so admins can see what a policy would block first; the signal to watch is how many organisations run it before the date rather than after the first failed build.
- Whether actor rules get used to separate human and bot runs. Rules can now name Copilot and Dependabot alongside individual users, repository roles and GitHub Apps. Watching whether organisations start treating automated actors as a distinct class with narrower workflow rights, and whether the new REST API gets wired into policy-as-code.
- When the credential inventory reaches GitHub Enterprise Server. Support is planned and no date has been given. Until it ships, self-hosted customers have no equivalent export of keys and tokens with last-used timestamps.
- Whether the credential export becomes a daily control or a one-off audit. The Futurum Group’s Mitch Ashley argues that pulled daily through the API and compared run-over-run, it becomes an operating control. Watching for the first published practice of diffing it and revoking on drift.
- Whether Z.ai publishes the CAICT and NSFOCUS audit. Z.ai commissioned both to audit ZCode and says previously uploaded data has been deleted. No audit report has been published. Watching for the report, and for the ongoing vulnerability reporting and response process the company says it will establish.
- Whether Gemini CLI’s confirmation gates carry over to Antigravity CLI. Google announced at I/O in May that Gemini CLI is migrating to Antigravity CLI. The 0.61.0 build-file and untrusted-input confirmations are the behaviour to check for in the successor. The release does not address last week’s Plugin4Shell pinned-plugin issue.
- Whether Prismor’s numbers hold outside simulated sessions. The project reports 0.8 milliseconds of overhead per tool call and a 30% higher prompt-injection catch rate from its optional semantic guard across 800+ test cases. Both are the project’s own benchmarks. Watching for independent measurement on real agent workloads.
- What JetBrains Air actually costs and supports. The announcement gives no pricing, availability dates or supported-agent list. Air Governance, the renamed JetBrains Central, is the piece a security team will want to evaluate; watching for what its audit trail records.
- Whether a seven-day release cooldown becomes a default anywhere. Mandiant recommends that newly published public package versions not be installable for at least seven days. Watching whether package managers, proxies or CI templates start shipping it as a setting rather than leaving it to policy.
- What Security Slam 2026 produces. The OpenSSF and CNCF event runs 5 October to 6 November, culminating at KubeCon + CloudNativeCon North America. Watching for the count of projects that close security findings during the window.
This week’s topic map — the pipeline cluster at the upper left around GitHub, GitHub Actions, workflow execution protections, the pull_request_target defaults and the 2 November enforcement date, actor rules for Copilot, Dependabot and GitHub Apps, and the credential inventory export for GitHub Enterprise Cloud with personal access tokens and SSH keys; the Mandiant hardening cluster across the top with digest pinning, ephemeral runners, OIDC federation, signed SBOMs, the seven-day release cooldown and the six-stage scanning gate; the agent-guardrail cluster through the centre around AI coding agents, Gemini CLI 0.61.0, build-file confirmation, prompt injection, the Model Context Protocol, agent sandboxing and Prismor’s allow/warn/block verdicts and install risk scoring; the ZCode cluster at the left with Z.ai, the undisclosed workspace upload, Alibaba Cloud, Ferstar, NSFOCUS and the CAICT audit; the tooling cluster below with JetBrains Air and Air Governance, and to the right Lovable’s OJ, Vite and cheaper forking; the developer-role cluster at the bottom around managing agents, code review, the end of coding by hand and tech layoffs; and the commons cluster at the upper right around OpenSSF, the open-source supply chain, Security Slam, CNCF, KubeCon and the GDS open-by-default guidance.
View interactive topic map →
Article index
Who may run the pipeline
Identity, credentials and policy are becoming the CI/CD control surface. GitHub now lets organisations say which actors may run which workflow files and export every credential with a last-used date, and Mandiant published the control list to put around both.
Guardrails around coding agents
What the agent may touch, and what the tool vendor itself takes. One release adds confirmation gates, one open-source project adds a policy check on every tool call, and one vendor apologised for uploading entire user workspaces without consent.
The new agent tooling stack
IDE makers, model builders and individual engineers are all building the layer that directs, coordinates and governs coding agents — and the cost of forking a large open-source project has dropped far enough that a Rust rewrite of a dev server is now a product decision.
What AI coding is doing to the developer’s job
Directing agents is turning into the job, and the review queue is where the work lands. The pieces in this group range from one viral post to survey data on who gets promoted for it.
Hiring, firing and rehiring
Two labour-market stories from the week, for context on the teams that will be asked to run this tooling.
The open-source security commons
The foundation layer: an upcoming fix-it event, the next cohort of supply-chain contributors, a member case study, and the policy question of what “open by default” means once AI is involved.
Detailed write-ups
1. GitHub now asks who is running the workflow, and starts enforcing on 2 November
DevOps.com · September 21, 2026
The date to put in the calendar is 2 November 2026. That is when GitHub begins enforcing the new default restrictions on pull_request_target. The broader feature, workflow execution protections, went generally available on 17 September after a public preview that opened on 18 June; DevOps.com’s write-up landed on 21 September, and it names the incidents that set the context: tj-actions/changed-files, Nx and trivy-action.
The substance is granularity. Rules can now target specific workflow files rather than whole repositories, so the release workflow and the lint workflow no longer have to share one policy. Actor rules can name individual users, repository roles (Read, Maintain, Admin), GitHub Apps, Copilot and Dependabot — which means automated actors can be given a different set of runnable workflows from humans. An evaluate mode lets an administrator see what a policy would block before enforcing it, and a new REST API supports create, read, update and delete of rules at enterprise, organisation and repository level. Coverage is all public repositories, plus private repositories on GitHub Team or GitHub Enterprise.
The Futurum Group’s Mitch Ashley put the threat model in one line: “A single compromised developer account can mean the difference between a well-running pipeline and compromised software.” That is the right way to read this release. It does not scan code or find vulnerabilities; it narrows which identities can cause a workflow to run at all, which is the step an attacker holding a compromised account needs. The practical move is to use the five weeks before enforcement to run evaluate mode across the estate and find the workflows that rely on the old behaviour, rather than discovering them from a failed release in November.
Sources: https://devops.com/github-separates-who-writes-code-from-who-runs-your-ci/
2. GitHub Enterprise Cloud can now tell you every credential, who owns it and when it was last used
DevOps.com · September 24, 2026
Four days after the workflow protections went generally available, GitHub shipped the other half of the same argument. From 21 September, GitHub Enterprise Cloud customers can export a credential inventory covering SSH keys, personal access tokens both classic and fine-grained, OAuth app tokens and GitHub App credentials. Each record carries the owner, scopes, creation and expiration dates, and a last-used timestamp. The export comes as CSV from Enterprise Settings or through a paginated REST API, filterable by user, app, credential type or organisation.
Two details make it more useful than a one-off audit. A new “View enterprise credentials” permission lets security staff read the inventory without holding full enterprise-admin rights, which removes the usual reason the audit never happens. And the API makes it repeatable: Ashley’s view is that “pulled daily via the API and compared run-over-run, it becomes an operating control.” A token that appears overnight, a key that has not been used in a year, a classic PAT with broad scopes on a departed account — all of those become diffable events rather than things someone finds during an incident.
Keep the scope clear. This is an inventory, not secret scanning; it tells you which credentials exist and how they are used, not whether one has been committed to a repository. And it is Enterprise Cloud only for now. GitHub says Enterprise Server support is planned and has given no date, so self-hosted customers should not plan around it yet.
Sources: https://devops.com/github-gives-enterprises-a-full-count-of-who-holds-the-keys/
3. Gemini CLI 0.61.0 puts build files behind a confirmation prompt
The New Stack · September 24, 2026
Google released Gemini CLI 0.61.0 on 24 September, and the change is narrow and pointed. Build configuration files — package.json, Makefiles, pyproject.toml and Bazel BUILD files — now require the user’s confirmation before the agent edits them. Confirmation is also required to run build or test commands after such an edit, and for shell commands whose arguments came from untrusted external content. The untrusted sources named are web search results, MCP server responses, Google Docs and Buganizer, Google’s internal issue tracker.
The reason build files are the gate is that they are where an instruction becomes execution: an agent that can add a postinstall script or a Make target can run arbitrary code the next time anyone builds. The New Stack’s Amanda Caswell frames it well: “Giving a coding agent more authority to modify and execute code also gives an attacker more ways to turn that authority against the developer.” The sandbox changed too. Gemini CLI supports Docker, Podman, LXC or macOS Seatbelt, and the ~/.gemini directory is no longer mounted into the sandbox; sanitised settings with API keys and hooks stripped are passed in instead.
Two limits on the reading. The change is sourced to two public pull requests in the Gemini CLI repository, not to a named attack or CVE, so it is hardening rather than a patch. And it does not address last week’s Plugin4Shell pinned-plugin issue. Google announced at I/O in May that Gemini CLI is migrating to Antigravity CLI, and the open-source tool has primarily served enterprise customers since 18 June; whether these gates carry into the successor is the question to ask of it.
Sources: https://thenewstack.io/gemini-cli-prompt-injection-safeguards/
4. ZCode uploaded whole workspaces to the cloud, and Z.ai has apologised
The Register · September 22, 2026
This is not a breach and not an attacker; it is a vendor’s own tool doing something its users did not agree to. Z.ai, formerly Zhipu, found that its ZCode product had been packaging entire user workspaces and uploading them to Alibaba Cloud without consent. The uploads included complete project histories and git-encrypted files that users could neither access nor delete, and only Z.ai’s servers held the private decryption keys. The upload was triggered by ZCode’s Repository Index functionality after its Repo Wiki feature generated cloud-hosted pages. A researcher writing as “Ferstar” first identified the behaviour publicly.
Z.ai’s response has three parts, all of them its own claims. It says previously uploaded data has been deleted and the Repo Wiki feature removed. It commissioned the China Academy of Information and Communications Technology (CAICT) and Beijing security firm NSFOCUS to audit the product; no audit results have been published. And it open-sourced the entire ZCode project on GitHub. The company’s statement: “We sincerely thank the community developers who previously identified issues in ZCode. Going forward, we will establish an ongoing product security vulnerability reporting and response process.”
The lesson for a DevSecOps programme is about the tool, not the model. A coding assistant sits on the developer machine with read access to everything in the workspace, and indexing features have an obvious reason to send that content somewhere. Knowing what each assistant in use uploads, where it goes and whether the user can delete it is now a procurement question, and it is one the vendor’s documentation may not answer until a researcher does.
Sources: https://www.theregister.com/security/2026/09/22/zai-says-sorry-for-slurping-up-your-code-open-sources-zcode/5298300
5. Prismor puts a policy check on every tool call a coding agent makes
Help Net Security · September 23, 2026
Prismor is a free, open-source layer that sits between an AI coding agent and its actions and checks each tool call against policy before it executes. It supports Claude Code, Codex and Cursor, is distributed on GitHub under PrismorSec, and gives every call one of three verdicts: allow, warn or block. Rules start in observe mode by default, logging findings to a local dashboard, and the user chooses which to enforce — the right default for a tool that could otherwise break a developer’s workflow on day one.
The package-install piece is the part most directly aimed at the supply chain. Prismor wraps npm and pip and scores each install on package age, maintainer count, install scripts and compromise indicators; a score of 60 or more blocks it. The attacks it cites as examples are the May 2026 mini-shai-hulud wave and the AntV hijacked-maintainer incident. The project reports 0.8 milliseconds of overhead per tool call across simulated agent sessions, and says an optional LLM-based “semantic guard” raised its prompt-injection catch rate by 30% across 800+ test cases without increasing false positives.
Those figures are the project’s own benchmarks on simulated sessions, and no maintainer or company is named beyond PrismorSec, so treat Prismor as a pattern to evaluate rather than a control to deploy blind. The pattern itself is sound and worth copying whatever tool implements it: observe first, score dependencies before an agent can add them, and put the decision point before execution rather than in a log review afterwards.
Sources: https://www.helpnetsecurity.com/2026/09/23/prismor-open-source-ai-agent-security/
6. JetBrains Air: the IDE maker builds for the system, not the workbench
InfoWorld · September 23, 2026
JetBrains announced JetBrains Air on 22 September, describing it as an open system of products for managing AI-driven development across individuals, teams and organisations. There are three named parts. Air in JetBrains IDEs is an agentic experience for directing and orchestrating agents and verifying their work. Air Teams coordinates and automates software-delivery workflows that mix developers and autonomous agents. And Air Governance covers policy, visibility, auditability, cost management and accountability for AI-assisted development.
Air Governance is not new: it is JetBrains Central renamed. That matters for evaluation, because it is the component a security team will actually care about, and it has a track record to check. JetBrains also says it will feed agents richer context from code, architecture, repositories, runtime behaviour and organisational knowledge, with mobile and remote experiences planned “over time”. CEO Kirill Skrygan framed the shift: “For 26 years, we have focused primarily on the individual developer workbench. Now, we are building for the wider system…”
No pricing, availability dates or supported-agent list were given, so this is a direction rather than a purchase decision. The direction is the useful signal: the tools that direct agents are now being sold with governance and audit as a named product line, which gives security teams a place to ask for the controls rather than bolting them on.
Sources: https://www.infoworld.com/article/4225681/jetbrains-unveils-jetbrains-air-for-agentic-software-development.html
7. Mandiant’s CI/CD hardening list, and the seven-day cooldown
Google Cloud (Mandiant) · September 24, 2026
Mandiant’s Proactive Defense guidance, published 24 September, is guidance rather than incident reporting, and it reads best as the control list the GitHub releases above slot into. Its most concrete recommendation is a minimum seven-day release-age cooldown before newly published public package versions become installable — a direct answer to the window in which a malicious version is live before anyone notices. It recommends pinning container images and third-party actions to immutable SHA-256 digests rather than mutable tags, and single-use ephemeral runners destroyed after each job.
On identity, it recommends OIDC federation to replace long-lived automation secrets with short-lived tokens, and migrating classic PATs to fine-grained PATs with strict TTLs, plus pre-commit and IDE secret scanning. On the build itself, it recommends isolating build caches by branch privilege and rejecting cache writes from unauthenticated forks, and generating and signing SBOMs in CycloneDX or SPDX tied to the artifact digest. It closes with a six-stage scanning gate: secrets at pre-commit, SAST at pull request, SCA at build, container at the registry, DAST in staging and CSPM before deploy. Mandiant’s summary: “Hardening the development lifecycle requires implementing continuous, automated verification at every stage, unifying security postures across developer endpoints, code repositories, package registries, build runners, and deployment guardrails into a cohesive defensive framework.”
Two cautions. The guidance names no specific campaigns and cites only CISA KEV externally, so it should not be read as a response to any particular incident. And it recommends Google products in places; the controls transfer to any stack, and the controls are what to carry out of it.
Sources: https://cloud.google.com/blog/topics/threat-intelligence/hardening-code-pipelines-and-ci-cd-infrastructure/
8. Lovable’s OJ: a Rust rewrite of one layer, and what it says about forking
Socket · September 22, 2026
OJ is a Rust rewrite of Vite’s dev-server layer only — the file watcher, module graph, compiler coordination, hot updates and WebSocket handling — not of Vite as a whole. It was built by Raphael Amorim at Lovable and lives at github.com/lovablelabs/oj. On a 10,000-component test app, Lovable reports OJ using 115 MB of memory against 1,751 MB for Vite’s bundled mode, with cold start at 1,315 ms against 1,528 ms. In a controlled production rollout, Lovable says median sandbox acquisition time fell from 14.5 seconds to 3 seconds. It has been tested against real apps including Excalidraw and Twenty, the latter at 15,000+ modules.
The memory number is the business case. Lovable engineer Jonathan Grahl: “Memory is a dedicated resource (compared to CPU which is highly shareable); which makes it expensive.” For a company running a sandbox per user, a fifteen-fold cut in dev-server memory changes the unit economics. OJ and Vite 8 share Rolldown for bundling and Oxc for parsing and transforms, both maintained by VoidZero, which keeps the fork tied to the upstream at the layers that do the heavy lifting.
The supply-chain angle is the thesis in the headline, not a vulnerability: when AI lowers the cost of rewriting a large open-source component, more organisations will run their own forks of pieces they used to consume as-is. Every one of those is a component whose maintenance, patching and provenance now sit with the forking team. All the performance figures here are Lovable’s own.
Sources: https://socket.dev/blog/oj-vite-rust
Calls to action
- Run GitHub’s workflow execution protections in evaluate mode this week. Enforcement of the new
pull_request_target defaults starts on 2 November. Evaluate mode shows what a policy would block before it blocks it; use the five weeks to find the workflows that depend on the old behaviour.
- Write actor rules per workflow file, not per repository. Rules can now target specific workflow files and name individual users, roles, GitHub Apps, Copilot and Dependabot. Give release and deploy workflows the narrowest actor list, and manage the rules through the REST API so they live in version control.
- Pull the credential inventory and revoke what nobody uses. On GitHub Enterprise Cloud, export SSH keys, classic and fine-grained PATs, OAuth app tokens and GitHub App credentials, sort by last-used, and revoke the stale ones. Grant security staff the “View enterprise credentials” permission rather than full enterprise-admin rights.
- Upgrade Gemini CLI to 0.61.0 and turn the sandbox on. The release gates build-file edits and untrusted-input shell commands behind confirmation, and no longer mounts
~/.gemini into the sandbox. Choose one of Docker, Podman, LXC or macOS Seatbelt, and treat confirmation prompts as a review step rather than something to click through.
- Find out what your AI coding tools upload. ZCode packaged entire workspaces and sent them to a cloud provider without consent. For every coding assistant in use, check what leaves the machine, where it goes and whether the user can delete it; monitor egress from developer machines where you can.
- Put a policy check between agents and package installs. Whatever tool you use, the pattern is the one Prismor implements: start in observe mode, log every tool call and install, then enforce the rules that fire on real attacks. Score new dependencies on package age, maintainer count, install scripts and compromise indicators before an agent can add them.
- Adopt Mandiant’s pipeline baseline. A seven-day release-age cooldown; container images and third-party actions pinned to SHA-256 digests; single-use ephemeral runners; OIDC federation in place of long-lived automation secrets; build caches isolated by branch privilege with fork writes rejected; classic PATs migrated to fine-grained tokens with strict TTLs; signed SBOMs tied to the artifact digest.
|