Azure just amplified the “agent-first” runway: Microsoft Foundry now exposes Anthropic’s Claude Fable and Claude Opus plus OpenAI enterprise models, Microsoft Discovery has graduated to GA (with a Discovery app preview for building agentic flows), and Azure rolled out early access for new Arm-based VMs targeted at Linux agentic workloads while making Entra-only identities for Azure Files SMB generally available.
That combination — multiple frontier models, a platform-level discovery/governance product, and Arm Linux VMs marketed for agentic workloads — is the kind of coordinated push that changes how platform teams think about risk. It’s not just more models; it’s models surfaced as first-class execution and orchestration primitives inside your cloud account, with I/O, storage, and identity hooks. If you treat these endpoints like another SaaS API you can casually key into CI, you will create an operational and compliance mess.
The practical delta here
- Microsoft Foundry: Claude Fable (framed for autonomous agents), Claude Opus (aimed at coding and agentic workloads), and recent OpenAI enterprise models are all available in Foundry. That’s multiple frontier model families you can pick per workload and orchestration pattern — including closed-loop agenting.
- Microsoft Discovery GA + app preview: a cataloging and workflow surface explicitly aimed at agentic workflows and governance. This is a notable release that wires models into business processes with discovery and app tooling at GA.
- Arm-based Azure VMs (early access): new Linux Arm VM SKUs aimed at agentic/AI workloads for lower-cost or energy-efficient inference and tool execution nodes colocated with model endpoints.
- Entra-only identities for Azure Files SMB GA: removes the legacy dependency on Windows AD domain controllers for SMB authentication, simplifying identity while concentrating policy in Entra ID.
Why this matters for platform engineering
Microsoft is assembling the plumbing teams need to run agents in production: model selection at Foundry, a discovery/governance plane, cheaper Arm hosts to run worker processes or local inference, and identity primitives that integrate with Azure’s control plane. That’s smart product design. It’s also dangerous if you haven’t rethought boundaries.
Three real risks you need to treat as first-class now
-
Privilege explosion: Agents will need tokens, file mounts, and network access to act. Treat model endpoints and agent orchestrators as privileged identities — not as unprivileged API calls. Use conditional access, managed identities, and per-agent scopes. Audit every token mint.
-
Lateral movement via SMB and compute: Entra-only SMB simplifies mounting shares, and new Arm hosts give cheaper Linux workers for tool execution. If agent code or payloads can create or modify SMB mounts, you now have a pipeline for lateral access. Lock SMB ACLs, enable NTFS-level auditing, and microsegment agent workers.
-
Data exfiltration and model grounding: Foundry’s support for multiple model families means agents can call different model endpoints. Model responses may be used to generate actions — assume any output could be an instruction. Private endpoints, VNet isolation, and strict egress policies are non-negotiable.
This is the right call — with guardrails
Centralizing model access in Foundry and shipping Discovery as the governance surface is the right architectural move. Teams should want a single plane to manage model choice, experiments, and audit logs. But Microsoft is shipping capability faster than most orgs have hardened operational practices. If your security and platform teams don’t treat model endpoints, agent runtimes, and SMB mounts as privileged surfaces, you’ll pay for it.
If you want a starting point, examine how you currently onboard service principals and secrets: extend those policies to Foundry model consumers and Discovery agents, require managed identities for agent runtimes, and run agent workers in isolated VNets with private endpoints to Foundry.
Final thought
This wave isn’t about performance benchmarks or model rankings — it’s about changing ownership: models become part of your control plane. Expect platform teams to pivot from “where do we run models” to “how do we govern agent actions.” If you don’t treat that as an infrastructure problem — not just an ML problem — you’ll be remediating in prod instead of building safe, composable agent platforms.
Related reading: see my earlier coverage of how Foundry added OpenAI and Anthropic families and the platform implications in Azure Foundry adds OpenAI & Anthropic models, Arm-based VMs, and Entra-only Azure Files GA, and compare vendor approaches in Amazon Bedrock AgentCore: Managed knowledge bases and web search for platform teams.