Microsoft 365 Agent Security: Inventory, Ownership and Least Privilege Before Runtime Enforcement

The argument: a gateway only sees traffic that goes through it​

The article draws a line between two things that are often sold as one. An AI gateway sits in a pipe you own and inspects prompts headed to a model you picked. The runtime where many agents actually execute is somewhere else, inside third-party applications.

The author's examples are Claude inside Salesforce, an agent inside Slack, Workday's agents inside Workday, and Copilot inside Microsoft 365. The sharpest example is an agent triggered by a Salesforce Flow that reads CRM records and writes case comments. In the author's telling, none of that activity passes an inspection point you control.

The narrower claim is the defensible one: a control can't see actions that never cross it. The author says outright that this isn't an argument against gateways. It's an argument against treating any single component as the whole strategy. These product placements are the author's assertions. The piece offers no technical documentation of how each named platform routes agent traffic, so treat them as a framing device rather than verified architecture.

"The millisecond needs a memory"​

The second argument is about context. A support agent touching customer data might be doing its job or exfiltrating. A finance agent creating an OAuth connection might be doing integration work or taking the first step of a compromise.

The author says the verdict depends on several things:

• The agent's identity and owner
• Its permissions
• Its normal behavior
• The sensitivity of the data
• The destination
• The delegation chain behind the request

Block too much and the business routes around you. Block too little and you have, in the author's words, a logging appliance with latency. That's a risk-management argument, not a measured finding. It's still a familiar lesson from conditional access, where policy without context tends to be either ignored or bypassed.

The author's 12-week plan​

The piece proposes an order of operations. It's the author's recommendation, not an industry benchmark.

1. Weeks 1–2: Count the agents that are running. Do it without deploying a new gateway, endpoint rollout, or traffic rerouting.
2. Weeks 3–6: Give every agent a named human owner, or suspend it. Fix configuration debt on the platforms that host the most reachable agents.
3. Weeks 7–12: Tier risk by what each agent can actually reach. Build a sanctioned path so business teams ship agents with secure defaults.
4. Afterward: Turn on runtime enforcement as each enforcement point becomes available.

The logic is that runtime controls work better when they land on a map that already knows what normal looks like. The piece also says the "full end state" of every platform instrumented and every agent registered at birth isn't available this year from anyone. The full guide, which the article only advertises, holds the vendor's self-assessment and checklist. Those aren't in the public text.

A correction on the LiteLLM claim​

The article says the LiteLLM breach "lasted forty minutes and exposed credentials across more than 2,500 organizations." That is looser than the evidence supports.

• What the reporting says. SecurityWeek reported in August that CloudSEK counted more than 2,500 organizations and about 434,000 CI/CD pipelines affected. The malicious packages were live for about 40 minutes.
• What CloudSEK itself cautions. The figures describe reconstructed exposure. They aren't proof that every listed organization was compromised or every credential stolen. SecurityWeek later noted that SOCRadar found most of those organizations were probably affected earlier, likely through the Trivy incident.
• How the March incident happened. Per SecurityWeek, LiteLLM was compromised because its CI pipeline automatically installed a compromised Trivy version. Two LiteLLM releases, 1.82.7 and 1.82.8, were pushed to PyPI.
• The safer wording. "Estimated exposure" is accurate. "Confirmed credential theft at 2,500 organizations" is not.

The underlying point survives the correction. An AI gateway holds provider keys and sits near everything else, so it's a high-value target.

A second LiteLLM incident, one day before the article​

This is a separate event, and it shouldn't be confused with the March one. LiteLLM's own notice says its release pipeline was compromised in the early hours of October 21, 2026, and that version 1.107.0 was pushed to Docker registries and PyPI. According to the notice, that version contained compiled malware that steals credentials and loads remote-code execution tools.

Key facts from LiteLLM's incident notice:

• PyPI: The malicious package was live from about 11:39 to 13:23 UTC, roughly two hours.
• Docker: The v1.107.0, latest, main-latest and main-stable tags were compromised from about 11:46 to 14:20 UTC.
• Enterprise customers: LiteLLM says the private enterprise release was not affected.
• Official source tag: LiteLLM says the official GitHub source tag didn't contain the malicious files. The artifacts were built from an attacker-controlled lookalike repository.
• Status: The notice lists the incident as contained, with the investigation still in progress.

If you ran an affected artifact, LiteLLM's guidance is as follows:

1. Treat the environment as compromised. Check with pip show litellm.
2. Don't start with pip install. Any Python start in the affected environment re-runs the malicious files.
3. Delete the identified malicious files from every affected site-packages directory, and kill the detached Python daemon.
4. Reinstall pinned to 1.106.2, or better, rebuild images and virtual environments from scratch.
5. Rotate everything the host could reach. That includes the instance or task IAM role, provider keys stored in the proxy database, master and virtual keys, the database password, and any secret in the environment.
6. Review CloudTrail for suspicious use of the instance role's credentials from outside your infrastructure.

LiteLLM warns that a missing marker file doesn't prove a clean system. Check its live notice for updates, since the investigation was ongoing.

What Microsoft says​

Microsoft's own security blog, published October 19, supports the layered view even though it doesn't validate the LinkedIn piece's specific claims. It says agents can make mistakes, be manipulated, or be compromised. It calls for protection spanning identity, permissions, data, endpoints, network, cloud and runtime.

Microsoft's framing is that controls must sit outside the model. Its four continuous responsibilities are:

• Know which agents exist and who owns them.
• Contain what each can do before it acts.
• Protect the data, tools, runtime and systems in its path.
• Adapt protection as risk changes.

The announced pieces map neatly onto the LinkedIn plan:

• Inventory: Microsoft is expanding local-agent discovery by 35 types, to 60. The list includes Claude Code, OpenAI Codex and GitHub Copilot. Discovery feeds a registry shared with Microsoft Agent 365.
• Ownership and identity: Microsoft is extending Entra Agent ID to local and previously unknown agents found by security sensors. That means an agent can become a policy target even if it wasn't integrated with Microsoft Security.
• Least privilege: Dynamic Permissions starts agents with no authority. It grants task-scoped, time-bound access, and organization policy caps it at what the user holds.
• Graduated response: Dynamic Conditional Access can reduce permissions, allow reads while blocking writes, narrow resources, restrict network paths, require human approval, or isolate and stop the runtime.

Futurum reported that these capabilities were announced in the context of Microsoft 365 E7, including Agent 365 and Entra Suite, and Project Perception. Licensing and availability are the open questions. One roundup noted that a release date for each added integration was not specified. Treat these as Microsoft's announced capabilities, not a checked feature of your tenant.

Reach is uneven, which is the point​

Futurum's analysis offers a useful counterweight. It says coverage is strongest for agents on the endpoint and agents built in-house, and harder for agents that come with someone else's application. That is the same gap the LinkedIn author describes. A vendor's own platform controls don't automatically reach a Salesforce or Workday agent.

So the vendor-neutral conclusion holds even if you discount Reco's sales pitch. Inventory and ownership come first. Permissions come second. Runtime enforcement works best where you actually own an enforcement point.

Practical takeaways for Microsoft 365 admins​

• Count before you block. Build an agent inventory from the sources you already have, rather than waiting for a new gateway.
• Assign an owner to every agent, or suspend it. Microsoft's guidance on separate agent identities points the same way.
• Don't let agents inherit their sponsor's standing access. Scope them to the task.
• Know which platforms sit outside your inspection points. Third-party SaaS agents may need platform-side configuration review rather than network inspection.
• Treat AI infrastructure as a target. Pin dependency versions, and rotate secrets promptly after supply-chain events like LiteLLM's.
• Be skeptical of numbers. Estimates of exposure aren't confirmed compromise, and one vendor's timeline isn't a standard.

Bottom line​

The article's central claim is sound: runtime enforcement is a last line of defense, not a first one. Its LiteLLM statistic is stated more strongly than the reporting supports. Its 12-week timeline is one vendor's suggestion. The most useful part is the sequence of count, own, tier, then enforce. Microsoft's own October 19 guidance independently points in the same direction.