The Experimental Windows 11 build released September 8, Build 26340.9354, includes an official Microsoft mock-up showing the new Resume hovercard, but it surprisingly shows a new mouse pointer. It’s slightly broader, softer around the lower-left side, and more symmetrical, without the thin tail-like extension we saw for decades in Windows.

Microsoft hasn’t said it changed the system cursor. The release notes for this build do mention fixing a known issue where cursor customization doesn’t work correctly, which we first reported. But nothing about a redesign.

But there’s history here. Back in June, there were reports that Microsoft was internally testing a new Windows 11 mouse pointer as part of the Windows 11 modernization effort. However, Microsoft hadn’t shown the design publicly back then.

Three months later, we may finally have our first public glimpse of what Microsoft was testing. The new cursor will be based on this mock-up. The size and shadow you see here may be different as well when it finally arrives.

The cursor in Microsoft’s screenshot looks a lot like a Fluent icon

Microsoft’s Fluent UI System Icons repository contains a Cursor icon with a noticeably cleaner, wider shape than the traditional Windows arrow. The 32px light PDF version is particularly close in proportion to the shape in Microsoft’s new screenshot, an outlined pointer with a straighter left edge and a more geometric body.

Of course, this resemblance isn’t enough to prove Windows has adopted it. It’s just a design-system icon. Microsoft’s current developer documentation still describes the standard pointer as the “arrow cursor,” and the Windows App SDK lists Arrow as the standard northwest-pointing shape. Microsoft already has a modern cursor-shaped Fluent asset.

The design language itself isn’t new. Fluent System Icons has existed since 2020, and the repository’s commit history stretches back so far. To be honest, it’s high time that Microsoft applies this language to the one element users see all day.

Windows 11 has modernized almost everything around the pointer, but the pointer stayed behind

Windows 11 has replaced old Settings pages, dialogs, and File Explorer pieces with modern WinUI over the past year, including a modernized mouse indicator that highlights your cursor when you press Ctrl. The pointer’s shape, meanwhile, has stayed the same arrow for years, with customization limited to size, color, and pointer schemes.

I’ve seen Microsoft use much more stylized cursors in presentations and promotional material over the years and always wondered why the real pointer still looked so plain.

macOS and several Linux desktop environments already have modern softer pointers as part of their visual language for years, while Windows 11 mostly just lets you change its color and size, while still looking like a 32-bit element.

I still remember using ridiculous custom pointers growing up, including banana cursors that made a shared family PC feel like mine. Those are, somehow, still downloadable today. Microsoft has long supported swapping in custom .cur and .ani pointer files, which is what makes Windows, well, Windows!

Windows may finally be giving its most visible UI element a Windows 11 makeover

Note that Build 26340.9354 doesn’t officially announce a new cursor. But the June report of an internally tested pointer redesign, and now this September screenshot showing a pointer that looks different, and a Fluent cursor design in Microsoft’s icon library, all look like we are remarkably close to it.

Personally, I like the new-looking pointer more. It is wider, cleaner, and more symmetrical, and I particularly prefer the lack of the old tail-like extension. Now I just want Microsoft to stop making us guess and ship it already.

The post Is this Windows 11’s new modern cursor? Microsoft quietly shows a redesigned pointer mock-up appeared first on Windows Latest

Many organizations still depend on legacy Windows activation scripts built around slmgr.vbs, often buried inside deployment workflows, task sequences, and IT management tools. The problem is that these automations were designed around VBScript, a feature Microsoft has already started phasing out and plans to remove from future Windows releases.

According to Microsoft, activation processes that run reliably may eventually fail on newer versions of Windows. VBScript remains available during the current transition period, but organizations that postpone modernization could struggle to repair critical activation workflows once the scripting engine is no longer included in Windows.

Microsoft’s OSLicense module becomes the recommended alternative

To avoid that scenario, Microsoft is urging IT teams to migrate activation automation to the OSLicense PowerShell module, which is designed to replace common slmgr.vbs functions such as activating Windows, installing product keys, and checking licensing status. The company recommends first identifying dependencies on slmgr, cscript, wscript, and other VBScript-based components, then validating replacement scripts in test environments before moving them into production.

However, the transition comes with tradeoffs. OSLicense support is not yet universal across all Windows releases, and organizations must verify which devices and server versions are compatible before updating production automation. IT teams may also need to spend time testing scripts, updating documentation, retraining administrators, and maintaining fallback plans during the migration period.

Microsoft’s guidance reflects a broader shift away from legacy scripting technologies. Organizations that begin planning now can spread the migration effort over time, and those that wait until VBScript reaches its final removal phase may face a more disruptive and time-sensitive transition.

The post Legacy Windows Activation Scripts Could Break As VBScript Nears Retirement appeared first on Petri IT Knowledgebase.

Infrastructure keeps shifting and access now comes from all kinds of people and systems.

I spoke about that with Ross Kukulinski from Tailscale at WAD Berlin. He kept coming back to the same problem: traditional networking still trusts too much based on IPs and subnets. That doesn’t work well in a world where identity matters more than location.

We talked about his talk on the next internet protocol and what it takes to build connectivity around identity instead of network boundaries.

Large shared networks are becoming a liability

Kukulinski points out a simple mismatch: the internet was built to be open, but private infrastructure usually shouldn’t be. That openness works for public services, but it gets much harder to justify when you’re talking about databases, Kubernetes clusters, internal tools, and AI workloads.

In practice, teams try to work around this with firewalls, gateways, proxies, and network segmentation

Kukulinski argues that a better starting point is to ask whether every person, machine, or workload should be able to reach everything else at all. This shifts the design toward smaller, isolated networks that are only connected when a resource needs to be shared, with access rules determining which identities can communicate with which services. He explained:

The key is point-to-point connectivity. Policy is governed centrally, but enforcement happens at the edge. Instead of routing through a stack of gateways or proxies, machines can talk directly to each other.

For developers, the key idea is the separation of authorization from network topology. A service can be reachable because a particular identity is allowed to reach it, rather than just because both endpoints sit inside the same trusted network.

“That distinction matters as infrastructure becomes more distributed. A development environment may span several clouds, customer networks, on-prem systems, remote workstations, and edge devices,” Kukulinski pointed out.

He added that traditional connectivity options can solve individual cases, but large shared networks become harder to govern as the number of environments and access relationships grows. The goal is to make connectivity explicit and narrowly scoped, instead of treating broad network membership as permission.

Identity is more durable than an IP address

That same idea raises a bigger problem with trusting IP addresses: IPs are fine for finding where traffic should go, but they are not a good way to prove who someone is or whether they should be allowed to access something sensitive. Kukulinski said this is especially clear in Kubernetes, where IP addresses change often and don’t reliably represent identity:

IP addresses come and go, and they’re duplicated everywhere. If you’re running in a Kubernetes cluster, the IP address of any one pod changes as pods are destroyed and recreated. So trusting IP addresses, or even trusting a subnet, really doesn’t work.

Kukulinski also said that identity-based access is better because it ties permissions to the connection itself, rather than to an IP address or subnet. That connection can carry useful context, like who the user is, what group they belong to in the identity system, what device they’re using, and what policies apply to that device. For example, a managed work laptop might be allowed to access internal systems that a personal laptop cannot, even if both belong to the same person.

For developers, this can remove a lot of the hassle around infrastructure access. SSH, Kubernetes admin tasks, databases, and remote systems often rely on credentials that have to be created, shared, updated, and eventually revoked.

Identity is becoming the control layer for infrastructure and AI

Kukulinski also said that if access is based on identity and group membership, permissions can change automatically when a person’s role changes. For example, when a developer moves to another team, the systems they can reach can update right away, without having to clean up old VPN access or long-lived keys:

If I transfer internally from product management to engineering, and my groups change in the identity provider, that automatically updates what I can do from my devices.

The same idea is becoming important for AI tools too. An identity-aware gateway can sit between developers and model providers, check who is making the request, control which models they can use, and manage provider logins in one place. As Kukulinski explained, developers can still make API calls without needing a separate credential for every model or service.

He also said Kubernetes shows that networking can still get complicated, even when identity is handled well:

The harder problem begins at the cluster boundary, when a service in one cluster must communicate securely with another cluster, another cloud, or a system outside Kubernetes. Things inside the cluster can talk easily, but talking to other Kubernetes clusters, especially in a different cloud, is incredibly challenging

Kukulinski prefers a direct encrypted connection when possible, using relay infrastructure only as a backup. Connectivity affects not just security, but also speed, reliability, and cloud costs.

AI agents need limited access, not blanket trust

AI makes this problem harder because it adds non-human users that need access to internal systems. Kukulinski also said AI tools can help attackers automate scanning and reconnaissance, so defenders should use the same kind of automation for supply-chain security, environment checks, and build and deployment controls.

The risk is often inside a company’s own infrastructure. Teams sometimes give AI projects broad access first and tighten it later, which can leave them with the same kind of over-permissive VPN access companies have struggled with for years:

The historical pattern has often been: “We just need to get this AI thing going, so let’s give AI access to the whole network.” That’s the scariest thing, and it repeats the same failure mode as giving too many people open VPN access to too many systems.

Kukulinski’s preferred model is to give agents their own identity and access policy, with permissions that can be changed or revoked as needed. An agent, or group of agents, can also be isolated from the wider network and given access only to the nodes, services, or data it needs.

For developers building agentic systems, treat an agent as a separate workload with least-privilege access from the start

“If an agent can reach a production database simply because it is already inside a trusted network, the architecture has repeated an old networking mistake with a much more capable actor,” Kukulinski said.

The post AI agents need their own identity and least-privilege access appeared first on ShiftMag.

During a service incident, a customer-remediation workflow is moved onto an emergency route because the situation is critical and the team needs a fast resolution. Approvals are shortened, a priority queue is opened, and an on-call agent is cleared to use an alternate procedure until the service recovers. The incident ends, but the route stays active for a small customer segment after everyone has moved on.

The emergency route itself was fine. Production systems need emergency routes, and a human approved this one. The trouble is that the route now runs without a live incident, an owner, or an expiry condition. A controlled exception has quietly settled into the platform’s standard runtime behavior.

This article is about that execution layer: the temporary operating state that lingers in runtime behavior. Temporary authority is easy to grant under pressure and hard to retire once the pressure lifts. An enterprise agent shouldn’t have to guess from prompts or conversation history whether it’s running under normal, incident, or recovery conditions. That state should be handed to it as authoritative runtime input, the way platforms already hand over identity, tenant, environment, and permissions.

An exception is safe while the incident that justified it is live. It becomes dangerous the moment the platform can no longer show the incident has ended.

The problem is unmanaged exception state

Exception drift is what happens when temporary exception behavior outlives its authorized scope, authority, or duration, and emergency accommodations settle into normal execution. The drift is usually quiet: a routing rule that stays reachable, an approval shortcut that survives closure, a tool permission that keeps shaping execution after the triggering condition has passed.

Enterprises already have the human machinery for this. Incident management defines abnormal conditions, change control governs deviations from standard practice, and postincident reviews confirm that temporary measures have closed.¹,² The gap is architectural. Most agent platforms still treat organizational operating state as something outside the runtime rather than an input to it.

Once an accommodation proves useful, it fades into an invisible operating state. The routing rule stays enabled, the shortened approval path stays reachable, and the temporary queue keeps taking work. No dramatic model failure is required, only a platform with no reliable way to close runtime state.

The practical question to ask is “Which operating mode is active for this workflow, this user, this segment, at this moment?” When the answer is left implicit, every agent, workflow, and tool gateway invents its own. Discussions of agent architecture tend to dwell on capabilities such as models, tools, and orchestration, yet production behavior depends just as much on runtime context: identity, tenant, environment, permissions, session state, policy, and tool access. One piece of that context is usually absent. The runtime knows who is acting and what they may do but not whether the organization is under normal conditions, incident response, recovery review, or a declared exception. Exception drift begins in that blind spot.

The exception lifecycle

Organizations move through a predictable sequence: normal operations, incident declaration, a temporary exception window, closure review, and return to normal. Each stage answers a question, from why the exception exists and who authorized it to what evidence shows it’s no longer shaping execution. Most enterprises handle the front of that sequence well; they’re practiced at declaring incidents and authorizing workarounds. The hard part is the retirement: proving that the exception behavior actually disappeared.

Declaring an exception is loud. Retiring one is quiet, especially when the workaround improved throughput or helped the team recover faster. That asymmetry is where drift lives, because an incident can be closed on paper while emergency routing, override policies, or alternate workflows keep influencing execution. From the platform’s point of view, the lifecycle should close only when it can show that every exception path has been retired or formally adopted through change governance.

Why this matters more for AI agents

Agents raise the stakes because they act. Rather than sitting in a config file, they select tools, trigger workflows, coordinate with other agents, and adapt their paths at runtime. An accommodation introduced during an incident can spread through routing, tool use, approval paths, and downstream agents. A traditional exception stays legible in a runbook or workflow definition; an agent can carry the same exception along many paths at once, which makes it harder to find and retire.

For engineers, the missing layer is an authoritative operational-state context that arrives with the request rather than being inferred from it. Historical traces and retained memory can explain why an accommodation once existed. They should never decide whether it’s still authorized. Memory informs execution; operating mode governs it. And when the two disagree, authoritative runtime state wins.

A small example shows the shape of that context. It carries the minimum needed to bind an exception to a mode, a scope, an authority, an expiry, and a status:

{
  "mode": "incident",
  "exception_id": "INC-4721",
  "scope": {
    "segment": "premium-customers",
    "region": "us-east",
    "workflow": "customer-remediation"
  },
  "authority": "service-owner",
  "expires": "incident-close",
  "status": "active"
}

The pattern sits near familiar ones without matching them. Feature-flag platforms such as LaunchDarkly target behavior by context, RBAC governs what a principal may do, and tenancy metadata tells a service where a request belongs.³ Operating mode serves a different purpose. It doesn’t replace policy, permissions, or memory: Permissions determine who may act, and policies determine how they may act. Operating mode determines whether exception behavior is authorized at all. As a result, it acts as a higher-order governance constraint on agents, workflows, approvals, tools, and escalation paths. Operating mode draws its authority from the organization’s incident and change process and represents a governed state of the enterprise, consumed by the runtime.

A design pattern for exception-aware agents

Operating mode becomes actionable once the platform treats it as a first-class runtime construct. Most agent architectures already inject identity, permissions, tenant context, and policy into every request, and operating mode belongs in that set. Agents consume it as authoritative state after the organization declares the exception, scopes it, assigns authority, and sets an expiry, instead of reconstructing it from prompts or accumulated context.

That reframes the architectural question as whether the platform can guarantee that exception behavior is impossible outside an authorized operating mode. Emergency behavior exists because the platform enables it, and for no other reason. Table 1 shows the minimum contract that makes the boundary testable.

Field	Purpose	Example
Mode	Current operating state	Normal, incident, recovery
Exception ID	Unique identifier for tracking and validation	INC-4721
Scope	Boundaries affected by the exception	Workflow, region, customer segment
Authority	Owner who approved the exception	Service-owner
Expiry	When the exception ceases to be valid	Incident closure, timestamp
Status	Current lifecycle state	Active, closed, retired

A workflow invocation receives that state alongside the user request, and orchestration, routing, and tool gateways read the same state. Figure 1 shows the shape.

Building an exception-aware control plane

The natural home for operating mode is an external control plane. Incident management platforms, maintenance window services, and change management workflows already hold authoritative operational state, and exception-aware architectures extend those signals into execution with explicit scope, authority, expiry, and closure semantics.⁴,⁵ Implementation will vary across organizations, but the principle holds: Exception state should be authoritative, observable, and externally managed, kept out of prompts and workflow definitions and away from agent memory.

Exception-aware execution

With explicit operating state, behavior shifts when system state shifts, and prompt wording stops being the lever. Under normal operations, agents run standard workflows, routing, and approvals. Under incident mode, the same workflows can expose scoped accommodations that the authorized mode makes available, such as expedited approvals, alternate routing, deferred reviews, or emergency runbooks.

Capability	Normal mode	Incident mode
Approval path	Standard workflow	Expedited approval
Queue routing	Primary queue	Alternate queue
Manual review	Mandatory	Deferred where authorized
Tool access	Standard permissions	Emergency tools enabled
SLA handling	Standard policy	Incident response workflow

Table 2’s payoff is testability. A workflow in normal mode should never reach an emergency path, and a workflow in incident mode should reach only the accommodations its scope, authority, and expiry allow. Governance becomes an enforceable runtime property the platform can check at execution time.

Return to the opening incident. With operating mode as runtime state, the emergency route opens only inside a declared exception: scoped to the affected segment and workflow, owned by the service owner, and stamped with an expiry tied to incident closure. When the incident closes, the mode returns to normal and the routing gate stops handing that route to the segment, ahead of any manual cleanup. Closure then runs as a check. The platform replays the exception’s scope against live routing, approval, tool, and queue configuration, and confirms that no path still resolves to the emergency behavior. No one has to remember to retire the route; it was bounded by state, and the platform can show it is gone.

A common operating model for multi-agent systems

The problem compounds across collaborating agents. Customer-facing, orchestration, and execution agents may share a workflow while disagreeing about state, so one keeps applying emergency routing after another has returned to standard controls. A shared operating state gives them a single governance boundary: The exception is represented once and read consistently everywhere. As agent ecosystems grow more autonomous, shared operational state matters as much as shared identity and authorization. Fragmented state produces fragmented accountability.

Making exception drift observable

The payoff is observability. These conditions have historically been hard to see because accommodations scatter across workflow definitions, approval policies, routing configurations, and tool permissions. Explicit operating state makes them measurable at runtime. Closure can trigger automated validation, and the platform can watch for residual exception behavior between closures. The revealing checks are direct: Is the exception’s routing path still reachable, do its temporary approvals or elevated permissions still resolve, and does any expired exception still touch behavior? Tracking how many exceptions are open, how long they stay open, and how often they harden into permanent change turns drift from an audit finding into a monitored signal.

From adaptive agents to governed systems

Table 3 captures the shift. Traditional governance documents exceptions and trusts that they are retired. An exception-aware platform represents them as runtime state that can be propagated, validated, monitored, and closed.

Traditional approach	Exception-aware approach
Exceptions are documented.	Exceptions are represented as runtime state.
Closure is procedural.	Closure is validated.
Audit relies on evidence collection.	Audit relies on observable state.
Exception behavior can persist silently.	Drift becomes detectable.
Agents infer context.	Agents consume authoritative state.

The test is whether the platform can demonstrate that the exception stayed bounded to its purpose and duration.

None of this demands a new governance model. Organizations already know how to govern identity, permissions, change, and operational risk, and the recommendation is to extend those disciplines to operating state. Once operating mode is authoritative, observable, and testable, drift becomes detectable, closure verifiable, and recovery an engineering result. The aim is a platform that can make its own operating conditions explicit, hold every agent to them, and demonstrate a clean return to normal. In that model, temporary accommodations stay temporary, governance lives in the architecture, and enterprise agents earn trust at scale.

References

1. ISO, “ISO 22301:2019: Security and resilience—Business continuity management systems—Requirements,” International Organization for Standardization, 2019. https://www.iso.org/standard/75106.html ︎
2. Axelos, “ITIL 4: Change enablement,” IT service management practice, 2019. https://www.axelos.com ︎
3. LaunchDarkly, “Target with Flags,” LaunchDarkly Documentation. https://launchdarkly.com/docs/home/flags/target ︎
4. ServiceNow, “Change Management,” ServiceNow Product Documentation. https://docs.servicenow.com ︎
5. PagerDuty, “Maintenance Windows,” PagerDuty Support Documentation. https://support.pagerduty.com/main/docs/maintenance-windows ︎

Ryan chats with Sam Curry, CSO at Zscaler, about where human intelligence sits in the new security landscape with AI, why shifting security protections closer to applications helps limit probes for vulnerabilities, and why building more resilient code infrastructure is the best way to address the vulnerabilities AI does discover.

About Richard

Mr. Moore, P.E. is the President and Founder of Moore Engineering. He is a Vietnam veteran where he was a Lieutenant with the Corps of Engineers assigned to the 102 Construction Engineering Company building roads in the Central Highlands. He also taught water supply and wastewater treatment at the Army Engineer School at Fort Belvoir, VA.

Mr. Moore is an internationally recognized expert in water quality protection and wastewater and stormwater management, has published widely in the field and is an Adjunct Professor at Wentworth Institute of Technology. His 40 years of engineering and project management experience includes successful oversight of infrastructure projects. Mr. Moore has a proven track record of completing large-scale and complex infrastructure projects in the US and abroad.

Mr. Moore holds a BS and MS in Civil Engineering and is a Registered Professional Engineer. Early in his career he worked for Metcalf and Eddy on wastewater and stormwater projects nation-wide.

More recently, Mr. Moore served as President of Tetra Tech Rizzo from 2000 to 2007, where he managed the firm’s domestic and international engineering operations with a diverse portfolio of assignments for both public and private clients. He was responsible for growing the company’s annual revenue from $20M to $40M. In his last two years as President, Tetra Tech Rizzo won the ROI (Return on Investment) award, Tetra Tech’s highest award among approximately 30 operating units. Subsequently, Mr. Moore led Tetra Tech India Limited, a wholly owned subsidiary of Tetra Tech with a staff of approximately 200, through 2012.

Mr. Moore is a life member of ASCE, served on the Board of ACEC Massachusetts and was Chair of several national committees for the Water Environment Federation (WEF).

---

Today We Talked About

• Officer Life
• Getting out of comfort zone
  • Vietnam
  • India
  • Don’t hide your mistakes
• Working with Teams
  • Building Trust
  • Project Management
• Leadership
  • Emotional Intellegence
  • Trust
• Don’t peak too early
• Trust your neighbors
• Plant seeds…

---

Connect with Richard

• Website
• Books
  • A Charmed Young Life
  • An Officer’s Journey
  • A Cosultant’s Story

---

Leave me a tip $
Click here to Donate to the show

---

I hope you enjoyed this show, please head over to Apple Podcasts and subscribe and leave me a rating and review, even one sentence will help spread the word.  Thanks again!

Download audio: https://media.blubrry.com/a_geek_leader_podcast__/mc.blubrry.com/a_geek_leader_podcast__/AGL_486_Richard_Moore.mp3?awCollectionId=300549&awEpisodeId=12216132&aw_0_azn.pgenre=Business&aw_0_1st.ri=blubrry&aw_0_azn.pcountry=US&aw_0_azn.planguage=en&cat_exclude=IAB1-8%2CIAB1-9%2CIAB7-41%2CIAB8-5%2CIAB8-18%2CIAB11-4%2CIAB25%2CIAB26&aw_0_cnt.rss=https%3A%2F%2Fwww.ageekleader.com%2Ffeed%2Fpodcast