Ship It Weekly Host Commentaries

For this Ship It Weekly episode, I wanted to zoom in on a pattern I keep seeing: the stuff we call “glue” is now the blast radius.

A few years ago, you could kind of mentally separate things into buckets. There was “the app,” there was “infra,” and then there was a pile of scripts and YAML and CI jobs that felt like supporting cast. Useful, but not the main story. This week’s stories are a reminder that the supporting cast is now running the show. The control plane, CI triggers, agent tooling, metadata… that’s where outages and security incidents start getting born.

We opened with Azure because it’s the cleanest example of a control plane incident that doesn’t look like a clean outage. When VM service management ops get degraded, it’s not a single red alert that screams “Azure is down.” It’s this slow-motion failure where everything feels “kind of broken” in a way that’s hard to pin on one thing. Deploys hang. Scaling actions don’t apply. Nodes don’t come back the way they normally do. Rollbacks take longer than they should. And because your product still responds to some traffic, humans argue about whether it’s real, whether it’s your code, whether it’s the cluster, whether it’s just “a temporary hiccup.” That’s the exact zone where time disappears.

And the ugly truth is: even if your application is fine, you can still be in a bad incident if you can’t operate the platform. A lot of teams build resiliency thinking primarily about the data plane, requests, latency, errors, and throughput. But control plane issues break your ability to respond. If you can’t scale out, can’t recreate nodes, can’t change configs, can’t drain traffic the way you normally do, then the incident becomes less about the technical fix and more about human coordination and waiting. That’s how a 15-minute issue becomes a two-hour issue. Not because the original problem was huge, but because you lost the steering wheel.

Then we moved into GitHub’s agent push because that’s the other half of the same theme. AI tooling is no longer a side tab. GitHub putting Claude and Codex into Agent HQ alongside Copilot is them saying “this is the workflow now.” And for DevOps and platform folks, that’s not a fun gadget story. That’s a supply chain story.

Because once an agent can open PRs, update workflows, or propose changes in an infra repo, you’ve effectively created a new automation actor in your environment. An actor that makes changes quickly, confidently, and sometimes without the same instinct humans have for “wait… should we touch that?” The interesting thing about the GitHub Actions case() update is it’s small, but it points at a bigger trend. CI logic is becoming more expressive and more central. That’s good. It also means the difference between a safe deploy and a “why did this run in prod?” incident is increasingly hidden in workflow logic and permissions. If AI agents are going to play in that space, your guardrails and reviews matter more than the model pick.

There’s a mindset shift here that I think teams are going to have to make this year. CI is not just a build system. It’s a control plane. The workflow files are production code. The runner fleet is infrastructure. The artifacts and tokens are high-value security assets. So if you’re letting agents touch that layer, treat it like you’re granting access to a real teammate, not like you’re enabling autocomplete. Start read-only. Start “suggest and explain.” Force review. Keep write access narrow. Build audit trails. If you don’t, you’re going to get a brand new class of incident: not a broken app, but an agent-initiated change that’s logically plausible and still wrong.

The DockerDash story is the one I didn’t want to gloss over, because it’s easy to hear “AI vuln” and tune out. The important part isn’t Docker specifically. The important part is the pattern: once agents are wired to tools, “untrusted input” expands. Most of us have mental models for untrusted input. HTTP requests, form fields, user uploads. We’ve spent twenty years building guardrails around those.

But now you’ve got systems where image metadata, descriptions, README text, issue comments, commit messages, or even a cleverly phrased error log can become part of the agent’s context. If the agent is allowed to act on that context, now you’ve got a prompt injection path. And prompt injection isn’t magic. It’s just a new way to trick an automation system into doing something dumb. We’ve had this problem forever. We called it social engineering. We called it command injection. We called it supply chain poisoning. Now it’s “prompt injection,” but the defense mindset is the same. Don’t let untrusted text drive privileged actions. Put hard gates between reading and doing. Scope tools. Use allowlists. Log everything. And assume anything that can be influenced by an external party will eventually be influenced by an external party.

That leads into MCP, which is the connective tissue story. MCP sounds like “yet another protocol,” and it’s tempting to ignore it. But I think this is the layer that will decide whether the agent wave is useful or chaotic. Because the moment you have a standard way for agents to discover tools and call them, you’ve created a new platform surface area.

Now you need the same boring, essential platform engineering stuff we learned with APIs. Inventory, so you know what exists. Ownership, so somebody is accountable. Auth, so access is scoped. Policy, so you can enforce guardrails centrally. Auditing, so you can reconstruct what happened when something goes sideways. Rate limits, so an agent doesn’t melt your internal systems. And you need “break glass” and “kill switch” thinking, because the worst incidents in automation are the ones where you can’t quickly stop the automation.

And then observability tying into all this is interesting, too. When companies start treating telemetry as data that belongs in the same universe as everything else, and then layering AI on top, they’re basically saying: “we want systems that can reason about reality faster than humans can.” That sounds good. But it also means your telemetry pipeline is now a governance issue, not just a tooling issue. Who can query what? What’s in those logs? What secrets accidentally end up there? What’s your retention policy? What happens when an AI assistant can search your logs better than your humans can? That’s powerful. It also changes the risk profile of “we keep everything forever.”

So my throughline for the episode is simple: the control plane is part of the product, and AI is becoming part of the control plane. Treat it that way.

If you’re adopting agents, don’t think of it as “we’re adding a tool.” Think of it as “we’re adding an actor.” And actors need identity, permissions, constraints, and accountability. The success path here isn’t hype. It’s boring. It’s guardrails, approvals, audit logs, and a team-wide understanding of what agents are allowed to touch.

Because the failure mode isn’t that the agent is dumb. The failure mode is that the agent is competent enough that people stop double-checking.

And when that happens, you don’t get a normal outage. You get an automation incident. The kind where everything looks plausible, until you realize the system is drifting in the wrong direction and nobody noticed because everyone trusted the glue.

---

Quick follow-ups since we covered these recently: ingress-nginx and n8n are both still in the “patch fast, then verify you’re actually patched” bucket. For ingress-nginx, there’s an updated security advisory thread with multiple issues and fixed versions called out, plus Chainguard is publishing updates around keeping ingress-nginx alive as upstream heads toward the March 2026 retirement timeline. For n8n, there’s a fresh security bulletin with upgrade guidance, and it’s a good reminder that workflow automation tools sit right next to your secrets, so “authenticated” vulns still matter a lot if workflow authoring isn’t tightly restricted.

Links
ingress-nginx advisory thread: https://discuss.kubernetes.io/t/security-advisory-multiple-issues-in-ingress-nginx/34115
Chainguard on ingress-nginx: https://www.chainguard.dev/unchained/keeping-ingress-nginx-alive

Past episode where we covered ingress-nginx retirement / March 2026 timeline:
Episode 2Nov 21, 2025⏱️ 15:53Kubernetes Shake-ups, Platform Reality, and AI-Native SREEpisode: Kubernetes Shake-ups, Platform Reality, and AI-Native SRE

n8n security bulletin: https://community.n8n.io/t/security-bulletin-february-6-2026/261682

Past episode: n8n “Ni8mare” / CVE-2026-21858
Episode 12Jan 9, 2026⏱️ 16:18n8n Critical CVE (CVE-2026-21858), AWS GPU Capacity Blocks Price Hike, Netflix TemporalEpisode: n8n Critical CVE (CVE-2026-21858), AWS GPU Capacity Blocks Price Hike, Netflix Temporal

Past episode: n8n Auth RCE / CVE-2026-21877
Episode 14Jan 16, 2026⏱️ 12:28n8n Auth RCE (CVE-2026-21877), GitHub Artifact Permissions, and AWS DevOps Agent LessonsEpisode: n8n Auth RCE (CVE-2026-21877), GitHub Artifact Permissions, and AWS DevOps Agent Lessons

We also mentioned Observe getting acquired by Snowflake - https://www.linkedin.com/posts/snowflake-computing_welcome-to-the-team-observe-inc-today-activity-7424199034833301504-icN8

For this Ship It Weekly episode, I wanted to lean into something I think a lot of us are feeling right now.

The “hard” parts of infra are still hard, but the stuff that keeps biting teams is the glue. The little config assumptions. The trigger rules. The cert renewals that “should be automated.” The Helm defaults everyone copy-pasted three years ago. The automation tool that quietly turned into a control plane holding every credential.

That’s basically the connective tissue for all four stories.

CodeBreach is the cleanest example of “glue is the boundary.” AWS’s bulletin is pretty straightforward, but the bigger takeaway is the part nobody wants to admit: CI triggers are now authorization. If an untrusted event can cause a trusted pipeline to run, you’ve built an execution environment exposed to the internet, and you’re hoping the YAML doesn’t have a footgun in it. That’s why the Wiz angle matters too. It frames how quickly “just CI” can become “supply chain.”
AWS bulletin: https://aws.amazon.com/security/security-bulletins/2026-002-AWS/
Wiz research: https://www.wiz.io/blog/wiz-research-codebreach-vulnerability-aws-codebuild

The Bazel cert expiry story is the other flavor of glue failure. It’s boring, it’s binary, and it’s absolutely capable of blocking an entire engineering org. The part I keep coming back to is that “auto renew” is not a system. It’s a single step. The real system is issuance, renewal, deployment, reload, and verification, with monitoring that checks what users actually hit. Most orgs have 2 out of 5 and call it done.
Postmortem: https://blog.bazel.build/2026/01/16/ssl-cert-expiry.html
Extra context that pairs well with this: https://surfingcomplexity.blog/2025/12/27/the-dangers-of-ssl-certificates/

Helm chart reliability is the one that feels less spicy, but it’s probably the most “this will save you pain next month” story. Prequel’s report reads like a postmortem generator because these are exactly the failure modes that stretch incidents out. Missing requests means unpredictable scheduling and throttling. Weak probes means traffic going to pods that aren’t actually ready. Missing disruption guardrails means node drains can turn into brownouts. And the worst part is how often Kubernetes looks “green” while your app is melting.
Report: https://www.prequel.dev/blog-post/the-real-state-of-helm-chart-reliability-2025-hidden-risks-in-100-open-source-charts

Then n8n. This one keeps coming up on the show for a reason. Workflow automation tools feel harmless until you remember what they really are. They’re a control plane that holds credentials and runs code on behalf of humans. So when you see sandbox escape + code execution, “authenticated” should not make you relax. It should make you ask who can author workflows and what those workflows can touch. Patch fast, narrow authorship, reduce exposure, and least-privilege the credentials it holds.
The Hacker News coverage: https://thehackernews.com/2026/01/two-high-severity-n8n-flaws-allow.html
Canadian advisory (nice summary + tracking): https://www.cyber.gc.ca/en/alerts-advisories/al26-001-vulnerabilities-affecting-n8n-cve-2026-21858-cve-2026-21877-cve-2025-68613
JFrog technical write-up: https://research.jfrog.com/post/achieving-remote-code-execution-on-n8n-via-sandbox-escape/

If you listened to the last two n8n CVE episodes, this is the same theme, just the “next” set of vulns. It’s not about n8n being uniquely bad. It’s that the category is high leverage, and if it’s inside your network with credentials, you treat it like production software.
Past episode 1: Episode 12Jan 9, 2026⏱️ 16:18n8n Critical CVE (CVE-2026-21858), AWS GPU Capacity Blocks Price Hike, Netflix TemporalEpisode: n8n Critical CVE (CVE-2026-21858), AWS GPU Capacity Blocks Price Hike, Netflix Temporal
Past episode 2: Episode 14Jan 16, 2026⏱️ 12:28n8n Auth RCE (CVE-2026-21877), GitHub Artifact Permissions, and AWS DevOps Agent LessonsEpisode: n8n Auth RCE (CVE-2026-21877), GitHub Artifact Permissions, and AWS DevOps Agent Lessons

Lightning round was intentionally “operator-friendly” this week.

Fence is the kind of primitive I want more of. Safe-by-default beats clever-by-default, especially if you’re experimenting with agents or runbooks that execute.
Fence: https://github.com/Use-Tusk/fence

HashiCorp agent-skills is interesting because it’s a vendor leaning into guardrails and reusable skills instead of “just prompt better.” That’s the right direction if we’re going to operationalize agent workflows without lighting things on fire.
agent-skills: https://github.com/hashicorp/agent-skills

marimo hits a real pain point for me: incident analysis and ops experiments are genuinely useful in notebook form, but notebook JSON is awful to version and review. “Notebook, but it’s just Python files” is a good trade.
marimo: https://marimo.io/

And the Claude loop story is funny, but it’s also the warning label. People are already building “keep going until it works” loops. If you don’t put constraints and verification around that, you get confident nonsense at scale. The failure mode is basically alert fatigue, but for decisions.
The Register: https://www.theregister.com/2026/01/27/ralph_wiggum_claude_loops/

So yeah. Big picture, I think this is the real job now. Not “automate everything.” It’s “treat guardrails like product work.” Because the moment your glue gets fast and automated, failures get fast too. And if you only build accelerators, you’re not building a better platform. You’re building a faster incident.

More episodes and links live here: https://shipitweekly.fm

For this Ship It Conversations episode, I wanted to bring the “AI automation” conversation back down to earth. Not “agents will replace everyone” and not “here’s a Zapier demo that falls apart the second it hits real volume.” Just… what’s actually working for businesses that need reliability, repeatability, and fewer things falling through the cracks.

Austin’s world is SMB automation, but a lot of the themes map cleanly to how we think about ops. The big one is expectations. Some owners are scared of AI and don’t trust it at all. Other owners think because Cursor exists, they can get a production-grade system for $300 and a weekend. Austin’s take is basically: both sides are wrong. AI is useful, but it doesn’t remove the need for process, clarity, testing, and someone who understands what “good” looks like.

The part I liked most is how he frames quick wins and prototyping. Businesses come in with the giant menu order, and it’s tempting to build the full “automation platform” version of their dream. But his team pushes for one high-impact workflow first, gets it in people’s hands early, and iterates. That’s basically the same playbook we use in infra when we’re being honest. Prove it works, shrink the unknowns, then expand. And he had a really good warning that I’ve seen in platform work too: don’t automate a future problem. If it isn’t happening yet, you’re guessing. And guessing is expensive.

We also talked about what not to automate, which is where you can tell he’s been burned by reality. Finance-heavy logic is a no-go for him unless someone truly understands it, because the cost of being wrong is way higher than the convenience. Same with HIPAA and government, because compliance and liability turn every “simple automation” into a minefield. And even when you do automate, he’s big on “man in the loop” for anything that needs judgment or a human touch. That’s the sane version of “agents,” in my opinion. Use AI to draft, triage, summarize, route, and accelerate. Don’t let it make irreversible decisions without review.

The dev workflow stuff was interesting too. He’s using GPT and Claude for different strengths, Cursor to move faster, and experimenting with AI in PR review and CI/CD quality gates. And the key detail he kept coming back to is something I wish more people would admit: these tools help the most when you already understand the problem. If you can’t validate the output, you’re basically outsourcing decision-making to a confident autocomplete engine. Sometimes that’s fine. Sometimes it’s how you quietly ship a disaster.

If you’re in DevOps/SRE and your org is getting pulled into “AI automation,” this episode gives you a useful lens. Start with a real workflow that exists today. Define what success looks like. Put guardrails around anything risky. Ship a small win. Then build outward. That approach works whether you’re automating lead follow-up for a sales team or rolling out a platform workflow that touches production systems.

Links to Austin’s LinkedIn and horizon.dev are in the show notes.

This week’s episode is kind of a perfect “small decisions, big consequences” combo.

On paper, these three stories look unrelated:

curl shutting down bug bounties
AWS shipping a couple container/database features that sound boring
and a Honeycomb outage write-up that’s basically “our own safeguards bit us”

But the thread through all of it is the same: signal vs noise, and how platform teams get crushed when the signal gets buried.

1) curl shuts down their bug bounty because of AI slop

This one made me sad, but it also felt inevitable.

curl has always been this weird backbone dependency that everyone uses and nobody thinks about until something breaks. It’s also been one of the better examples of “a small team maintaining critical infra” doing the right things publicly, transparently, and responsibly.

And now they’re basically saying: “we can’t keep running a bug bounty like this because it’s getting flooded with low-quality AI-generated reports.”

If you’ve ever been on the receiving end of a vuln intake queue, you already know what’s happening. It’s not just spam. It’s spam that looks plausibly real at first glance, so you have to spend real cycles to disprove it. That’s the worst kind.

A couple thoughts I couldn’t fit into the show:

• This is going to spread. Security teams and maintainers are going to start rate-limiting “external feedback” the same way we rate-limit APIs. Identity, reputation, proof-of-work, anything to keep the channel usable.
• “Bug bounty” might split into tiers. Like a public free-for-all channel for obvious stuff, then a gated lane for researchers who can demonstrate quality. Not because maintainers are evil, but because you literally can’t function otherwise.
• This is also a warning for AI in ops. If your automation can generate tickets, PRs, alerts, or incidents, you need guardrails, dedupe, scoring, and throttling… or you just invented a new way to DoS your own humans.

The punchline is brutal: the same tooling that helps real researchers move faster is also letting randoms generate infinite garbage. And the limiting factor is still human attention.

2) AWS RDS Blue/Green improvements (and what you should actually take from it)

Blue/green for databases always sounds like the promised land until you actually try to ship it.

The hard parts are never “can I flip a DNS record.” The hard parts are:

• replication lag realities
• cutover sequencing
• client behavior (retries, pools, connection storms)
• and what happens when you have to roll back but the write paths already diverged

So when AWS talks about reducing downtime and making blue/green smoother, I’m not hearing “free magic.” I’m hearing “they’re sanding down the sharp edges enough that more teams will actually try it.”

If you’re operating a service with a real DB behind it, the practical takeaway is:

If you’re still doing “maintenance window + pray,” you should at least revisit what’s possible now. Not because you need perfection, but because even shaving downtime from minutes to seconds changes how often the business will let you practice it.

And practicing it matters more than the feature. You don’t want your first real blue/green cutover to be under pressure.

3) ECR cross-repository layer sharing (and why this matters in platform land)

This one is one of those “sounds minor, is actually huge at scale” AWS updates.

If you run lots of images, lots of services, lots of accounts, you’ve probably felt all of these:

• duplicate layers everywhere
• slow pulls during deploy storms
• wasted storage
• painful cache behavior when teams do their own thing

Layer sharing is basically AWS acknowledging that the “one repo per app” model gets weird when you have a real platform, real reuse, and a real base image strategy.

The way I’d think about it:

If your org is trying to standardize on hardened bases, golden images, or “platform-owned” base layers, this feature nudges you toward treating ECR more like an internal artifact platform instead of a dumb image bucket.

And if you’re not at that scale yet, it’s still a good forcing function question:

Do we want every team reinventing base images, or do we want a small set of blessed bases with fast patch propagation?

Because that decision shows up later as incident load and vuln backlog.

Human story: Honeycomb’s EU outage write-up

This was my favorite part of the week, because it’s honest in the way good postmortems are honest.

I’m paraphrasing, but the vibe is: “we had safety mechanisms, and we had automation, and under the wrong conditions those mechanisms amplified the failure instead of containing it.”

That’s a super common operations failure mode. You build a bunch of protections:

• retries
• autoscaling
• circuit breakers
• queue backpressure
• regional failover logic

…and then a specific combination happens, and the system behaves “correctly” according to each local component, but globally it’s chaos.

My big takeaway from their write-up:

Resilience controls are code.
If they aren’t exercised, observed, and periodically broken on purpose, you don’t really know what you built.

This is the part people miss. Teams will do game days for application failure, but they won’t game day their safety systems. Then the first time a real edge case happens, the “recovery lever” snaps off in your hand.

A really practical thing you can steal from this kind of outage story:

Pick one resilience feature you rely on (autoscaling, retry policies, failover, rate limiting, feature flags) and ask:

• What’s the expected behavior?
• What’s the worst-case behavior?
• How would we notice it drifting into worst-case before it’s too late?

Even a half-assed answer is better than discovering it live.

Why these stories together

If you’re an SRE/platform/DevOps person, your job is basically “make the human part sustainable.”

That means:

• keep inputs high-signal (curl bounty story)
• reduce blast radius when change happens (RDS blue/green story)
• standardize the boring stuff so patching and shipping is faster (ECR layer sharing story)
• and actually test the guardrails you think you have (Honeycomb outage story)

Same theme, different layer.

If you want links beyond the show notes, here are the sources I pulled from for this episode:

• curl bug bounty / AI slop context: curl PR + discussions around the change
• AWS announcements: RDS blue/green improvements and ECR cross-repository layer sharing from AWS “What’s New”
• Honeycomb outage: the SRE Weekly link for the EU outage write-up (and the write-up itself)

If you’re reading this on shipitweekly.fm, the episode page has the show notes links, and you can always hit follow/subscribe wherever you’re listening. Ratings help a stupid amount, even though it feels like yelling into the void.

See you next week.

This episode is a pretty direct sequel to Episode 12, but with an important twist.

Episode 12 was “Ni8mare” (CVE-2026-21858): unauthenticated paths that can turn “it’s just a workflow tool” into “why is this box doing weird stuff.” The new one this week (CVE-2026-21877) is authenticated RCE, which sounds less scary until you remember what “authenticated” means in real life: a compromised account, a leaked token, a contractor account you forgot about, or a teammate with more access than they should have. Different entry point, same end state: the automation layer can become an execution layer.

So the theme for Episode 14 is basically: workflow automation tools are production-adjacent systems now. Treat them that way.

For n8n specifically, the right framing isn’t “do we use it?” It’s “what’s the blast radius if it goes sideways?”

If you self-host n8n, your risk is largely shaped by deployment choices:
If it can reach internal networks, it’s not “just automation,” it’s a pivot point.
If it has secrets sitting in it, it’s not “just workflows,” it’s a credential broker.
If lots of people can create/modify workflows, it’s not “just productivity,” it’s distributed code execution.

And yes, mitigations like disabling the Git node and locking down who can create/modify workflows are real, but they’re the seatbelt, not the airbag. Upgrading is the fix.

The part I want to underline is that this isn’t an “n8n is bad” story. This is an “automation is changing the shape of the threat model” story. We used to worry about the app, the cluster, the pipeline. Now we also have to worry about the tools that orchestrate work across all of those, because they sit right in the middle of everything.

That ties into the GitHub stories really cleanly.

The new artifact_metadata permission is one of those changes that looks like a tiny GitHub Actions footnote, but it matters because it lets you stop handing out broad contents:read or contents:write just to query artifact metadata APIs. This is classic “least privilege catches up to reality.” If your org has been slowly tightening Actions permissions, this is a nice win.

And secret scanning extended metadata auto-enabling (when you already have validity checks enabled via security configurations) is another example of the control plane getting “smarter by default.” It’s helpful, but it’s also a governance moment: teams wake up to more context in alerts, more information to triage, and more expectation that security findings get handled like operational work, not “security’s problem.”

Now the agent angle.

I didn’t want to turn this episode into “AI tool drama,” but that Claude Code issue thread is a good reminder of why agents need guardrails and why tool choice matters. The punchline isn’t who’s right. The punchline is: once agents are part of your workflow, identity and authorization become the whole game. What credentials can the agent use? Where can it run? What actions can it take? And what happens when people start routing around the “official” paths to get work done faster?

That’s where Goose and OpenCode are actually useful stories, not just “cool tools.”

Block’s Goose docs are basically showing the industry moving from “chat with an LLM” to “operate an agent with sessions, context management, and repeatable workflows.” That’s the boring, real-world part that matters. When you operationalize agents, you need lifecycle, history, and constraints, or you get chaos.

OpenCode is the other side of the same coin: an “agent runner” pattern, where the value isn’t just the model, it’s the harness. How you run it, where you run it, what tools it can call, and what permissions it gets. If you’re experimenting with agents at work, this is the pattern to steal: separate the agent harness from production credentials, put it in a sandbox, and make it earn trust before it touches real infra.

My practical takeaway for this whole episode is simple:

If a tool can run workflows, open PRs, touch CI, or reach internal services, it deserves the same controls you’d put around any other production system. Network boundaries. Least privilege. Audit logs. Rate limits. And a very explicit answer to “what’s the blast radius if this gets popped?”

Because “automation layer” used to mean convenience.
Now it means control plane.

Links (main + extra)

Episode 12 (Ni8mare / CVE-2026-21858 context): Episode 12Jan 9, 2026⏱️ 16:18n8n Critical CVE (CVE-2026-21858), AWS GPU Capacity Blocks Price Hike, Netflix TemporalEpisode: n8n Critical CVE (CVE-2026-21858), AWS GPU Capacity Blocks Price Hike, Netflix Temporal

n8n CVE-2026-21877 (authenticated RCE, fixed in 1.121.3): https://www.tenable.com/cve/CVE-2026-21877

n8n community thread re: Ni8mare CVE-2026-21858 (fixed in 1.121.0): https://community.n8n.io/t/ni8mare-cve-2026-21858/250595

GitHub: artifact_metadata permission GA (deprecating old contents usage for artifact metadata APIs on Feb 3, 2026): https://github.blog/changelog/2026-01-13-new-fine-grained-permission-for-artifact-metadata-is-now-generally-available

GitHub: secret scanning extended metadata checks auto-enabled (if validity checks already enabled via security configurations) starting Feb 18, 2026: https://github.blog/changelog/2026-01-15-secret-scanning-extended-metadata-to-be-automatically-enabled-for-certain-repositories

Claude Code issue thread (guardrails + credentials + tool friction): https://github.com/anthropics/claude-code/issues/17118

OpenCode (agent runner): https://opencode.ai/
OpenCode GitHub: https://github.com/opencode-ai/opencode

Block Goose session/context management (operationalizing agent workflows): https://block.github.io/goose/docs/guides/sessions/smart-context-management/