Update SDK snapshot for Copilot CLI 1.0.92-5

This week’s highlights bring together some practical programming improvements, thoughtful reflections on the craft of coding, and a few interesting ways to work with AI. From open-source Blazor controls and smarter CSS optimization to Claude Code routing, Docker Sandboxes, and better secrets management, there’s plenty here to explore and put to use.

Programming

• Syncfusion Releases First Set of Open-Source Blazor Controls - That's good news, free components together us started faster

• Improving site performance by shipping more CSS - The GitHub Blog (Josh Black, Marie Lucca) - Nice performance tuning story. It makes me think we should all do the exercise more often.

AI

• Route every Claude Code message to the right model with Jev | Pulumi Blog (Engin Diri) - A really cool project that features the new JEV model. It's an OSS project and can be found on GitHub.

• Docker Sandbox Kit Spec: Authority as Code | Docker - This post shares the evolution/stabilization of the kit for Docker sandboxes

• Auto-accepting AI edits in VS Code - There is, most of the time, a setting in VS Code to tweak it just the way you prefer. Nice share.

• One Gym Session, One Cell Phone, One Working App ( jamie maguire) - Fun little experiment. There are things like this that you can safely one-shot because they’re well-known and predictable.

DevOps

• From API Keys to Access Control: Rethinking Secrets Management (Aanchal Mishra) - Security must stay a priority. I like what Postman did here.

Miscellaneous

• Something About Coding Stopped Feeling Good — and It Took Me a While to Figure Out What - We all noticed it, but only a few of us talk about it, and this post does a good job of putting words to feelings

Sharing my Reading Notes is a habit I started a long time ago, where I share a list of all the articles, blog posts, and books that catch my interest during the week. 

The following article was originally published on the Agentic AI Foundation blog site and is being republished here with the author’s permission.

A customer asks your company’s AI agent to update the shipping address on account 123. The agent relies on a support ticket with a typo and updates account 132 instead. The customer relationship management system reports that the update “succeeded.”

The API successfully completed the authorized request, but because it had no way to know which account the customer approved versus what was intended, it saw no error.

Teams often try to improve reliability by tuning the prompt or choosing a stronger model. But the model did exactly what the surrounding system allowed because the system treated the agent’s decision as the final authority. Prompt tuning and stronger models can improve the agent’s responses, but can’t provide guarantees for actions.

Put each decision in a layer that can enforce it

The model should propose an action, while a policy service decides whether the action is allowed. The execution layer can then perform the action within those limits.

Now consider that same agent, but with a policy service in place. The agent would propose updating an account after reading a support ticket. Before the update runs, a policy service can compare the request with the change the user approved. If the request falls outside those limits, the service can reject it even when the agent sounds confident.

After the policy check, the system can save an audit record that connects the request to the result and identifies the policy version used for the decision.

This separation gives each part of the system a job it can handle. The model interprets the request, while deterministic software enforces the conditions that must always hold.

However, policy enforcement depends on the information used to request an action. A policy check can’t correct a decision that was built on context the system should never have trusted.

Treat agent context as untrusted input

Agents receive instructions from more places than the user’s current prompt. A coding agent may read a SKILL.md file or persisted memory from a previous run. Each source can influence what the agent does next.

Stored instructions are useful, but their source may be stale or malicious. Another agent may have written the memory. A downloaded skill may contain instructions that expose credentials.

Therefore, stored context needs provenance. The system should record who wrote the context and when, then verify that linked files still match the versions the writer used. A risk label can also tell the runtime whether a piece of context may guide an answer or authorize a write.

Warnings help, but they don’t remove the risk. In controlled testing described in “Trustworthy Context Is Untrusted By Default,” Shub Argha reports that a trust preamble reduced one class of context contamination from 88.8 percent to 33.3 percent. The remaining failures show why a warning should sit alongside technical checks.

Once a team can tell where context came from, the next decision is what an agent may do with it.

Give the agent only the authority required for the task

OAuth scopes provide a useful boundary, but a broad write scope still leaves a large decision to the agent. The token may allow the agent to update any record even though the user approved one field on one account, as we saw in the opening example.

A narrower capability can represent the exact action the user approved. For example, the runtime could issue a capability that permits one update to the shipping address on account 123. The capability expires after the update, so the agent cannot reuse it for another customer.

Narrow capabilities also apply to local execution. An agent that needs to format one file doesn’t need unrestricted shell access. The runtime can provide a tool with the necessary input and keep other commands unavailable.

As a result, a prompt injection has less authority to work with. The agent may still request the wrong action, but the runtime can reject anything outside the capability it received.

Narrow permissions also make audit records easier to understand because the record contains the authority granted for that specific action. When authority lives in a broad token or a long prompt, an operator has to reconstruct what the agent was supposed to do after the failure.

Even narrow authority doesn’t require an agent to act. A reliable system also needs clear conditions for when the agent should stand down.

Make stopping part of normal operation

An agent can cause damage even without calling a sensitive tool. It can post a wrong answer to a customer or keep replying after a human has taken over.

The runtime should make restraint part of the workflow. If the agent’s confidence falls below a set threshold, the runtime can route the support ticket to a human representative. A reply from the human can then cancel any pending response from the agent.

Confidence checks and rules that stop the agent when a human takes over belong in the routing and execution layers. The model shouldn’t make either decision on its own. Similarly, a kill switch must stop an agent even when the model is in the middle of a plan.

Stopping safely solves one part of reliability, but long-running agents also need a plan for failures that occur after valid work begins.

Preserve state so the system can recover

Consider a browser agent that has filled out most of a form when the page changes. A retry that starts from the beginning could submit an earlier step twice, while a retry that guesses where to continue may skip a required field.

The execution system should record each confirmed step and attach an idempotency key to any action that must happen once. The key is a unique identifier that tells the server a retry belongs to the same action. Then, when the workflow resumes, the system can continue from the last confirmed state without repeating a completed action.

Agent sandboxes create a related problem. Keeping every sandbox running during long idle periods wastes resources and keeps execution environments available longer than needed. Hibernation can reduce both concerns, but only when the wake-up process restores the required state and handles a failed resume.

Recovery becomes much harder when the system can’t explain what happened before the interruption.

Keep evidence that people and agents can inspect

An execution log should connect the context an agent received to the action it requested. It should also show which policy allowed the action and what result came back.

Teams can use that record during an incident, but the agent can also use it during later work. For example, an agent that can read the reason behind a previous code change doesn’t need to infer intent from the final diff alone.

Context graphs offer one way to preserve those relationships across time. A graph can connect a tool call to the policy that governed it. The same record can link the source context to the outcome. Later, a person or agent can query the relationships to understand why the system made a decision.

The record still needs limits. Secrets shouldn’t be copied into an audit trail, for example, and retention rules should match the data involved.

A deliberate record is safer than relying on a conversation transcript and hoping it contains everything an operator will need.

A reliable agent system can explain why an action was allowed and resume safely when that action fails. Enforceable policies and recorded state provide those guarantees around the model.

Keep the controls portable

Many organizations will use more than one model or agent runtime. When each agent carries its permissions inside a prompt, the rules can drift as teams add models and tools.

MCP gives clients and servers a shared way to describe and call tools. Teams can use that common tool surface to enforce authorization at the server or gateway, regardless of which model requested the action.

A shared context format can also preserve provenance when a workflow moves between agents. Open specifications provide consistent interfaces, while each deployment remains responsible for its policies and enforcement.

Oluyomi Emmanuel: When Agile Team Trust Breaks Before the Scrum Master Acts

Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.

 

"Once that trust is broken, everything else, nothing else matters." - Oluyomi Emmanuel

 

Oluyomi Emmanuel started his Scrum Master journey after a strategic move toward Agile ways of working changed his project coordinator role into something deeper: helping people communicate when the answers were unclear. In this episode, he shares a hard lesson from a newly formed software team of eight people, where tension between a tech lead and a new developer first appeared in GitHub pull request comments. There were sarcastic replies, cameras switched off during the daily standup, and a growing distance when the team worked in the same office. Oluyomi initially treated it as a normal forming-stage conflict and waited for the team environment to absorb the tension. By the time the tech lead escalated concerns to the developer's line manager, trust had already deteriorated. A facilitated feedback session produced an improvement plan, but the developer experienced the feedback as judgment rather than support and left the team less than a month later. Oluyomi's lesson was clear: a Scrum Master needs to name trust concerns early, first in one-on-ones, then together, before the relationship becomes too damaged to repair.

 

In this episode, we refer to psychological safety, conflict resolution, and team trust.

 

Self-reflection Question: What early sign of broken trust have you noticed but not yet named with your team?

 

[The Scrum Master Toolbox Podcast Recommends]

🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥

Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.

 

🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.

 

Buy Now on Amazon

 

[The Scrum Master Toolbox Podcast Recommends]

 

About Oluyomi Emmanuel

 

Oluyomi is a Scrum Master, Agile Coach, and Product Lead with over seven years of experience helping teams work better and deliver meaningful digital products. Having worked across energy, consumer platforms, and fintech, he is passionate about building high-performing teams, creating clarity, and turning Agile principles into real business and customer value.

 

You can link with Oluyomi Emmanuel on LinkedIn.

 

Download audio: https://traffic.libsyn.com/secure/scrummastertoolbox/20261005_Oluyomi_Emmanuel_M.mp3?dest-id=246429

New episodes coming, stay tuned!

About Betatalks: watch our podcast videos and follow us on Instagram and LinkedIn. 

Download audio: https://www.buzzsprout.com/1622272/episodes/19898817-137-new-betatalks-the-podcast-episodes-coming-with-rick-oscar.mp3

https://clearmeasure.com/developers/forums/

Sam Nasr is a Senior Software Engineer and Trainer at NIS Technologies in Cleveland, Ohio, specializing in the Microsoft AI stack, Azure, and .NET development. A software developer since 1995, Sam is an 8-time Microsoft MVP and Microsoft Certified Trainer who leads the Cleveland C# User Group, the .NET Study Group, and the Azure Cleveland User Group. He shares his expertise as a contributing author for Visual Studio Magazine and through his LinkedIn Learning courses, and he blogs regularly at samnasr.blogspot.com, This will be his second appearance on the podcast, having previously joined me to discuss SQL Server for developers.

Sam's Blog - https://samnasr.blogspot.com/
LinkedIn - https://www.linkedin.com/in/samsnasr/
Github - https://github.com/samnasr
X Account - https://x.com/samnasr
Upcoming Event - https://www.meetup.com/caparea-net/events/316713608
Linktree - linktree.com/samnasr

Previous Appearances on the Azure & DevOps Podcast:
Episode 122 - https://azuredevopspodcast.clear-measure.com/sam-nasr-on-sql-server-for-developers-episode-122

Want to Learn More?
Visit AzureDevOps.Show for show notes and additional episodes.

Download audio: https://traffic.libsyn.com/clean/secure/azuredevops/Episode_422.mp3?dest-id=768873