A full AI IAM architecture diagram

We’re going from jokes to real architecture now ;D


Here you go

  1. A full architecture diagram (described + Mermaid you can paste into tools)
  2. A step-by-step implementation guide for an end-to-end AI IAM workflow in Azure.

I’ll anchor this around a concrete example:

AI-powered stale-account + risky-sign-in remediation workflow
…but the pattern works for PIM justifications, suspicious role assignments,

High-Level Architecture Diagram

Components

  • Identity & Logs
    • Microsoft Entra ID (users, groups, roles, sign-ins, audit)
    • Entra Sign-in Logs & Audit Logs → Log Analytics
  • Detection & Analytics
    • Log Analytics Workspace
    • Microsoft Sentinel (analytics rules + incidents)
  • AI Reasoning Layer
    • Azure OpenAI (or “AI Skills” via Logic Apps / Cognitive Services)
    • Optional: Custom prompt templates for IAM decisions
  • Automation & Orchestration
    • Logic Apps (Sentinel playbooks)
    • Azure Functions (optional for custom logic)
  • IAM Action Layer
    • Microsoft Graph API (via managed identity)
    • Entra ID (disable account, require MFA, remove role, trigger PIM flow)
  • Notification & Governance
    • Email / Teams / Slack (Logic App connectors)
    • ITSM tool (ServiceNow / Jira / etc via connector)
    • Storage / Log Analytics for full audit trail


Flow Summary

  1. Event happens: risky sign-in OR stale account detected via KQL in Sentinel.
  2. Sentinel Incident created.
  3. Sentinel playbook (Logic App) is triggered.
  4. Logic App calls Azure OpenAI:
    • Sends context: user info, sign-in history, risk level, groups, roles, etc.
    • AI returns classification + recommendation (e.g., “likely stale”, “high-risk login”, “needs human approval”).
  5. Logic App branches:
    • Low risk → log & close.
    • Medium risk → notify and require manual approval.
    • High risk → auto-remediate via Graph API + notify SOC.
  6. Graph API executes IAM changes (via managed identity):
    • Disable account
    • Revoke sessions
    • Enforce MFA
    • Remove risky assignments
  7. Audit & Tickets:
    • Incident updated in Sentinel
    • ITSM ticket created / updated
    • Full reasoning + actions stored.


Mermaid Diagram (You Can Paste This)

Paste this into any Mermaid-compatible tool (including many diagram editors, VS Code extensions, etc.):

flowchart LR

    subgraph Users_and_Identity

        U[Users / Service Accounts]

        AAD[Microsoft Entra ID]

    end


    subgraph Logging

        SIGNS[Sign-in Logs]

        AUDIT[Audit Logs]

        LAW[Log Analytics Workspace]

    end


    subgraph SIEM

        SENT[Microsoft Sentinel\nAnalytics Rules + Incidents]

    end


    subgraph Automation

        PLB[Sentinel Playbook\n(Azure Logic App)]

        FN[Azure Functions\n(optional)]

    end


    subgraph AI

        AOAI[Azure OpenAI\nAI Reasoning]

    end


    subgraph IAM_Action

        GRAPH[Microsoft Graph API\n(via Managed Identity)]

        IAM[Entra ID Changes\n(Disable, MFA, Roles)]

    end


    subgraph Governance

        NOTIF[Teams / Email / Slack]

        ITSM[ITSM Tool\n(ServiceNow/Jira/etc)]

        AUDSTORE[Audit Log\n(Storage/LAW)]

    end


    U -->|Sign-ins| AAD

    AAD --> SIGNS

    AAD --> AUDIT

    SIGNS --> LAW

    AUDIT --> LAW

    LAW --> SENT


    SENT -->|Incident Trigger| PLB

    PLB --> AOAI

    AOAI --> PLB


    PLB -->|Optional complex logic| FN

    PLB --> GRAPH

    GRAPH --> IAM


    PLB --> NOTIF

    PLB --> ITSM

    PLB --> AUDSTORE


Step-by-Step Implementation Guide

I’ll break it into phases so you can treat this like a mini-project.

Phase 0 – Prereqs & Design Decisions

  1. Decide your initial use case(s):

    2. •  Stale accounts (no sign-in in X days)

    •  Risky sign-ins / impossible travel

    •  PIM justification quality / risk scoring

    •  Suspicious role assignments (e.g., Global Admin, Privileged Role Admin)

  2. Confirm you have:
    • An Azure subscription with:

      • •  Microsoft Entra ID (obviously)

      •  Microsoft Sentinel licenses

      •  Log Analytics workspace

    • Access to:

      • •  Azure OpenAI or AI-powered connectors in Logic Apps

      •  Microsoft Graph API via managed identity

    • A dev/test environment (please don’t start in prod 😅).
  3. Define IAM policy for actions:
    • What risk levels map to:

      • •  Just log

      •  Alert only

      •  Require approval

      •  Auto-remediate

You’ll need this baked before you let automation touch accounts.


Phase 1 – Enable & Normalize Identity Logging

  1. Enable diagnostic settings for Entra ID:
    • In Entra admin center → Monitoring & health → Diagnostic settings
    • Send:

      • •  Sign-in logs

      •  Audit logs

    • Destination: Log Analytics Workspace (LAW).
  2. Confirm data is flowing:

    3. •  In Log Analytics, run sample KQL:

    SigninLogs

    | top 10 by TimeGenerated desc

    And:

    AuditLogs

    | top 10 by TimeGenerated desc

  3. Connect Sentinel to this LAW:

    4. •  In Microsoft Sentinel → attach workspace.

    •  Enable basic security content as needed.


Phase 2 – Build Detection Logic in Sentinel (KQL Rules)

A. Stale Accounts Example

Create a scheduled analytics rule to find accounts with no sign-in in X days:


Kusto:

let InactiveDays = 120;

let activeUsers = SigninLogs

    | where TimeGenerated > ago(InactiveDays * 1d)

    | summarize LastSignIn = max(TimeGenerated) by UserId, UserPrincipalName;

AuditLogs

| where OperationName == "Add user" or OperationName == "Update user"

| summarize CreatedOrModified = max(TimeGenerated) by TargetResources[0].id, TargetResources[0].userPrincipalName

| join kind=leftouter activeUsers on $left.TargetResources_0_userPrincipalName == $right.UserPrincipalName

| extend DaysSinceLastSignIn = datetime_diff("day", now(), LastSignIn)

| where isnull(LastSignIn) or DaysSinceLastSignIn >= InactiveDays

Use that as the base for a Scheduled analytics rule.

B. Risky Sign-ins Example

You can use built-in Risky Sign-in sources or custom KQL with impossible travel / geo anomalies.


Phase 3 – Create the Sentinel Playbook (Logic App)

  1. In Sentinel:

    2. •  Go to Automation → Playbooks → Create → Playbook with incident trigger.

  2. Add a trigger:

    3. •  Trigger: When a response to an Azure Sentinel alert is triggered.

  3. Parse incident details:

    4. •  Add a step: Parse JSON (optional) to work with incident entities.

  4. Get user details:

    5. •  Use the Microsoft Graph connector or generic HTTP + managed identity:

      •  Example: GET https://graph.microsoft.com/v1.0/users/{userPrincipalName}

  5. Prepare AI input payload:

    6. •  Build a Compose action with context like:

      •  UserPrincipalName

      •  Last sign-in time

      •  Number of risky sign-ins

      •  Roles / groups

      •  Whether account looks like contractor/service account


      Example (simplified JSON):

      {

       "userPrincipalName": "@{variables('Upn')}",

       "lastSignIn": "@{variables('LastSignIn')}",

       "roles": "@{variables('Roles')}",

       "riskSignals": "@{variables('RiskSignals')}",

        "scenario": "StaleAccountOrRiskySignin"

      }


Phase 4 – Add the AI Reasoning Step (Azure OpenAI)

If you don’t have Azure OpenAI, you can conceptually swap this for “AI Builder” or wait for built-in AI actions in Logic Apps — but I’ll describe the OpenAI-style pattern.

  1. Create an Azure OpenAI resource:

    2. •  In Azure Portal → Create Azure OpenAI.

    •  Deploy a suitable model (e.g., GPT-4-type).

  2. In Logic App:
    • Add HTTP action to call your Azure OpenAI endpoint:

      • •  Method: POST

      •  URL: https://<your-openai-resource>.openai.azure.com/openai/deployments/<model-name>/chat/completions?api-version=<api-version>

      •  Headers:

        •  api-key: <Azure OpenAI key> (store in Key Vault ideally)

        •  Content-Type: application/json•  


        Body (example):

        JSON:

        {

        "messages": [

         {

              "role": "system",

              "content": "You are an IAM risk analysis assistant. You classify identity events and propose safe actions following least privilege and corporate IAM policies."

            },

            {

             "role": "user",


             "content": "Analyze this identity context and return JSON with fields: riskLevel (Low, Medium, High), reason, recommendedAction (LogOnly, Notify, RequireApproval, AutoRemediate). Context: @{outputs('Compose_AI_Context')}"

            }

          ],

          "temperature": 0.1

        }

  3. Parse AI output:
    • Use Parse JSON to extract:

      • •  riskLevel

      •  reason

      •  recommendedAction


Phase 5 – Branch Logic & Take IAM Actions

  1. Add a Switch / Condition on recommendedAction:
    • Case: LogOnly
    • •  Add a step to write the AI decision to:

        • •  Log Analytics

        •  Or Storage•  Close incident (optional).

    • Case: Notify
      • Send message to:
        • Teams / Email / Slack: “AI flagged user X as Medium risk. Reason: Y. Please review.”
      • Update Sentinel incident with AI reasoning.
    • Case: RequireApproval

      • •  Create approval workflow:

        •  Use Logic Apps approval connector

        •  Or post an Actionable Message in Teams

        •  On approval → proceed to remediation

        •  On rejection → log & close.


    • Case: AutoRemediate
      • Call Microsoft Graph API via managed identity:
        • Example actions:
          • Disable account:
          • PATCH https://graph.microsoft.com/v1.0/users/{id}
          • {
          •   "accountEnabled": false
          • }
          • Revoke sign-in sessions:
          • POST https://graph.microsoft.com/v1.0/users/{id}/revokeSignInSessions
      • Document everything in Sentinel/incidents + ITSM.
  2. Set up Graph permissions:
    • Assign a system-assigned managed identity to the Logic App.
    • In Entra ID:
      • Grant it roles like:
        • Directory Readers
        • User Administrator (or more scoped custom roles)
    • In Entra ID → Enterprise Apps:
      • Ensure it has Microsoft Graph application permissions as needed (if using app reg) or appropriately scoped delegated permissions.


Phase 6 – Notifications, ITSM & Audit Trail

  1. Notifications:
    • Use Logic App connectors:

      • •  Send an email (V2)

      •  Post message in Teams

  2. ITSM Integration:
    • Connector: ServiceNow / Jira, etc
    • Create or update ticket with:
      • User
      • Detection signal
      • AI reasoning text
      • Actions taken
      • Who approved (if applicable)
  3. Audit Trail:
    • Write a structured log to:
      • Log Analytics
      • Or Blob Storage / Table
    • Include:
      • Incident ID
      • UserPrincipalName
      • AI input context
      • AI decision JSON
      • IAM changes performed
      • Time stamps


Phase 7 – Testing, Tuning & Rollout

  1. Dry-run mode first:
    • Log-only / notify-only.
    • No automatic disabling of accounts until confident.
  2. Tune prompts & logic:
    • Watch for false positives/negatives.
    • Adjust AI prompt:
      • Stricter or more conservative.
    • Adjust KQL logic thresholds.
  3. Gradual rollout:
    • Start with:
      • Test OU
      • Specific groups (e.g., contractors)
    • Expand to full org once stable.
  4. Operationalize:
    • Document runbooks.
    • Train SOC / IAM teams:
      • “When AI flags something, here’s how to interpret it.”
    • Add dashboards:
      • AI decisions
      • Risk levels over time
      • Manual vs auto remediation counts.