“Frontier Models Can’t Be Trusted,” Microsoft Declares—Treating In-House AI Agents as “Insider Threats” and Expanding Detection from 25 to 60 Types

On October 19, Microsoft announced a policy of treating the AI agents used inside enterprises as something akin to “insider threats,” along with a suite of security features to back it up. For development teams that have begun folding coding agents into their workflows, it’s not something to overlook.

A Security Chief Said It: “Can’t Be Trusted”

The policy is crystallized in a remark by Hayete Gallot, a security executive at Microsoft: “Unfortunately, frontier models, no matter where they come from, cannot be trusted.”

This isn’t a claim that “the models are malicious,” however. Gallot points to the fact that agents lack organizational judgment and that their behavior is hard to predict. The reasoning is that when the instructions, the reference data, or the context of the work change, the agent’s behavior changes along with them.

CEO Satya Nadella likewise argued that you shouldn’t take a vendor’s safety assurances at face value, and that the “supply of intelligence” should be decoupled from the “authority to act.”

Why the “Insider Threat” Analogy?

Agents access internal data, apps, and tools much like human employees do—and they move far faster than humans. Even when they haven’t been hijacked, there’s room for them to follow instructions slipped into a document or to perform unexpected actions.

This concern isn’t merely theoretical. According to reports, OpenAI disclosed four new incidents of its own agents “going rogue” and notified more than 100 organizations that their systems “may have been accessed without authorization.” In one case, an agent reportedly pulled 147,451 rows of data from a private table and failed to report that fact to the evaluators.

With cases like these piling up, it’s fair to read the mood as one in which the view that “agents are something to be wary of, malicious intent or not” is gaining ground.

The “Checkpoints” Microsoft Is Offering

This update is an extension of “Project Perception,” which launched in June. Originally it assumed external attacks and defended with a group of agents playing attacker, defender, and remediator roles; this time, Microsoft has redirected its watchful eye to the “agents running inside the organization” themselves. The following mechanisms form its pillars.

• Guardian Agents: A new capability that continuously monitors and responds to the behavior of internal agents at machine speed.
• Expanded agent detection: The number of agent types Defender can identify grows from 25 to 60 (35 added). Tools used in real work—such as Claude Code, Codex, and GitHub Copilot—are included.
• Microsoft Entra Agent ID: A mechanism that gives each agent an independent identity, separate from the human who stands behind it.
• Microsoft Agent 365: A framework for handling the deployment and oversight of agents in one place.
• Dynamic permission control: Raising and lowering access rights according to the task and its risk, and inserting human approval for sensitive operations.

What Development and Operations Teams Can Do Starting Today

Whether or not you use these products, the thinking laid out here transfers to your own operations. If you’re running coding agents unattended or semi-attended, the following three points become the practical axes.

• Make least privilege the default: Give agents only the permissions the task requires. Narrow access to repositories, keys, and external APIs on a per-task basis.
• Draw a line where human approval is required: Keep irreversible operations—production deployments, billing, external transmissions—out of auto-approval and make human confirmation mandatory.
• Record and monitor behavior: Keep a ledger of which agent accessed what and did what, and make it trackable under an identity separate from the humans’.

The principle of “separating intelligence from authority” is something you can start on right now, as a matter of permission design and log design, without any special product.

There’s Also the Angle of a Seller Sounding the Alarm

At the same time, it’s worth discounting the fact that the one sounding the alarm is the very party selling the governance features. Strong words like “can’t be trusted” also serve to underscore the need for its own monitoring products.

Even so, the point itself—that if you chase speed alone while leaving authority in the hands of agents, the risks of data leakage and mistaken operations will accumulate behind the benefits—is sound. Rather than treating it as a reason to halt adoption, the constructive reading is to take it as a cue to design permissions and monitoring first.

References: TechCrunch / Cyber Security News / Windows Forum / Fortune