Kiro CLI Approval Bypass, Amazon Braket Pickle Risk, AWS Org Logging, KEDA Upgrades, and Automation’s Hidden Boundaries

Transcript

0:00 Your AI coding tool asks for permission. Then

0:02 stdin answers for you. That is not a sentence

0:06 I expected to say this week, but here we are.

0:08 This week, we've got Kiro CLI with an approval

0:12 bypass through piped input. Amazon Braket with

0:15 a very normal Python pickle problem inside a

0:18 very expensive-sounding quantum SDK. AWS Organizations

0:23 finally logging account membership changes to

0:26 CloudTrail. And KEDA releases that remind us

0:29 autoscaling upgrades are not just version bumps.

0:32 Then in the lightning round, we'll hit Kubernetes

0:35 dashboard being archived, Google Cloud's managed

0:38 MCP server for AlloyDB, Kafka 4.3 .0, and Atlassian's

0:44 AI productivity claims around more pull requests

0:47 and saved developer time. The theme this week

0:51 is pretty simple. Automation keeps getting more

0:54 authority, but the boring boundaries still decide

0:57 what happens. I'm Brian Teller from Teller's

0:59 Tech, and this is Ship It Weekly. Welcome back

1:18 to Ship It Weekly. The show where we look at

1:21 the DevOps, SRE, cloud, platform, and security

1:25 stories that actually matter when you are the

1:28 person who eventually has to keep the thing running.

1:31 This week is a nice mix of AI tooling risk, cloud

1:34 governance, Kubernetes operations, and the ongoing

1:37 question of what happens when automation gets

1:41 more power than people realize. We're starting

1:44 with Kiro CLI and a bug where crafted piped

1:47 input could be treated like user approval. Then

1:50 we'll talk about Amazon Braket SDK and an insecure

1:54 deserialization issue in quantum job results.

1:58 After that, we'll get into AWS Organizations

2:01 finally emitting CloudTrail events when accounts

2:04 join or leave an organization. Then we'll talk

2:07 KEDA 2.20 and 2.19. because autoscaling upgrades

2:12 can move assumptions around events, permissions,

2:16 scalers, and monitoring. In the lightning round,

2:19 we'll hit Kubernetes Dashboard being archived

2:21 with Headlamp as the path forward, Google Cloud

2:24 Remote MCP Server for AlloyDB, Apache Kafka 4

2:28 4.3.0, and Atlassian's AI-native SDLC productivity

2:33 claims. And the human closer this week is about

2:36 hidden boundaries, because the scary part of

2:39 automation is not always what it can do. Sometimes

2:42 it's what we forgot it was allowed to do. So

2:45 let's get into it. First up, Kiro CLI had a

2:52 pretty interesting security issue. AWS published

2:55 a bulletin for CVE-2026-9255 affecting Kiro

3:00 CLI versions before 1.28.0. The short version

3:05 is that crafted content piped into Kiro CLI through

3:08 stdin could be consumed as confirmation

3:11 input, and that could allow tools, including

3:14 shell commands to execute without the user actually

3:18 approving them. So yes, the AI tool asked for

3:21 permission. And stdin answered for you,

3:24 which is funny in the way that makes you stop

3:27 smiling after about half a second. Because this

3:30 is not just a random command-line parsing bug.

3:33 This is an approval boundary bug. A lot of AI

3:36 coding tools are built around the idea that the

3:39 agent can suggest actions, but the user approves

3:43 the risky parts. That approval step is the thing

3:46 that makes people feel safer. The tool says,

3:48 hey. I want to run this command. The human looks

3:51 at it and says yes or no. That is the mental

3:54 model. But if crafted input can accidentally

3:56 or intentionally flow into the confirmation path,

4:00 now that boundary is not really where people

4:03 thought it was. And that matters because these

4:05 tools are not just answering trivia questions.

4:08 They can read files. They can inspect repos.

4:12 They can call tools. They can run commands. They

4:15 can modify code. They can sometimes interact

4:18 with cloud CLIs, Kubernetes configs, package

4:21 managers, and all the usual developer machine

4:24 chaos. So when approval gets weird, the blast

4:27 radius gets weird too. The practical lesson here

4:30 is bigger than Kiro. If you are building or adopting

4:33 AI tools, Approval needs to be treated like security

4:36 controls, not UX prompts. Security controls.

4:40 That means you should think about where approval

4:42 input can come from. Can it come from standard

4:45 in? Can it come from a file? Can it come from

4:48 pasted content? Can it come from generated content?

4:51 Can it come from previous agent output? Can it

4:53 come from something the model read and then accidentally

4:56 turned into an action? Because when an AI tool

5:00 has access to execution, The approval path is

5:03 part of your trust boundary. And trust boundaries

5:06 are where boring bugs become very interesting.

5:09 For operators and platform teams, I would treat

5:12 this as another reminder to be careful with agent

5:15 tooling in high trust environments. Keep tools

5:18 updated. Avoid running agentic CLIs with broad

5:22 permissions unless you really need to. Be careful

5:25 piping untrusted content into tools that can

5:28 execute actions. And do not assume that a confirm

5:32 before running prompt automatically means the

5:35 human is the only thing that can confirm. The

5:38 button is not the boundary. The input path is.

5:45 Second story. Amazon Braket SDK had an insecure

5:49 deserialization issue. And I have to admit, there

5:52 is something funny about quantum computing getting

5:55 a very normal Python pickle bug. Like, yes. We

5:59 are doing quantum workloads and advanced simulation

6:02 and cloud-managed quantum jobs. But also, somewhere

6:06 in the middle of that, Python Pickle is still

6:09 standing there with a folding chair. AWS published

6:12 a bulletin for CVE-2026-9291 affecting Amazon

6:17 Braket SDK versions before 1.117.0. The issue

6:22 involved job results. The SDK trusted a data

6:26 format field in job result JSON. And under the

6:29 wrong conditions, it could call pickle.loads()

6:33 on attacker-controlled data. That could lead

6:35 to remote code execution for a remote authenticated

6:38 user with S3 write access to the job output bucket.

6:42 This is a very specific vulnerability, but the

6:45 pattern is extremely familiar. You have an SDK.

6:49 You have job output. You have S3. You have metadata

6:53 that says what format the data is in. And somewhere

6:56 in that chain, the client trusts the metadata

6:59 too much. Then the parser becomes an execution

7:02 path. That is the lesson. Deserialization bugs

7:05 are not old news just because the service sounds

7:08 modern. Pickle is dangerous when used on untrusted

7:12 input. That sentence has been true for a very

7:15 long time. And apparently, it is still true even

7:19 if the words around it include quantum computing.

7:21 For DevOps and platform teams, I think the takeaway

7:24 is about the trust boundaries around job output

7:27 and storage buckets. A lot of systems treat output

7:30 buckets as boring storage. The job writes results.

7:34 The client reads results. Everybody goes home.

7:37 But if the client treats those results as trusted

7:39 instructions for how to deserialize data, then

7:43 whoever can write to that bucket may be influencing

7:46 code execution on the client side. That changes

7:50 the security posture. So yes, patch the SDK.

7:53 But also, think about the surrounding pattern.

7:56 Who can write to job output buckets? Are those

7:58 buckets shared? Are they cross-account? Can

8:01 temporary jobs write results that other systems

8:04 later consume? Are clients running in developer

8:06 environments, CI, notebooks, or production workflows?

8:10 And are any of those clients deserializing data

8:13 in a way that assumes storage means trusted?

8:16 Because storage is not trust. Storage is just

8:19 where the problem waits politely until something

8:22 reads it. Before we get to the next story, a

8:25 quick word from this week's sponsor, @Scale: Systems & Reliability.

8:28 @Scale: Systems & Reliability is happening June 25th at the Meydenbauer Center in Bellevue, Washington. The event

8:37 is focused on the infrastructure behind AI-scale

8:41 systems, reliability, high-performance compute,

8:44 storage, networking, and the operational side

8:47 of AI-driven systems. So if you are thinking

8:50 about how reliability changes when AI workloads,

8:53 agents, and automation enter the picture, this

8:56 is worth a look. Register today at atscaleconference.com/events/systems-reliability-2026 or use the link in the show notes.

9:07 All right, back to the show. Third story, AWS

9:14 organizations now emit CloudTrail events when

9:17 accounts join or leave an organization. And this

9:21 is one of those updates that sounds small until

9:24 you remember what AWS Organizations actually

9:26 represents. An AWS Organization is not just

9:30 a billing container. It is a security boundary.

9:33 It is where SCPs apply. It is where centralized

9:35 logging expectations live. It is where guardrails

9:39 live. It is where account ownership and governance

9:42 gets enforced. So when an account joins or leaves

9:45 an organization, that is not just an administrative

9:48 event. That is a security and governance event.

9:51 AWS says organizations now emit account joined

9:55 organization and account departed organization

9:57 events to the management account. Those events

10:01 include things. like the join or departure method

10:04 and timestamp. You can feed them into CloudWatch

10:07 alarms, EventBridge roles, or whatever your

10:10 alerting and governance process looks like. And

10:12 honestly, this feels like one of those things

10:15 that should have already existed, which is not

10:17 a compliment exactly, more like a very cloud

10:20 engineering version of relief. Because account

10:23 movement is the kind of thing you want to know

10:25 about immediately. If an account leaves your

10:28 organization, what happened to the SCPs? What

10:31 happened to centralized CloudTrail? What happened

10:33 to Config rules? What happened to Security Hub

10:36 aggregation? What happened to access policies

10:39 that assume the account is still under org control?

10:43 And if an account joins your organization, is

10:45 that expected? Is it coming from an acquisition?

10:48 A sandbox? A delegated admin flow? A weird test

10:52 account someone created with a personal email

10:54 in 2021 and is now trying to bring home like

10:57 a stray cat. The practical takeaway is pretty

11:00 simple. Do something with these events. Do not

11:03 just mentally file this under nice AWS improvements.

11:07 Create EventBridge rules. Alert on account join

11:10 and departures. Send them somewhere your cloud

11:13 platform or security team actually watches. Attach

11:16 context if you can. Was this account expected?

11:19 Who owns it? Which OU did it join? What guardrails

11:23 apply? Was the departure planned? Do we need

11:26 to investigate? Because the worst time to discover

11:28 an account left your organization is later, when

11:31 you are trying to explain why the normal guardrails

11:34 did not apply. Account membership is not just

11:37 billing metadata. It is control plane state.

11:39 And control plane state deserves alerts. Fourth

11:46 story. KEDA has had a couple of releases. worth

11:49 operators actually reading. And I know, a KEDA

11:53 release note is not exactly the kind of thing

11:55 that makes people cancel dinner plans. But autoscaling

11:58 changes are production changes. KEDA sits in

12:01 a very sensitive part of the system. It watches

12:03 external signals. It decides when workloads should

12:06 scale. It interacts with Kubernetes events, RBAC,

12:09 metrics, scalers, and workload behavior. So when

12:13 KEDA changes event recording, scalers, permissions,

12:16 or assumptions, that is not just a version bump.

12:18 That is part of how your workload responds to

12:21 pressure. The on-call brief this week flags

12:23 KEDA version 2.20 and version 2.19 changes,

12:27 including event recording moving to the

12:30 events.k8s.io API group, plus scaler changes and additions

12:36 around things like OpenSearch, Elastic Forecast,

12:39 and Kubernetes resources. The event recording

12:41 change is the one I would pay attention to because

12:44 events sound like observability garnish until

12:48 something breaks. Then suddenly, everybody wants

12:51 to know what scaled, when it scaled, why it scaled,

12:54 what failed, and which controller said what.

12:57 If events move API groups, that may affect RBAC.

13:00 It may affect tools that scrape or watch events.

13:04 It may affect alerting. It may affect the way

13:06 your team reconstructs scaling behavior during

13:09 an incident. And that is the hidden risk with

13:12 autoscaling systems. When they work, nobody thinks

13:15 about them. When they fail, everybody discovers

13:17 they are part of the incident timeline. The practical

13:21 takeaway is not avoid KEDA upgrades. KEDA is

13:24 useful. The takeaway is to treat autoscaler upgrades

13:27 like production behavior changes. Read the release

13:30 notes. Check RBAC. Check event collection. Check

13:33 dashboards. Check scaler-specific changes for

13:36 the triggers you actually use. Test the upgrade

13:39 in a non-prod cluster with real-looking metrics

13:42 if you can. And make sure your team still knows

13:45 how to answer the basic questions. Why did this

13:48 workload scale? Why did it not scale? What signal

13:51 was it watching? What did KEDA think was happening?

13:54 And where would we see that during an incident?

13:56 Autoscaling is one of those areas where it just

13:59 works is great right up until it very much does

14:02 not. Now let's do a quick lightning round. First,

14:12 Kubernetes Dashboard has been archived and Headlamp

14:15 is the path forward. We have mentioned Headlamp

14:18 before, so I'll keep this short. The new angle

14:21 is that dashboard being archived means platform

14:23 teams should decide what the supported cluster

14:26 UI actually is. If developers, support engineers,

14:30 or internal teams rely on a UI to inspect workloads,

14:34 logs, events, or namespaces, that UI is part

14:37 of your platform surface. So do not let the

14:40 migration happen by accident. Decide what you

14:43 support. Decide who gets access. Decide how auth

14:46 works. Decide what actions are allowed. And please,

14:50 do not replace one risky dashboard with another

14:53 risky dashboard and call it modernization. Second.

14:57 Google Cloud Remote MCP Server for AlloyDB is

15:00 generally available. I know we have covered MCP

15:03 a lot, so I'm not going to make this the whole

15:05 show. But the trend matters. MCP is moving from

15:08 local developer demos into managed cloud data

15:12 access. That means the questions get more serious.

15:16 Who can connect? What data can the agent reach?

15:19 What identity is used? What audit trail exists?

15:22 And can the agent only read? Or can it take action?

15:25 Managed MCP is not just convenience. It is another

15:28 control plane for agent access. Third, Apache

15:32 Kafka 4.3 .0 is out. For most people, a Kafka

15:36 release is not something you rush into production

15:39 during lunch. At least I hope not. But it is

15:41 worth tracking because Kafka sits under a lot

15:44 of real-time systems, event-driven platforms,

15:47 data pipelines, and very nervous on-call rotations.

15:51 The high-level takeaway is simple. Read the

15:53 release notes. Watch client compatibility. Check

15:55 broker upgrade paths. Check the features that

15:58 affect your actual deployment model. And remember

16:01 that Kafka upgrade is rarely just a Kafka upgrade.

16:05 It usually involves consumers, producers, schemas,

16:09 connectors, monitoring, retention, partition

16:12 behavior, and some service nobody remembered

16:15 still uses the old client. Fourth, Atlassian

16:18 published AI-native SDLC productivity claims

16:22 around more pull requests and saved developer

16:24 time. The numbers sound good. More PRs. More

16:28 time saved. More development throughput. And

16:30 I am not against that. But more PRs is not automatically

16:34 more throughput. If planning, review, testing,

16:37 security, release, and operations cannot absorb

16:41 the extra output, then you may not have improved

16:44 flow. You may have just moved the bottleneck.

16:46 AI can absolutely help teams produce more work.

16:50 The leadership question is whether the system

16:52 can safely absorb it. Because more code is not

16:56 the same as more value. And it is definitely

16:58 not the same as more reliable production. The

17:09 human closer this week is about hidden boundaries.

17:12 That is the thread running through all of this.

17:14 Kiro CLI had an approval boundary. Amazon Braket

17:17 had a deserialization boundary. AWS Organizations

17:21 has an account membership boundary. KEDA had

17:24 an autoscaling and event visibility boundary.

17:27 Kubernetes Dashboard and Headlamp sit on the

17:30 platform access boundary. MCP sits on the agent

17:33 data access boundary. Kafka sits on the event

17:36 pipeline boundary. And AI productivity claims

17:39 run straight into the boundary between output

17:42 and actual throughput. The scary part of automation

17:45 is not always what it can do. Sometimes it is

17:48 what we forgot it was allowed to do. That is

17:51 the part teams need to keep looking at. What

17:53 counts as approval? What counts as trusted data?

17:56 What counts as an account boundary? What counts

17:58 as a safe scaling signal? What counts as supported

18:01 platform access? What counts as developer productivity?

18:05 Those are not abstract questions. Those are production

18:08 questions. Because automation does not remove

18:11 boundaries. It moves them. And if you do not

18:14 know where the boundary moved, you may not know

18:17 what you are trusting anymore. And that is where

18:19 staff and principal engineering work often lives.

18:22 Not just picking the tool. Not just approving

18:25 the upgrade. Not just reading the headline. But

18:28 asking where the authority actually sits now.

18:31 Who can approve? Who can write? Who can scale?

18:34 Who can access? Who can deserialize? Who can

18:37 query? Who can ship? That sounds boring. But

18:40 boring is usually where the real risk is hiding.

18:43 So the takeaway this week is simple. When automation

18:46 gets more powerful, look for the boundary. Then

18:49 make it visible. That's it for this week of Ship

18:52 It Weekly. We covered the Kiro CLI approval bypass,

18:55 Amazon Braket SDK insecure deserialization,

18:58 AWS Organizations CloudTrail account membership

19:01 events, KEDA autoscaling changes, and a lightning

19:04 round on Kubernetes Dashboard and Headlamp, Google

19:07 Cloud Remote MCP Server for AlloyDB, Kafka 4

19:10 4.3.0, and Atlassian's AI-native SDLC claims.

19:15 If this episode was useful, follow or subscribe

19:18 wherever you are watching or listening. If you're

19:20 on YouTube, hit subscribe. If you are in a podcast

19:23 app, follow the show there. And if you know someone

19:26 on a DevOps, SRE, platform, security or engineering

19:30 leadership team who is dealing with AI tools,

19:33 AWS governance, Kubernetes autoscaling, or platform

19:37 access, send this one to them. It helps the show

19:39 grow and it helps me keep making this kind of

19:42 content for people who actually live with these

19:45 systems. You can find the weekly brief at OnCallBrief.com and more episodes and this week's show notes

19:52 at shipitweekly.fm. I'm Brian Teller from Teller's

19:55 Tech. Thanks for listening. And remember, If

19:58 your AI tool asks for permission, your SDK trusts

20:01 a pickle, your account leaves the org, or your

20:04 autoscaler changes behavior, the question is

20:07 not just what happened. The question is where

20:09 the boundary was supposed to be.

Kiro CLI Approval Bypass, Amazon Braket Pickle Risk, AWS Org Logging, KEDA Upgrades, and Automation’s Hidden Boundaries

Watch this episode here

Transcript

Catch This Episode

Host Commentary

Show Notes