Back to all episodes
PeopleSoft Zero-Day Exploited, npm v12 Install Script Changes, GitHub Agentic Tokens, Anthropic Model Risk, and Default Trust Breaking
This episode of Ship It Weekly discusses the risks of default trust in software systems. Brian covers Oracle's PeopleSoft zero-day, npm v12's install-script changes, GitHub's shift away from personal access tokens, and Anthropic's AI model removals.
PeopleSoft Zero-Day Exploited, npm v12 Install Script Changes, GitHub Agentic Tokens, Anthropic Model Risk, and Default Trust Breaking
Ship It Weekly
0:00
22:27
Transcript
0:00
PeopleSoft gets hit by a zero-day. npm changes
0:03
what code is allowed to run during install. GitHub
0:07
removes long-lived personal access tokens from
0:11
agentic workflows. And Anthropic reminds everyone
0:14
that your AI dependency can disappear for reasons
0:18
that have nothing to do with uptime. The theme
0:21
this week is simple. Default trust is getting
0:24
punished. Old enterprise systems were trusted.
0:28
because they were internal. Package installs
0:31
were trusted because that is just how the ecosystem
0:33
worked. CI/CD tokens were trusted because they
0:37
were convenient. AI models were trusted because
0:41
the API worked yesterday. But production does
0:44
not care why you trusted something. It only cares
0:47
what that trust was allowed to do. I'm Brian
0:50
Teller from Teller's Tech, and this is Ship It
0:53
Weekly. Welcome back to Ship It Weekly, the show
1:13
where we look at the DevOps, SRE, cloud, platform,
1:18
and security stories that actually matter when
1:21
you are the person who eventually has to keep
1:23
the thing running. This week is about default
1:26
trust. We're starting with Oracle PeopleSoft
1:29
and a zero-day that was reportedly exploited
1:32
before Oracle released an emergency patch. Then
1:35
we'll talk npm v12. changing install-script
1:39
defaults which is great for supply-chain security
1:42
and maybe a little annoying for some CI pipelines
1:45
after that we'll get into github agentic workflows
1:49
no longer needing personal access tokens which
1:53
is the kind of boring credential change that
1:56
actually matters then we'll talk about Anthropic
1:59
disabling fable 5 and mythos 5 after a us export
2:04
control directive because AI model availability
2:07
is now also a policy-risk dependency. In the
2:11
lightning round, we'll hit Tekton CloudEvents
2:14
moving to a dedicated events controller, NVIDIA
2:17
Triton 26.04 changing inference server defaults,
2:21
AWS Nitro Isolation Engine using formal verification,
2:26
and Homebrew 6.0 requiring explicit trust for
2:30
third-party taps. The human closer this week
2:33
is about trust defaults, because a lot of incidents
2:37
start with one quiet assumption. The system is
2:40
internal. The package is fine. This token is
2:44
safe. This model will be there tomorrow. And
2:47
sometimes that assumption is the real production
2:50
dependency. So let's get into it. Oracle issued
2:59
an emergency advisory for CVE-2026-35273 in
3:05
PeopleSoft PeopleTools. And yes, I know, PeopleSoft
3:09
does not sound like the kind of shiny cloud-native
3:12
story that makes people sprint to the podcast
3:15
app. But that is exactly why it matters. A lot
3:18
of modern companies still depend on older enterprise
3:21
systems for HR, finance, payroll, student records,
3:26
supply-chain. and all the boring data that becomes
3:29
extremely exciting when attackers get it. Oracle
3:32
says that the vulnerability is remotely exploitable
3:35
without authentication and can result in remote
3:39
code execution. Public reporting says exploitation
3:42
was observed before Oracle's emergency advisory,
3:46
with ShinyHunters linked activity targeting
3:49
mostly U.S. organizations, especially higher
3:52
education. So the shape of the story is pretty
3:55
clear. Old enterprise application, sensitive
3:57
data, remote unauthenticated exploit, active
4:01
exploitation, emergency patch. That is a bad
4:04
combination. And the lesson for DevOps, SRE,
4:07
platform, and cloud teams is not just patch PeopleSoft.
4:11
Although, yes, obviously, patch PeopleSoft. The
4:14
bigger lesson... is that the enterprise app tier
4:17
is still part of your perimeter, even if everyone
4:20
emotionally moved on to Kubernetes. A lot of
4:23
teams have a weird relationship with older enterprise
4:26
platforms. They are important enough that nobody
4:30
can turn them off, but old enough that nobody
4:33
really wants to own them. They live in a special
4:36
network zone. They have a special upgrade window.
4:39
They have special vendor requirements. They have
4:42
special firewall rules. from 2017 that everyone
4:46
is afraid to touch. And somehow, because they
4:49
are enterprise apps, people stop thinking of
4:52
them like internet-exposed production systems.
4:55
Attackers do not care what generation of architecture
4:58
the system belongs to. They care whether it has
5:01
data, access, and a path in. PeopleSoft may not
5:05
be the cool part of your stack, but if it holds
5:08
HR data, finance data, student data, employee
5:12
data, or business workflow data, it is very much
5:16
part of your attack surface. This is also a good
5:19
reminder that legacy does not mean low-priority.
5:23
Sometimes legacy means high-value, hard-to-patch,
5:26
badly isolated, and full of data. That is not
5:30
low-priority. That is where an attacker brings
5:33
a shovel. The practical takeaway is simple. Know
5:36
where these systems are. Know whether they are
5:39
internet exposed. Know who owns patching. Know
5:42
who owns logs. Know what normal access looks
5:46
like. Know whether unusual agents, web shells,
5:50
or scheduled tasks would actually be noticed.
5:53
And if you are a platform or cloud team that
5:57
thinks this is someone else's problem, be careful.
6:00
Because during the incident call, someone else's
6:03
problem has a funny way of becoming why did nobody
6:07
know this existed. Your ERP systems, HR systems,
6:11
finance systems, and admin portals are production
6:15
systems. Treat them that way. Second story. npm
6:24
v12 is changing some defaults around install
6:27
scripts. And this one matters to developers,
6:30
platform teams, CI maintainers, security teams,
6:34
and anyone who has ever watched an npm install
6:37
do 12 things they did not explicitly ask it to
6:40
do. GitHub says npm v12 is expected in
6:44
July 2026. And one of the big breaking changes
6:48
is that allowScripts will default to off. That
6:51
means npm install will no longer execute pre
6:55
-install, install, or postinstall-scripts from
6:59
dependencies unless they are explicitly allowed.
7:02
Prepare scripts from git, file, and link dependencies
7:06
are blocked the same way. These settings are
7:09
already available in npm 11.16.0 for migration
7:14
testing. This is a big ecosystem shift. For years,
7:18
npm install has been more powerful than people
7:22
like to admit. You run the package install. The
7:25
package runs code. That code might build native
7:28
bindings, download binaries, generate files.
7:32
patch something, bootstrap something, do the
7:35
magic that makes everything work. But that same
7:38
install-time execution path is also a supply
7:41
chain attack surface. A malicious package does
7:45
not need your app to import it at runtime if
7:48
it can run code during install. It only needs
7:51
to land in the dependency tree. Then the CI runner,
7:54
developer laptop, or build machine does the rest.
7:58
This is why this change matters. It moves the
8:01
ecosystem from implicit trust towards explicit
8:04
trust. And yes, that is good. But some builds
8:07
are going to break. Because a lot of pipelines
8:10
have been relying on install-time magic without
8:14
documenting it. Native modules. Post install
8:17
downloads. Git dependencies. File dependencies.
8:21
Link dependencies. Internal packages. Packages
8:24
that compile. Packages that generate code. Packages
8:27
that do one tiny little install step that nobody
8:31
has looked at since the person who wrote it left
8:34
the company. Those assumptions are about to become
8:36
visible. And visibility is great. Right after
8:40
it ruins your Tuesday. The practical takeaway
8:42
is not panic about npm v12. The takeaway
8:46
is to test early. Run builds with the new behavior
8:49
before it becomes the default. Find which dependencies
8:54
need scripts. Decide which scripts you actually
8:57
trust. Document why. And do not just flip everything
9:01
back on because one pipeline failed. That defeats
9:05
the point. This is a chance to clean up dependency
9:07
trust, especially in CI. Ask what install-scripts
9:11
run today. Ask whether CI runners have secrets
9:14
available during install. Ask whether build steps
9:18
can reach internal services. Ask whether developers
9:21
are running installs on machines with cloud credentials,
9:24
SSH keys, or package publishing rights. Because
9:28
the blast radius of an install-script is not
9:31
just the package. It is whatever the install
9:34
environment can access. I like this change. It
9:37
is going to annoy people, but sometimes the annoying
9:40
default is the correct default. npm install is
9:43
finally getting less magical. And that means
9:46
that some teams are about to discover how much
9:49
magic they were depending on. Third story. GitHub
9:56
says agentic workflows no longer need a personal
10:00
access token. And yes, that sounds boring. But
10:03
boring credential changes are often the ones
10:06
that save you later. Previously, agentic workflows
10:08
needed personal access tokens in certain setups.
10:12
Now GitHub says, These workflows can use the
10:15
built-in GITHUB_TOKEN and the copilot
10:18
request write permission instead. The point is
10:21
to avoid creating and storing long-lived personal
10:24
access tokens for agentic workflows. This matters
10:28
because agentic CI/CD is already risky enough.
10:32
These workflows can read context, generate changes,
10:36
open pull requests, review code, call tools,
10:39
interact with repo state, and eventually, in
10:43
some environments, they may become part of release,
10:46
remediation, triage, or automation paths. So
10:50
the credentials they use matter a lot. A personal
10:53
access token is often tied to a person. It may
10:56
be long-lived. It may have broad permissions.
10:59
It may sit in secrets. It may get copied between
11:03
repos. It may survive longer than anyone intended.
11:06
It may still exist after the workflow changed,
11:09
the person changed teams, or everyone forgot.
11:13
why the token was created. That is not a great
11:16
pattern for agentic automation. A scoped workflow
11:19
token is not magic. You still have to configure
11:22
it correctly. You still have to review permissions.
11:25
You still have to think about which events can
11:28
trigger the workflow. You still have to worry
11:30
about untrusted input. But it is a better default
11:34
than handing an agent a long-lived personal
11:37
credential and hoping everyone remembers where
11:40
it lives. The platform takeaway is simple. If
11:42
you are experimenting with agentic workflows
11:45
in GitHub, review the whole trust model. What
11:48
repos can run it? What events can trigger them?
11:52
What permissions do they get? Can pull request
11:54
content influence the agent? Can issue comments
11:58
influence the agent? Can the agent write code?
12:01
Can it approve changes? Can it call external
12:04
tools? Can it see secrets? Can it publish artifacts?
12:08
Can it affect production? And are you still using
12:11
personal access tokens where you do not need
12:14
them? Because agents are not just assistants
12:17
once they enter CI/CD. They become automation
12:20
services. And automation surfaces need boring,
12:24
strict, reviewable credentials. So yes, use the
12:28
better GitHub auth model. But do not stop there.
12:31
If it can change code, trigger work, or spend
12:34
money, it belongs in your production automation
12:37
threat model. Fourth story. Anthropic published
12:45
a statement saying that the U.S. government
12:47
issued an export-control directive requiring
12:50
Anthropic to suspend access to Fable 5 and Mythos
12:54
5 by any foreign national, whether inside or
12:58
outside the United States, including foreign
13:01
national Anthropic employees. Anthropic said
13:03
that the net effect was that it had to abruptly
13:06
disable Fable 5 and Mythos 5 for all customers.
13:11
to ensure compliance. Access to other Anthropic
13:14
models was not affected. Now, this is not a normal
13:17
SRE outage. There was not a regional failure.
13:20
There was not a bad deploy. There was not a database
13:24
incident. There was not a capacity problem. But
13:27
for customers who depend on those models, the
13:30
effect is still operational. The dependency disappeared.
13:33
and it disappeared for policy reasons. That is
13:36
the lesson. If AI APIs are part of your production
13:40
path, dependency risk is no longer just uptime,
13:43
latency, quota, and cost. It is also model availability,
13:48
geography, export-controls, regulatory shifts,
13:52
vendor policy, safety policy, commercial access,
13:56
model deprecation, compliance interpretation,
13:59
and whatever new category we invent next quarter.
14:02
This is uncomfortable because AI dependencies
14:05
can be harder to substitute than people pretend.
14:09
You can usually swap one HTTP endpoint for another
14:13
at a code level. But can you swap the behavior,
14:17
the context window, the latency, the tool calling
14:21
behavior, the moderation behavior, the cost profile,
14:24
the prompt format, the eval results, the customer
14:28
experience, the internal workflow? The fallback
14:31
may not be use a different model. The fallback
14:34
may be a degraded mode, a smaller model, a cached
14:38
response, a human review queue, a simpler workflow,
14:42
a feature flag, a regional restriction, or a
14:46
message that says this capability is temporarily
14:49
unavailable. Boring fallback behavior is better
14:53
than waking up to discover your product path
14:56
depends on a model that is no longer available
14:59
to you. The practical takeaway is to add AI models
15:03
to your dependency register like any other production
15:06
dependency. Track which features use which model.
15:10
Track whether the model is in a critical path.
15:13
Track where your users are. Track fallback options.
15:17
Track whether you can degrade gracefully. Track
15:20
whether a vendor-side access change would be
15:23
an incident. And test the fallback. Do not just
15:27
write... Fall back to another model in a doc
15:30
and call it done. Actually try it. Because the
15:34
weird thing about AI infrastructure is that even
15:37
when the API shape looks portable, the behavior
15:40
is not. Your AI dependency can disappear for
15:43
reasons that have nothing to do with uptime.
15:46
That means your reliability plan needs to cover
15:50
more than outages. Now let's do a quick lightning
16:00
round. First, Tekton pipelines changed how cloud
16:03
events are sent. Cloud events for PipelineRuns
16:07
and TaskRuns now move through a dedicated Tekton
16:11
events controller instead of the core pipeline
16:14
run and task run controllers. That means operators
16:17
need to make sure the tekton-events-controller
16:20
deployment is actually running. Small looking
16:23
platform changes like this can have real operational
16:26
impact. If CI/CD observability, event routing,
16:31
notifications, or automation depends on Tekton
16:34
events, make sure the new controller is deployed,
16:37
monitored, and part of the upgrade checklist.
16:41
Because the pipeline ran, but the event never
16:43
showed up, is exactly the kind of thing that
16:46
sends teams into Slack archaeology. Second, NVIDIA
16:50
Triton Inference Server 26.04 has changes operators
16:55
should read before upgrading. Client shared memory
16:59
is now disabled by default and must be enabled
17:02
explicitly if you rely on the old behavior. Triton
17:06
also enforces max inflight requests as a shared
17:10
limit across ensemble requests, which is meant
17:13
to prevent unbounded queue growth in ensemble
17:16
pipelines. The short version is this. AI inference
17:19
servers are now normal platform infrastructure.
17:23
Defaults change. queue behavior changes, memory
17:26
behavior changes, model control changes. So upgrade
17:30
them like production systems, not sidecar experiments.
17:33
Third, AWS published a deep dive on the Nitro
17:37
Isolation Engine. AWS says the Nitro Isolation
17:41
Engine is generally available on Graviton5-based
17:45
instances and uses formal verification to demonstrate
17:49
isolation properties. That is interesting because
17:52
cloud isolation is usually something customers
17:55
trust, but cannot directly inspect. Formal verification
17:59
does not mean bugs are impossible, but it does
18:03
show where cloud providers are heading. Smaller
18:06
trusted components, tighter isolation boundaries,
18:08
and mathematically checked properties for the
18:11
parts that protect customer workloads. Fourth,
18:14
Homebrew 6.0 introduced tap trust. Homebrew
18:18
now requires explicit trust. for third-party
18:21
taps before evaluating or running their Ruby
18:25
code, while official taps remain trusted by default.
18:29
This is another supply-chain default, changing
18:32
from sure, run it, to are you sure you trust
18:35
this? And that is good. A third-party tap can
18:38
contain arbitrary Ruby. If your developer laptops,
18:41
CI runners, or bootstrap scripts use Homebrew,
18:45
This change is worth knowing about. Some installs
18:48
may prompt or fail until trust is explicit. That
18:52
might annoy people. But again, that is the point.
18:55
Developer tooling is part of the supply-chain.
18:58
And fewer things should get to run code just
19:01
because they were convenient. The human closer
19:12
this week is about default trust. PeopleSoft
19:15
was trusted because it was an enterprise system
19:18
that had been around forever. npm install was
19:22
trusted because package managers have always
19:25
done some magic. agentic workflows were trusted
19:27
with personal tokens because that was the easy
19:30
path. AI models were trusted because the API
19:34
was available yesterday. Tekton events were trusted
19:37
to keep flowing. Triton defaults were trusted
19:40
until they changed. Cloud isolation was trusted
19:43
because that is the cloud model. Homebrew taps
19:46
were trusted because developer tooling has historically
19:50
been pretty casual about running code. Different
19:54
stories, same pattern. Production risk often
19:57
hides inside the trust defaults nobody has revisited.
20:01
The system is internal. The install-script is
20:04
normal. The token is convenient. The model will
20:07
be available. the event will fire the tap is
20:11
probably fine those assumptions may be true until
20:15
they are not so the practical question this week
20:18
is simple what are you trusting by default which
20:22
enterprise apps are still exposed which package
20:26
installs run code in ci which agents still use
20:30
long-lived tokens which ai models sit in production
20:34
paths which developer tools can execute code
20:38
before anyone reviews it that is platform work
20:42
now not just building the shiny new thing but
20:45
revisiting the old trust assumptions before attackers
20:48
vendors regulators or outages revisit them for
20:52
you find the defaults then decide whether they
20:56
still deserve your trust That's it for this week
20:59
of Ship It Weekly. We covered the Oracle PeopleSoft
21:02
zero-day, npm v12 install-script changes,
21:06
GitHub agentic workflows moving away from personal
21:09
access tokens, Anthropic's Fable and Mythos model
21:13
suspension, and a lightning round on Tekton,
21:16
NVIDIA Triton, AWS Nitro Isolation Engine, and
21:20
Homebrew 6.0 tap trust. If this episode was
21:24
useful, follow or subscribe wherever you are
21:26
watching or listening. If you are on YouTube,
21:29
hit subscribe. If you're in a podcast app, follow
21:32
the show there. And if you know someone dealing
21:35
with enterprise app security, CI/CD supply-chain
21:38
risk, agentic workflows, AI dependency planning,
21:42
or developer tool trust, send this one to them.
21:45
It helps the show grow, and it helps me keep
21:48
making this kind of content for people who actually
21:51
live with these systems. You can find the weekly
21:53
brief at OnCallBrief.com, and more episodes
21:57
and show notes at shipitweekly.fm. I'm Brian
22:00
Teller from Teller's Tech. Thanks for listening.
22:03
And remember, production does not care why you
22:06
trusted the default. It only cares what that
22:09
default was allowed to do.
PeopleSoft Zero-Day Exploited, npm v12 Install Script Changes,…
0:00 / 22:27
🎧 Listen & Subscribe
Catch This Episode
Listen on your favorite podcast platform
💬 Commentary
Host Commentary
📝 Notes
Show Notes
This episode of Ship It Weekly is about default trust getting punished. Brian covers Oracle’s emergency PeopleSoft advisory for CVE-2026-35273, npm v12 changing install-script defaults, GitHub Agentic Workflows moving away from long-lived personal access tokens, and Anthropic disabling Fable 5 and Mythos 5 after a U.S. export-control directive. The common thread: legacy ERP systems, package installs, CI/CD agents, and AI models all become production risks when teams trust the default without checking what that trust can actually do.
In the lightning round, Brian covers Tekton CloudEvents moving to a dedicated events controller, NVIDIA Triton Inference Server 26.04 changing inference defaults, AWS Nitro Isolation Engine bringing formal verification to Graviton5-based isolation, and Homebrew 6.0 adding explicit trust for third-party taps. The bigger theme: production does not care why you trusted the default. It only cares what that default was allowed to do.
The bigger theme: production does not care why you trusted the default. It only cares what that default was allowed to do.
Links
Oracle PeopleSoft CVE-2026-35273 advisory https://www.oracle.com/security-alerts/alert-cve-2026-35273.html
npm v12 breaking changes https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/
GitHub Agentic Workflows no longer need PATs https://github.blog/changelog/2026-06-11-agentic-workflows-no-longer-need-a-personal-access-token/
Anthropic Fable 5 / Mythos 5 access statement https://www.anthropic.com/news/fable-mythos-access
Tekton Pipelines releases https://github.com/tektoncd/pipeline/releases
NVIDIA Triton Inference Server 26.04 release notes https://docs.nvidia.com/deeplearning/triton-inference-server/release-notes/rel-26-04.html
AWS Nitro Isolation Engine https://aws.amazon.com/blogs/compute/aws-nitro-isolation-engine-formally-verifying-the-hypervisor-in-the-aws-nitro-system/
Homebrew 6.0.0 https://brew.sh/2026/06/11/homebrew-6.0.0/
This week’s On Call Brief https://www.tellerstech.com/on-call-brief-news/2026-W25/
More episodes and show notes https://shipitweekly.fm/
📍 Made in Greencastle, Pennsylvania
More from Ship It Weekly
All episodes →
Coinbase Outage, Meta AI Account Recovery, AWS AgentCore Code Injection, Apigee Tenant Isolation, and the Glue That Breaks Production
This episode of Ship It Weekly discusses critical infrastructure failures and their implications. Brian analyzes Coinbase's outage due to an AWS cooling failure, Meta's AI-driven account recovery issues, and vulnerabilities in AWS AgentCore and Google Apigee.
Kiro CLI Approval Bypass, Amazon Braket Pickle Risk, AWS Org Logging, KEDA Upgrades, and Automation’s Hidden Boundaries
This episode of Ship It Weekly explores automation's hidden boundaries, focusing on Kiro CLI's CVE-2026-9255 approval bypass and Amazon Braket's Python pickle risk.
GitHub Supply Chain Attacks, Railway’s GCP Outage, Discord’s Voice Failure, AWS Retry Changes, and Trusted Tool Risk
This episode of Ship It Weekly discusses the growing risks of trusted tools in production, highlighted by a GitHub supply chain attack involving a compromised VS Code extension.
Ship It Conversations: Jake Warner on Cycle.io, Bare Metal’s Comeback, and Why Private Cloud Is Getting Interesting Again
In this episode, Jake Warner of Cycle.io discusses the resurgence of bare metal and private cloud, emphasizing their benefits in cost, performance, and compliance.
This episode is about default trust getting punished.
That sounds a little dramatic, but it is the thread that connects all of these stories.
PeopleSoft was trusted because it was an enterprise system that had been around forever.
npm install scripts were trusted because that is just how the ecosystem worked.
GitHub agentic workflows were trusted with personal access tokens because that was the easy path.
AI models were trusted because the API worked yesterday.
Tekton events were trusted to keep flowing.
Triton defaults were trusted until they changed.
Homebrew taps were trusted because developer tooling has historically been pretty casual about running code.
Different stories, same pattern.
Production risk often hides inside the defaults nobody has revisited.
The PeopleSoft story is the loudest example. Oracle issued an emergency advisory for CVE-2026-35273 in PeopleSoft PeopleTools, a remotely exploitable unauthenticated vulnerability that Oracle says can lead to remote code execution.
And yes, PeopleSoft is not exactly the trendiest infrastructure topic in the world.
But that is kind of the point.
A lot of the systems that hold the most sensitive business data are not the shiny new systems. They are the old enterprise platforms that sit somewhere in the corner of the architecture diagram with an owner nobody wants to bother too much.
HR systems.
Finance systems.
Payroll systems.
Student record systems.
ERP platforms.
Admin portals.
The stuff that feels boring until someone steals data from it.
The mistake teams make is treating “legacy” as if it means “less important.” Sometimes legacy means high-value, hard-to-patch, full of data, and surrounded by years of network exceptions nobody wants to touch.
That is not low priority. That is a great place for attackers to dig.
The takeaway is not just “patch PeopleSoft,” although obviously, yes, patch PeopleSoft. The larger takeaway is that enterprise app tiers are still production systems. They still need ownership, logging, patching, access review, exposure review, and incident response coverage.
Even if everyone emotionally moved on to Kubernetes.
The npm v12 change is the same idea in a different place.
For years, npm install has been more powerful than people like to admit. You install a package, and that package can run code during install. Sometimes that code builds native bindings. Sometimes it downloads binaries. Sometimes it generates files. Sometimes it does the little bit of magic that makes a build work.
But that same magic is also a supply-chain attack surface.
A malicious package does not need your application to import it at runtime if it can execute during install. It only needs to land in the dependency tree. Then the developer laptop, CI runner, or build machine does the rest.
That is why npm v12 changing install-script defaults matters. Moving from implicit trust toward explicit trust is a good security direction. But it is also going to reveal how many pipelines quietly depended on install-time behavior that nobody documented.
That is the uncomfortable but useful part.
Some builds are probably going to break. Some packages will need explicit trust. Some internal assumptions will become visible. And while that is annoying, it is also an opportunity to ask better questions.
Which install scripts run today?
Which ones actually need to run?
Which ones do we trust?
Do our CI runners have secrets available during install?
Can install-time code reach internal systems?
Are developers running installs on machines with cloud credentials, SSH keys, or publishing rights?
The blast radius of an install script is not just the package. It is whatever the install environment can access.
GitHub’s agentic workflow change is another trust default shifting in the right direction.
Agentic workflows no longer needing long-lived personal access tokens sounds boring, but boring credential changes are often the ones that save you later.
Long-lived PATs are convenient, but they are also messy. They are tied to people. They get copied. They sit in secrets. They outlive their original purpose. They survive team changes, repo changes, workflow changes, and organizational memory.
That is already not ideal for normal automation.
It is worse for agentic workflows.
Once agents enter CI/CD, they are not just assistants. They are automation surfaces. They can read repo context, react to issues or pull requests, generate changes, open PRs, call tools, and potentially become part of release, remediation, or triage paths.
So the identity they run under matters a lot.
Moving toward scoped workflow permissions and GitHub Actions tokens is a better default than handing agents long-lived personal credentials. But it does not remove the need for a threat model.
You still need to ask what repos can run these workflows, what events trigger them, what permissions they get, whether issue or pull request content can influence them, and whether they can see secrets, publish artifacts, or affect production.
The update is good.
The bigger lesson is that agentic CI/CD belongs in the same production automation review process as anything else that can change code, trigger work, or spend money.
The Anthropic story is the weirdest one because it is not a traditional outage.
There was no bad deploy.
No regional failure.
No database incident.
No capacity problem.
But Fable 5 and Mythos 5 still became unavailable to customers after a U.S. export-control directive.
For anyone depending on those models, the operational effect is still real.
The dependency disappeared.
Just not for an uptime reason.
That is the part platform and reliability teams need to absorb.
AI dependencies are not only API dependencies anymore. They are also policy dependencies, geography dependencies, vendor dependencies, compliance dependencies, model availability dependencies, and probably a few more categories we have not named yet.
A fallback plan for AI cannot just say “use a different model” unless someone has actually tested that.
Can you swap the behavior?
The context window?
The latency?
The cost profile?
The tool-calling behavior?
The prompt format?
The eval results?
The moderation behavior?
The user experience?
Sometimes the fallback is a different model. Sometimes it is degraded mode. Sometimes it is cached output. Sometimes it is a human review queue. Sometimes it is a feature flag that disables a workflow before it breaks the product.
That sounds boring.
But boring fallback behavior beats waking up to discover your product depends on a model you can no longer access.
The lightning round kept reinforcing the same point.
Tekton CloudEvents moving to a dedicated events controller is not a giant story, but it matters if your CI/CD observability or automation depends on those events. Small platform changes can break the glue.
NVIDIA Triton changing defaults around shared memory and queue behavior is another reminder that AI inference servers are now normal production infrastructure. Defaults change. Resource behavior changes. Model control changes. Upgrade them like production systems, not experiments.
AWS Nitro Isolation Engine and formal verification is about cloud trust getting more explicit. Customers still cannot inspect everything underneath their workloads, but the platform is moving toward more clearly defined and mathematically checked isolation boundaries.
Homebrew 6.0 tap trust is another supply-chain default getting stricter. Third-party developer tooling can run code too, and developer tooling is part of the software supply chain whether teams admit it or not.
That is the bigger theme of the episode.
Defaults are not neutral.
They are decisions someone made for convenience, compatibility, usability, or speed.
Sometimes those defaults are still right.
Sometimes they are outdated.
Sometimes they are dangerous.
And sometimes nobody knows because nobody has looked at them in years.
That is the platform work hiding underneath this whole episode.
Not just building new systems.
Not just adopting new tools.
Not just patching the obvious CVE.
But asking what your organization trusts by default.
Which enterprise apps are still exposed?
Which package installs run code in CI?
Which agents still use long-lived tokens?
Which AI models sit in production paths?
Which developer tools can execute code before anyone reviews them?
Which event pipelines are assumed to keep working?
Which cloud isolation guarantees are you relying on?
Those questions are not flashy, but they are where a lot of real production risk lives.
The takeaway from this episode is simple:
Find the defaults.
Then decide whether they still deserve your trust.
Extra links worth including on the episode page:
Oracle PeopleSoft CVE-2026-35273 advisory
https://www.oracle.com/security-alerts/alert-cve-2026-35273.html
Oracle PeopleSoft CVE-2026-35273 risk matrix
https://www.oracle.com/security-alerts/cve-2026-35273verbose.html
npm v12 breaking changes
https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/
GitHub Agentic Workflows no longer need PATs
https://github.blog/changelog/2026-06-11-agentic-workflows-no-longer-need-a-personal-access-token/
GitHub Agentic Workflows authentication docs
https://github.github.com/gh-aw/reference/auth/
Anthropic Fable 5 / Mythos 5 access statement
https://www.anthropic.com/news/fable-mythos-access
Tekton Pipelines releases
https://github.com/tektoncd/pipeline/releases
NVIDIA Triton Inference Server 26.04 release notes
https://docs.nvidia.com/deeplearning/triton-inference-server/release-notes/rel-26-04.html
AWS Nitro Isolation Engine
https://aws.amazon.com/blogs/compute/aws-nitro-isolation-engine-formally-verifying-the-hypervisor-in-the-aws-nitro-system/
Homebrew 6.0.0
https://brew.sh/2026/06/11/homebrew-6.0.0/
This week’s On Call Brief
https://www.tellerstech.com/on-call-brief-news/2026-W25/
More Ship It Weekly episodes
https://shipitweekly.fm/