Microsoft's Agent Controls, New Chip Options and the Junior Hiring Squeeze

Permissions That Change Mid-Task

An AI agent could keep reading your company's data while losing permission to change it. That's the practical promise behind Microsoft's latest security announcement: intervening during the job, without necessarily stopping it altogether.

Our main story today is Microsoft's expansion of Project Perception, and whether businesses can narrow an agent's access as its behaviour changes. The useful question is how much work can continue safely after a security control steps in.

On 19 October, Microsoft announced that Project Perception is extending beyond defence against external attacks to monitoring and constraining agents already operating inside an organisation. Those agents may be there legitimately. They may also have permission to make changes, which makes the distinction between observing a problem and blocking an action especially important.

Microsoft says it's adding thirty-five types of local agents to its discovery capabilities, bringing the total to sixty. The examples include Claude Code, Codex and GitHub Copilot. Agent identities and a shared registry are also part of the announcement. For an administrator, discovering an agent and identifying it are the starting points for attaching controls to what it does.

The more interesting part is what Microsoft calls Dynamic Agent Risk and Dynamic Conditional Access. These controls are intended to change permissions as risk changes. Instead of treating access as a decision made once at the beginning, the system could preserve read access while blocking writes, or require a person to approve an action.

That distinction has a concrete consequence. Reading information and altering it are different kinds of authority. If a task can still make progress by examining information, a restriction on writes needn't end all useful activity. Equally, an agent that can still read hasn't been completely isolated. The value of a graduated response depends on matching the restriction to the concern.

Microsoft's announcement brings together identity, runtime and network controls, alongside supervisory systems it calls Guardian Agents. Runtime controls act while software is operating. Network controls concern its connections. An AI supervisor may help assess what's happening, but the enforcement outside the model is the part I'd focus on. A supervisor's assessment and a system's ability to refuse a write are separate capabilities.

For organisations evaluating this, I'd judge the approach by whether a changed permission reliably constrains the next action while preserving the work that's still allowed. That's a more useful test than how many supervisory agents have been added. It also gets closer to the operational problem: an administrator needs a response that is effective without turning every concern into a complete shutdown.

There are limits to what this announcement establishes. Microsoft describes the effectiveness; the material here doesn't provide independent demonstrations. Nor does the announcement establish that every component is generally available to every customer. Availability and licensing remain details to resolve for the particular combination a business wants to use.

Those details affect the buying decision. A discovery feature, a risk assessment and an enforceable access restriction can sound like one capability in a launch announcement, but an organisation needs to know which pieces it can actually deploy together. The promising change is a more precise intervention during a task. The proof will be in the permission boundary holding when the agent tries to cross it.

PyTorch Reaches More AI Chips

We'll leave agent permissions there; the shorter developments begin with the hardware choices available to AI developers.

AWS and Google have both widened access to their accelerators through PyTorch, the framework many developers use to build and run models. AWS's TorchNeuron entered public beta on 20 October, following its announcement on 19 October. Google open-sourced TorchTPU on 20 October.

TorchNeuron supports Trainium2 and Trainium3, with eager execution, torch.compile and standard distributed APIs. Eager execution runs operations as they're requested, which is useful when inspecting and debugging code. Compilation provides another execution path, while the distributed interfaces support work spread across accelerators. The point is that developers can use familiar PyTorch approaches rather than treating these chips as a completely separate programming environment.

Google says TorchTPU brings native PyTorch execution to its TPUs, and integrates with tools including Hugging Face, vLLM and TorchTitan. Those integrations matter to the amount of surrounding work involved in an evaluation. A model rarely exists as an isolated piece of code; developers also depend on tools for loading, training or serving it.

Both announcements reduce a potential obstacle before a team even gets to comparing hardware: the engineering effort of trying it. If the existing model and familiar tools can carry across with fewer changes, a developer has a more practical way to investigate another accelerator. That doesn't make the resulting workloads identical.

TorchNeuron is still in beta. The minimal-change and efficiency claims come from the participating companies, and these announcements don't establish an independent, like-for-like cost comparison. Native framework support doesn't tell you how quickly a particular model will run, how much capacity is available, or what its total bill will be. These are software-access changes, not offers of free compute.

My reading is that the immediate gain is a cheaper evaluation in engineering time, rather than a proven cheaper production workload. For developers who have held off because a hardware trial looked like a code migration, that could be meaningful. Hardware competition becomes more useful when you can test a real alternative with your existing work, then compare the results before committing to the move.

DeepSeek Opens Its Inference Engine

There's another kind of infrastructure opening here, and it's aimed at a much more specialised developer.

On 20 October, DeepSeek published DeepInfer, an inference framework under the Apache two point zero licence. Inference is the work of running a trained model to produce an answer. DeepSeek says this engine is derived from the system powering its own production services.

This release is an engine, rather than a new model. It supports DeepSeek V4.1 Flash on NVIDIA SM100 GPUs and Huawei Ascend 950 neural processing units. That is a specific model and hardware combination, so the publication doesn't suddenly make the engine a general option for every developer's existing machine.

The released code provides offline inference, optimised kernels and scheduling. Kernels handle low-level computation on the accelerator; scheduling organises the work being processed. For infrastructure specialists, access to those parts offers something useful to inspect and adapt, beyond sending requests to a hosted service and observing the responses.

The omissions are just as concrete. DeepInfer explicitly excludes the complete cache system, separated serving stages and load balancing needed for a full online service. Load balancing distributes requests across serving capacity. Without the complete surrounding system, having the engine doesn't give you an operating replacement for a hosted API. There is substantial additional engineering between running supported inference and offering a dependable service to other people.

That distinction changes who benefits first. A developer building an application around an API is unlikely to find a direct replacement here. Someone already working on model-serving infrastructure, with the supported hardware, has a much more relevant starting point. They can examine how the released engine handles computation and scheduling, while accounting for the service components they would still have to supply.

I'd treat this as an opportunity for specialist infrastructure work, not a shortcut to self-hosting. DeepSeek's statements about production use and performance remain company claims; independent reproduction isn't established here. The practical value of open code is that others can investigate those choices directly. Whether adapting them is worthwhile still depends on the hardware they have and how much of the surrounding service they can build.

A Narrower Entry Route for Junior Staff

The people doing technical work have a different constraint: getting enough experience to become good at it.

Anthropic published an internal employment study on 16 October, describing changes in hiring and work organisation alongside extensive use of AI agents. The standout figure is the junior share of technical hires, which fell from twenty-seven per cent to nine per cent over the period studied.

Technical hiring still grew in absolute terms. So those percentages describe the mix of people being hired; they don't mean that all technical recruitment contracted, or that the number of junior hires necessarily fell by the same proportion. A falling share and a falling headcount are different claims. The study supports the former figure.

The research combines internal records with seventeen employee interviews. Anthropic also acknowledges that adoption wasn't random, which limits the causal conclusions. We can't take the change in hiring, put it beside greater agent use, and conclude that AI alone caused it. This is one unusually AI-intensive, rapidly growing employer, not an estimate for the whole labour market.

Still, the work changes it describes are relevant. Employees are spending more effort supervising agents and reallocating work. Anthropic describes an early-warning system for changing roles and an emphasis on internal redeployment. That may help an existing employee whose work is shifting. An applicant who never gets hired isn't reached by an internal redeployment programme.

That's the gap I find most important for organisations making productivity plans. If agents take on more routine implementation, how does a junior person acquire the experience needed to supervise the harder work? Reviewing an answer can require the very understanding that people once developed by working through the implementation themselves. That's a practical training question, not proof that junior roles are disappearing everywhere.

A business could become more productive while making its entry route less accessible. Both outcomes can exist at once, and a policy for current employees only addresses one of them. The useful organisational response is to make the path from inexperienced hire to capable reviewer explicit in workforce planning. Otherwise, a plan that explains how experienced staff get more done may leave unanswered where the next experienced staff will come from.

DeepSeek's US Federal Procurement Scope

For suppliers selling software to government, the next constraint sits inside the product's model dependencies.

On 20 October, the US Federal Register published a Department of Homeland Security order excluding DeepSeek products from covered federal civilian procurement and requiring their removal from covered agency IT systems.

The dates need a little care. The appendix records the order's original release as 24 July 2026. It was filed for public inspection on 19 October and published on 20 October. The new development here is publication, rather than an order first issued on that date. Keeping those events separate avoids giving a misleading picture of when the order originated.

The notice extends to affiliates, and to third-party products and services developed using DeepSeek implementations. That wording makes the underlying model relevant even where a different company supplies the finished application. A buyer looking only at the name on the product could miss a dependency covered by the notice.

For a supplier serving a covered agency, the practical implication is that its account of the product may need to reach beneath the application layer. Knowing who sells the software and knowing which model implementation it uses answer different procurement questions. The broad third-party wording is why that distinction deserves attention.

There are clear boundaries to this story. The order concerns covered US federal civilian systems and procurement. It isn't a general ban on consumer use, and it isn't an Australian requirement. It also doesn't, by itself, settle every possible derivative-model or hosting arrangement. The publication gives the scope to examine, not a ready-made answer for every product architecture.

My takeaway for affected organisations is that model provenance can determine eligibility, even when the model isn't the product's public brand. That adds work for suppliers whose applications depend on someone else's implementation. It doesn't establish anything about DeepSeek's technical capability, and it doesn't change the scope into a global restriction. A product's suitability for a particular procurement and its engineering merits remain separate assessments.

Mozilla Responds to Compromised Keys

A more immediate maintenance issue concerns the certificates your software uses to recognise a genuine website.

Mozilla disclosed on 20 October that private keys for eight eMudhra intermediate certificates had been compromised. Those keys are part of the certificate infrastructure used to establish trust in website identities. Fraudulent certificates could enable impersonation where an attacker can intercept the connection. The disclosure doesn't establish that anyone's traffic was intercepted.

Mozilla received the report on 17 October and says its automatic OneCRL block reached standard Firefox configurations that day. Its 20 October releases extend protection to users whose custom settings prevented that update. That chronology matters: ordinary Firefox configurations received the automatic response before the public announcement.

There's also a change beyond the browser. NSS version 3.131.1 removes the signing root for downstream applications. NSS supplies security components used by other software, so those applications can have their own update paths rather than receiving protection at the same time as Firefox.

For people managing software, I'd focus on that difference in timing. An updated browser doesn't establish that every application using Mozilla-derived trust information has received its corresponding update. Managed Firefox configurations and downstream applications are the places where separate maintenance can matter. Mozilla hasn't explained how the keys were exposed, and it hasn't established exploitation. The actionable distinction is between the automatic protection standard Firefox received and the separate updates other configurations still depend on.

Gemini's Government Services Preview

There's also a government agent launch, though its availability is narrower than the name might suggest.

Google Public Sector launched Gemini for government services in preview on 20 October. It's aimed at US federal, state and local agencies, combining government-specific skills with connectors to agency systems. The named tasks include policy analysis, procurement review and document intake.

Google identifies Missouri and the US Department of Health and Human Services as early users. It says the integrations inherit agency access controls. That is an important design claim, because connecting an agent to an administrative system raises the question of which information and actions it can reach. The announcement doesn't independently demonstrate how that works in each deployment.

For eligible agencies, the potential attraction is less assembly work. Instead of putting together every connector and workflow from scratch, they have a packaged route to testing these administrative tasks. That could lower integration effort, although the announcement doesn't supply independent measurements of faster services or more accurate decisions. Early use isn't the same evidence as an improved outcome.

This remains a US government preview, not general availability for Australian agencies or a service consumers can sign into. Detailed pricing isn't supplied either. I'd see it as a way for eligible agencies to test whether packaged workflows fit their existing systems. The meaningful result will be what happens to the work itself, including review effort, rather than the number of processes described as agent-enabled.

What Changes for You

If a coding agent is choosing dependencies for you, there's a new check available before those packages arrive.

GitHub launched its package firewall in public preview on 20 October for GitHub Enterprise Cloud customers, including those using data residency. It checks package metadata and downloads against enterprise policies before installation. The checks include known malware, vulnerability advisories and package age.

For developers building AI applications or running coding agents in an eligible enterprise, that puts an enforceable step between selecting a dependency and installing it on a workstation or build runner. The decision to use a package can come from the agent, while the download still has to pass the enterprise's policy.

The important qualification is routing. An administrator configures both the policy and the endpoints using the service. A coding agent or build runner that continues downloading directly from a public registry is outside that route. Having a project on GitHub doesn't automatically put all its dependency downloads through this check.

The preview supports npm packages only, and it's free during preview. GitHub says general availability will bring usage-based charges, but a general-availability price isn't established here. Nor does the announcement establish independent detection rates. It's an additional policy check with a defined scope, not evidence that every harmful package will be caught.

Package age also creates a practical trade-off. A cooldown can hold back a newly released package, including a new security fix. GitHub includes an administrator-reviewed exception process for blocked packages, so someone can assess whether the reason for taking that release outweighs the reason for delaying it.

For me, the useful change is that an agent's dependency choice can now meet an external installation rule in this supported enterprise setup. That gives developers a clearer boundary, but it also gives administrators exception work to handle. A cooldown is only useful if an urgent fix has a timely route through review; otherwise, a policy intended to reduce exposure can leave the needed repair waiting.