Introduction

A customer came to me with a problem that many organisations have. They control their infrastructure through Infrastructure as Code, but there are often scenarios where an admin needs to go in and make a change – even though they would ideally not want this to happen. The use an Entra feature Privileged Identity Management (PIM). Users statically don’t have contributor access to Azure resources, but PIM allows them to elevate their access for a period of time. As part of PIM, the admin needs to give a reason for the elevation. Wouldn’t it be good if an agent of some sort could look at this reason, then look at what the user actually did and make an assessment on whether what they did aligned with the reason given? Then alert if not.

I initially built Python agents to handle this, but as with many “build vs. buy” decisions, I eventually discovered that Azure SRE Agent (in preview at the time of writing) could do what I needed – and more.

This blog chronicles my journey from initial scepticism to building a fully autonomous PIM elevation audit agent. Along the way, I learned valuable lessons about what SRE Agent is designed for, how to work with its tooling model, and the difference between interactive exploration and production automation.

The Starting Point: Python Agents and the Buy vs. Build Decision

Before discovering SRE Agent, I had functional Python scripts that queried Azure Audit Logs and Activity Logs to correlate PIM activations with actual Azure operations. They worked, but they required maintenance, error handling, scheduling infrastructure, and ongoing attention. When I heard about Azure SRE Agent’s capabilities as an autonomous monitoring platform, I decided to investigate.

The decision: If there’s a choice between buy versus build, buy should win – especially when the “buy” option is a managed Azure service with built-in security, monitoring, and integration capabilities.

First Impressions: The Interactive Front End

One of the first features that caught my attention was SRE Agent’s chat interface. Unlike my static Python scripts, I could have conversational interactions with the agent, refining queries and exploring my Azure environment in natural language. This was powerful for discovery and prototyping.

Initial Success (and Failure)

When I first asked SRE Agent to analyse PIM elevation patterns, the results were… disappointing. The agent couldn’t initially answer my PIM elevation questions effectively. However, this is where the interactive experience shone: through. With  coaching in an interactive session, I could:

– Explain what PIM activation events look like in Azure Audit Logs

– Show the agent how to correlate `CorrelationId` between activation requests and justifications

– Demonstrate how to build time windows from activation start to deactivation/expiration

– Guide it through matching Azure Activity operations against justification keywords

After several rounds of refinement, the agent eventually got excellent results. The interactive session wasn’t just a chatbot – it was a learning tool that helped me shape the agent’s behaviour.

The Subagent Puzzle: Interactive vs. Headless

What I really needed was an autonomous agent that could run on a schedule. As I got better results from the interactive sessions, 

Subagents is the tool in SRE Agent for this.

I naturally wanted to convert the interactive session into a subagent that could run autonomously. This is where I hit my first conceptual stumbling block.

The Aha Moment: Understanding SRE Agent’s Purpose

I was initially confused about how to structure a subagent. Should it replicate the interactive conversation flow? How do I capture all that back-and-forth in a static configuration?

After discussions with the engineering, I learned a critical lesson:

Azure SRE Agent is really designed for headless SRE agents

The interactive experience is fantastic for exploration, prototyping, and troubleshooting – but it’s not what you should be aiming for in production automation.

This reframed my entire approach. Instead of trying to replicate the conversational flow, I needed to distil my learnings from those sessions into the instructions for a subagent.

Struggling with Subagent Format

Even with this clarity, I struggled with the format of a subagent definition. The YAML structure, the `system_prompt` verbosity, the tool declarations – it felt overwhelming to translate my interactive sessions into a configuration file.

The Game-Changer: Let the Agent Write Itself

Then came the game-changing advice from engineering:

Ask the chat session to create the subagent definition for you.

This was brilliant in its simplicity. I had already what I wanted the agent to do in the interactive chat session. It was a simple as “generate a subagent from this conversation”. I must admit, I did have to ask it to generate an email with the report, but the bulk of the effort in generating the YAML subagent file was done by the agent.

What would have taken me hours of trial and error was done in minutes.

Tool Configuration: The Missing Pieces

With a subagent definition in hand, I deployed it and… nothing worked. This began the most educational part of my journey: understanding how tools work in Azure SRE Agent.

Challenge #1: Accessing Log Analytics

My subagent kept failing to query Log Analytics. I initially thought this was a role assignment issue – did the agent’s managed identity have Log Analytics Reader permissions? I spent time checking RBAC, verifying workspace access, and reviewing Entra ID permissions.

The real issue? I needed to add `QueryLogAnalyticsByWorkspaceId` as a tool in my subagent configuration!

tools: – QueryLogAnalyticsByWorkspaceId

The Azure SRE Agent UI supports selecting this tool during configuration, but I had missed it. More importantly, I needed to mention the Log Analytics workspace ID in my subagent’s `system_prompt` so the agent knew which workspace to target:

system_prompt: > … Query the workspace: XXXXXX-d119-4550-86c0-YYYYYYYYYYY…

Lesson learned: Tools aren’t automatically available – you must explicitly declare them. The agent uses this to understand what capabilities it has and to configure the appropriate authentication and access patterns.

Challenge #2: Sending Email Notifications

The next hurdle was sending email reports. My PIM audit was working beautifully, but the results were only visible in logs. I needed email notifications.

Initially, there didn’t seem to be a built-in email tool I could choose from the portal. I attempted to write a custom Python tool that sent emails via Microsoft Graph API. This seemed logical – I’d done this in my previous Python agents.

Problem: Corporate email policies blocked my application from sending emails via Graph. This was a security feature, not a bug, but it meant my custom tool approach was dead in the water.

Discovering the Outlook Connector

Then I noticed the Outlook connector in the SRE Agent configuration portal. This was a managed connector specifically for sending emails with pre-configured authentication. I set it up, configured it (noting the connector ID: `connector-abf2`), and waited for emails.

Still nothing.

The Manual YAML Edit

Trawling through other sample subagent configurations, I discovered a tool called SendOutlookEmail. This tool wasn’t available in the portal’s dropdown menu, but it existed in the platform. I needed to **manually add this to my subagent YAML file**:

tools: – QueryLogAnalyticsByWorkspaceId – SendOutlookEmail

After this change and redeploying the subagent, emails started flowing perfectly.

Lesson learned: The portal UI is evolving (remember, this is preview), and not all tools are exposed visually yet. Don’t be afraid to hand-edit the YAML when you know a capability exists. The documentation and sample repositories are your friends.

Making It Fully Autonomous: Scheduled Triggers

With a working subagent that could query logs, analyse alignment, and send emails, I had one final step: scheduling it.

I created a scheduled task trigger in Azure SRE Agent configured to run every 24 hours (UTC). This trigger invokes my PIM elevation subagent, which executes its entire workflow autonomously and emails stakeholders with any findings.

The subagent configuration includes this execution schedule guidance:

system_prompt: > Execution schedule: Run every 24h (UTC).

Now, every morning, our security team receives a PIM elevation alignment report without any manual intervention.

The Result: A Production PIM Elevation Agent

My final solution is an **autonomous agent** that:

1. Runs on a 24-hour schedule


2. Queries Azure Audit Logs for PIM activations


3. Extracts user justifications from the log


4. Builds precise activation time windows


5. Queries Azure Activity logs during that time window


6. Classifies alignment: Aligned, Partial, or NotAligned


7. Generates JSON and plaintext reports


8. Emails stakeholders with flagged non-aligned activity

No Python scripts. No custom authentication handling. No infrastructure to maintain.

You can see the full subagent configuration in my GitHub repository: PIM Elevation Agent

Reflections: SRE Agent’s Power and Rough Edges

Azure SRE Agent is powerful. The ability to define complex audit workflows in declarative YAML, leverage natural language prompts for behaviour specification, and integrate with Azure services through managed tools is genuinely impressive.

It also integrates with incident response services – both being able to generate incidents and to trigger flows from incidents.

All as a first-class Azure Platform as a Service (PaaS).

However, it’s important to remember that this is a preview service (as of February 2026). There are rough edges:

– Tool discoverability: Not all tools are visible in the portal UI

– Documentation gaps: Some capabilities require digging through samples

– Learning curve: Understanding the interactive-vs-headless paradigm takes time

– Debugging: Error messages aren’t always clear about what’s misconfigured

These are typical preview-stage challenges, and I expect they’ll improve as the service matures. The core platform is solid, and the engineering team is responsive to feedback.

Key Takeaways

If you’re considering Azure SRE Agent, here are my lessons learned:

1. Use interactive sessions for discovery – They’re excellent for prototyping and learning


2. Think headless/autonomous for production – Autonomous agents should be declarative, not conversational


3. Let the agent write itself – Ask the interactive session to generate subagent configs


4. Explicitly declare tools – They’re not automatic; you must add them to your config


5. Include context in prompts – Workspace IDs, connector IDs, schedules – be specific


6. Don’t fear manual YAML edits – The portal is evolving, hand-editing is ok


7. Check samples and docs*– Other configurations show patterns and tools not yet in UI, so check the YAML of these


8. Embrace “buy over build” – Managed services reduce long-term maintenance burden

Resources:

– SRE Agent Documentation

– my PIM Elevation subagent sample

– Kusto (KQL) Query Reference

 

*This blog post represents my personal experience and opinions. Azure SRE Agent capabilities and UI may have changed since the time of writing.*