AI Dev Patterns: GitHub Agentic Workflows Go GA, Anthropic Replaces Git with Scion, Validator-Gated Security Agents, 2026-11-02
ai

AI Dev Patterns: GitHub Agentic Workflows Go GA, Anthropic Replaces Git with Scion, Validator-Gated Security Agents, 2026-11-02

7 min read

GitHub Agentic Workflows Reach GA with a Defense-in-Depth Execution Model

GitHub Agentic Workflows, an open source project from GitHub Next, became generally available at Universe on October 28 for GitHub Free, Team and Enterprise. Workflows are written as Markdown in natural language and compiled into standard GitHub Actions YAML, so they reuse existing runners and policies. Typical uses are issue triage, CI failure analysis, documentation updates and test writing.

The execution model is the interesting part for anyone designing agent pipelines. Workflows run with read-only permissions by default, agents execute in a sandboxed container behind an Agent Workflow Firewall, access to GitHub content passes through an integrity filter, and agent outputs go through "safe outputs" validation plus a dedicated threat-detection job before any proposed change takes effect. New at GA, agents can run in Cloud Hypervisor or NVX micro-VMs, and enclaves help prevent leaks in cross-repository workflows.

The default engine is Copilot CLI (requiring a Copilot license), but teams can bring their own coding agent, choose providers per workflow, or use a model router that picks models by task difficulty. Self-hosted Actions Runner Controller runners are now supported, including Docker-in-Docker, and gh aw forecast (now stable) estimates monthly AI credit spend including threat-detection costs. The pattern of "natural-language intent, compiled to a reviewable deterministic artifact, executed with least privilege and gated outputs" is becoming the template for CI-hosted agents.

Read more — GitHub Changelog


Anthropic Moves Its Monorepo from Git to Scion to Keep Up with Agent Commit Volume

InfoQ covered Anthropic's account of replacing Git for its monorepo with Scion, an in-house source control system built for AI-driven development. The driver was volume: daily merged changes rose from about 2,500 in May to more than 30,000 in September, CI performs around 25 million checkouts per day, and the repository holds nearly 100 GB of main-branch history. Shallow clones, sparse checkouts, promisor remotes, snapshots and several hundred Git mirrors had all become harder to operate.

Scion moves commits, merges, rebases, history and blame to the server. Changesets record files changed relative to the first parent with content-addressed blob pointers, clients fetch immutable trees and blobs directly instead of negotiating packfiles, a node-local daemon shares cached objects between jobs, and regional caches sit in front of authoritative servers backed by Spanner and cloud storage. Checkouts are virtualized and tools can read diffs or perform some writes through APIs without checking out code. Anthropic reports cache hit rates above 99%, a footprint about 200 times smaller than its Git mirrors, and checkouts roughly two orders of magnitude faster, and credits Meta's Mononoke and Bonsai model for many of the ideas.

Scion is not a general Git replacement: it depends on Anthropic's bespoke code review, search and CI, and gives up offline independence. The transferable lessons are about where work happens when agents generate most commits: expose rich server-side repository APIs so agents do not need full checkouts, share immutable objects through caches, and treat checkout cost as a first-class CI bottleneck.

Read more — InfoQ


IBM Granite Switch 4.1.1 Treats Model Capabilities as Versioned, Swappable Adapters

IBM's Granite Switch 4.1.1 is a patch release of a modular architecture in which a single 30B checkpoint carries built-in adapters that are switched on as needed, so one endpoint can serve chat, decision-making and speech tasks. The release is explicitly versioned like software: 4.1.1 is backwards compatible with 4.1, and the only retrained components are a new Granite Speech ASR model (10 languages, with punctuation and capitalization in the output) and an updated Decision adapter. The base model was not touched.

The idea is that capabilities can be patched independently, the way a library ships a point release, rather than retraining or redeploying an entire model. IBM says an Adapter SDK is coming that will let developers and third parties build, version and test their own adapters. For teams running self-hosted models, this is a different operational model from swapping whole checkpoints: smaller, more frequent updates with clearer compatibility guarantees.

Read more — Hugging Face


Safe & Secure AI Agent Practices

Docker's "The CVE That Did Not Exist": Sandboxes Contain Actions, Not Claims

The latest entry in Docker's Coding Agent Horror Stories series describes a self-hosted AI code review bot, running local models via Ollama in GitLab CI with a read-only rule, that reviewed a routine PostgreSQL patch bump from 16.11 to 16.13. It returned a 1,500-word rejection describing an "architectural takeover," citing a CVE number that was never issued, naming a company that does not exist, referencing Kubernetes resources it could not have seen, and recommending that the team revoke all IAM access and run Go scripts to isolate "infected" database nodes. No permission was violated; the danger was entirely in a confident, well-formatted report that a tired on-call engineer might act on.

Docker's hardened design runs the bot in a Docker Sandbox microVM with the repository mounted read-only, no GitLab token, kubeconfig or cloud credentials, and a deny-by-default network policy that opens exactly one path to the model endpoint. Output is written to a file on the runner rather than posted directly, and a post-processing step checks every CVE identifier in the review against the NVD API, flagging the review as unverified if any ID does not exist. The policy log is reviewed afterward to prove the agent could not reach the cluster.

The recommendations generalize: treat agent security findings as hypotheses, automatically verify CVE IDs against a public registry, never run agent-written remediation without review, make read-only a property of the environment rather than a convention, and label agent output so it does not borrow the authority of a senior engineer. As the post puts it, containment handles what an agent can do; how much to trust what it says remains a human decision.

Read more — Docker


Google's PageBreak Only Reports Vulnerabilities a Deterministic Validator Can Reproduce

Google disclosed PageBreak, a Gemini-based security agent that has found more than 500 cross-site scripting vulnerabilities in Google's own web applications since entering full operation in January 2026. The design addresses the same problem as the Docker story above. The model is free to propose any hypothesis, but a finding only reaches a product team once a deterministic validator, plain code written by security engineers and kept outside the agent loop, reproduces it with a real payload: executing JavaScript for XSS, writing to a world-readable location for path traversal, or triggering outbound DNS for remote code execution. Google reports a near-zero false-positive rate.

Findings the validators cannot confirm are kept internally to seed future scans and to highlight where new validators are needed, rather than being sent to engineers as noise. Google acknowledges the trade-off: validators do not yet cover all vulnerability classes, so false negatives are possible, and the 500+ figure has not been independently verified. PageBreak is being integrated with CodeMender, Google's agentic fix generator, with the goal that product teams only review AI-generated fixes.

The pattern, "LLM generates hypotheses, deterministic code decides what counts," is a practical answer to hallucinated security reports and is applicable well beyond XSS scanning.

Read more — InfoQ


Gemini Enterprise Semantic Governance Now Evaluates Tool Calls from Non-Gemini Models

On October 26, Google extended semantic governance policies on Gemini Enterprise Agent Platform to evaluate tool calls produced by non-Gemini providers, including Anthropic, OpenAI Chat Completions, Mistral and self-hosted OpenAI-compatible servers. Organizations running mixed-model agent fleets can now apply one authorization policy layer regardless of which model proposes a tool call. Streamed responses are not yet supported, and each authorization policy's when condition must be updated to match the provider's request path.

The same update documents user intent matching, which checks that tool calls align with what the user asked for and is on by default. It can be disabled with the sgpUserIntentMatching key, but Google notes that doing so reduces protection against indirect prompt injection. Combined with the human-in-the-loop confirmation policies that shipped with the computer use tool's GA on October 30, this is a concrete example of moving agent guardrails out of prompts and into platform-enforced policy.

Read more — Google Cloud


Stanislav Lentsov

Written by

Stanislav Lentsov

Software Architect

You May Also Enjoy