Halilcan Soran

Tag: Azure

  • Azure Just Laid Out the Next Phase of Agentic Cloud Operations and the Insight to Action Loop Is What I Am Watching

    Azure Just Laid Out the Next Phase of Agentic Cloud Operations and the Insight to Action Loop Is What I Am Watching

    Agentic cloud operations Azure insight to action loop diagram

    Microsoft published From insight to action: The next phase of agentic cloud operations on June 25, and the framing is worth reading closely. The pitch for agentic cloud operations on Azure is no longer just copilots that surface insights. It is copilots that execute, chain decisions, and hand work between each other with approval gates in the middle.

    I have been reading a lot about this lately and watching how it lands with people at other organisations. The marketing is doing a lot of work in places. The underlying direction is real.

    What it actually does

    The post lays out a few moving parts that matter if you run anything on Azure.

    The FinOps copilot, the reliability copilot, and the security copilot are being repositioned as action-takers rather than dashboards with chat on top. Microsoft is describing a loop where signals come in from your environment, an agent proposes an action, a human (or another agent) approves it, and the action gets executed against the same control plane you already use. The agents can chain across domains. A reliability signal can trigger a FinOps reassessment. A security finding can pause a deployment.

    The execution layer is the interesting bit. These are not agents writing a Teams message asking you to go fix something. They are calling ARM, Defender, Monitor, and Cost Management APIs with scoped permissions, and the audit trail lives in the platform.

    The approval gate is the safety story. You can set policies for what an agent can do unattended versus what needs a human in the loop. That is the same pattern Power Platform uses for Dataverse business skills, and it is the right pattern. I looked at this when Microsoft shipped Dataverse business skills for agents and the approval boundary design there maps directly to what Azure is describing here.

    Why it matters

    The honest take: insight without action has been the broken promise of cloud operations for years. Every platform team I talk to has the same problem. The signal is there. The recommendation is there. Nobody has time to act on it. Cost recommendations sit in a tab for six months. Reliability advisor flags pile up. Security findings get triaged into a backlog that never drains.

    Agentic cloud operations on Azure is interesting specifically because it tries to close that gap with execution, not with another dashboard. If the FinOps copilot can actually right-size a VM after approval instead of just telling me to, that is a real change in how on-call and platform engineering work.

    Where the marketing is doing too much work: the chaining story. Cross-domain agent handoffs sound great in a blog post. In production, the failure mode is an agent making a FinOps decision based on a stale reliability signal, or a security agent pausing a deployment for a reason nobody can trace back two hops later. I have written about agentic workflow latency before, and chained agents compound that problem. Every handoff is another round trip, another context reconstruction, another place where the audit story gets fuzzy.

    The other thing I keep thinking about: this changes what platform teams own. If the agent is taking actions on your subscription, the runbook is now a policy document, not a wiki page. Who owns the approval thresholds? Who reviews the agent’s action history? That is a leadership question, not a tooling question, and Microsoft’s intelligent apps post is really about that same tension between speed and decision rights, and most orgs avoid it because it is uncomfortable.

    What I would do with it this week

    I would not chain anything yet. I would pick one narrow loop and wire it up end to end.

    Start with FinOps. Pick a non-production subscription. Turn on the action-taking mode for one specific recommendation type, like idle resource cleanup. Set the approval gate to require a human for anything above a small cost threshold. Let it run for two weeks. Read every action it took. See if the audit trail actually answers the question “why did this happen” without you having to reconstruct it.

    Then, and only then, look at where this connects to Power Platform. The natural fit is the approval layer. An Azure agent proposes an action, the approval lands in a Power Automate flow that routes it to the right owner with context attached, the decision flows back. That is a useful pattern. It is also a place to be careful because you are now spanning two control planes, and Power Automate flows need explicit error handling for the case where the Azure-side action fails after approval. The Microsoft Build 2026 Fabric and Azure databases framing is also relevant here because the data layer that feeds these agents matters as much as the agents themselves.

    The part I am genuinely watching is whether the cross-agent handoff story holds up in real environments or whether teams end up using one domain agent at a time for the next year. My bet is the latter, and that is fine. Single-domain action loops with clean approval gates would already be a meaningful step forward.

    If this lands the way the post describes, the role of a platform engineer shifts from triaging recommendations to designing the policies the agents operate under. That is a more interesting job. I will be writing more about how this plays out as the patterns settle.

    This post was inspired by From insight to action: The next phase of agentic cloud operations via Azure Blog.

  • Microsoft Open Sourced the Azure Integrated HSM Design and That is a Bigger Deal Than It Sounds

    Microsoft Open Sourced the Azure Integrated HSM Design and That is a Bigger Deal Than It Sounds

    Azure Integrated HSM open source hardware security module diagram

    Microsoft open-sourced the design of the Azure Integrated HSM. The azure integrated hsm open source release is not a marketing move dressed up as transparency. It is the hardware security module that sits in Azure silicon and anchors key protection for workloads running on top, and the design is now public for anyone to read, audit, and pick apart.

    I have been reading through the announcement and the surrounding material for a couple of days. My honest first take: this matters more than the headline suggests, especially if you are building anything agentic that touches sensitive data.

    What it actually does

    Azure Integrated HSM is a hardware security module Microsoft designed in-house and integrates into Azure servers. The job of an HSM is narrow and important. It generates, stores, and uses cryptographic keys inside tamper-resistant hardware so that the keys never leave the chip in plaintext. Encryption, signing, and key wrapping happen inside the module. The application above it gets the result, not the key.

    What shipped this week is the design itself. Schematics, firmware interfaces, the cryptographic boundary, the attestation flow. Open-sourced for review. Not the silicon, the design.

    This sits underneath services people actually use. Azure Key Vault Managed HSM, confidential computing workloads, the key material protecting storage and databases, and increasingly the trust roots for AI inference where prompts and outputs cannot be exposed to the host. If you have ever clicked “customer-managed key” on an Azure resource, something like this was already in the path. The shift is that you can now read how it works.

    Why it matters

    Cloud trust has been a faith-based exercise for a long time. You read the compliance certifications, you trust the vendor, you move on. That worked when the workloads were a SQL database and a web app. It works less well when the workload is an agent making autonomous decisions over sensitive data, calling tools, and producing outputs that have to be cryptographically attributable.

    Open-sourcing the HSM design changes the trust model from “Microsoft says it is secure” to “here is the design, run it past your own cryptographers.” That is a real shift. Apple did something similar with Private Cloud Compute last year, publishing the design and inviting external researchers in. The pattern is becoming the bar for any infrastructure provider that wants to host AI workloads with sensitive data.

    The other reason it matters: agentic workloads will multiply the number of cryptographic operations per user request by an order of magnitude. Every tool call that needs a signed token, every cross-service hop that needs an attestation, every model output that needs to be tied back to a verified context. The HSM is no longer a sleepy compliance box. It is in the hot path.

    I have written before about latency in agentic workflows. Cryptographic operations are part of that budget. Knowing how the hardware actually works, and being able to reason about what it costs per call, stops being academic.

    What I would do with it this week

    I am not going to pretend I will sit down and audit silicon firmware this week. I will not. But there are concrete things worth doing if you build on Azure and you care about where your keys live.

    First, read the design document end to end. Even at a surface level, understanding the attestation flow, the key hierarchy, and the boundary between firmware and host gives you a much better mental model when you are reasoning about Key Vault, Managed HSM, and confidential computing. The Managed HSM docs become much more useful once you can picture what is underneath.

    Second, look at where in your current architecture you are accepting hardware-rooted trust on faith. If you are building Power Platform solutions that pull from sensitive data sources, the keys protecting that data sit in this stack. Decisions about who owns and governs that data access matter too — something I covered in Power Platform Governance That Does Not Kill Adoption. If you are building Copilot Studio agents that call into systems holding regulated content, your trust chain runs through here. Knowing the chain is the first step to defending it in a design review.

    Third, watch how the community responds. Open-sourcing a design only matters if people actually look. The interesting signal over the next few months will be what independent researchers find, what they push back on, and how Microsoft responds. That conversation is more informative than any vendor whitepaper.

    For a deeper dive into the rationale, the Azure blog post is the place to start. My own running notes on infrastructure shifts like this end up on my LinkedIn as I work through them.

    Inspectable infrastructure is becoming the floor for serious AI workloads, and this release nudges that floor higher. The broader question of who owns the decision when agents act autonomously over that infrastructure is the next thing worth thinking through.

    This post was inspired by Enforcing trust and transparency: Open-sourcing the Azure Integrated HSM via Azure Blog.