Lab: Just-In-Time Access for AI Agents in Azure

A hands-on lab deploying a ZSP gateway that manages time-bounded access for non-human identities (AI agents, service principals, automation) and human administrators.

Cost: Variable by region, execution volume, logging, storage, and retention. Review current Azure Functions, Storage, and Log Analytics pricing before deployment. Cleanup: Run the repository’s manifest-driven cleanup script. It validates immutable Entra object IDs and provenance before deleting those objects; Azure resource-group deletion is a separate explicit switch.

Blog Post: For detailed explanations of the architecture and security concepts, see Just-In-Time Access for AI Agents.

Why NHI Security Matters

AI agents and automation workflows need Azure access. Giving them standing permissions is the wrong answer:

• AI coding assistants requesting temporary access to deploy infrastructure
• Backup automation needing Key Vault secrets only during backup windows
• CI/CD pipelines requiring temporary scoped write access for deployments
• Security scanners needing read access on a schedule

This lab demonstrates the Zero Standing Privilege pattern for the subject service principals and human administrators: they start without the target roles and receive time-bounded access on demand.

Tier 0 boundary: the broker is not zero-privilege. Its Function managed identity retains tenant-wide RoleManagement.ReadWrite.Directory, which can assign any directory role, including Global Administrator, plus scoped Azure role-management authority. The design relocates standing privilege into one audited workload; it does not eliminate it. Treat the Function App, deployment principals, and code path as Tier 0 assets. The canonical README’s What This Does Not Eliminate section is required reading before deployment.

Prerequisites

• Azure subscription with Owner access
• Azure CLI configured (az login)
• PowerShell 7+ (pwsh)
• Entra ID P1 or P2 license (for group-based role assignment)
• Privileged Role Administrator directory role (required to create role-assignable Entra groups)
• Permission to create applications/service principals, grant the documented Microsoft Graph application permissions with admin consent, activate/assign the two directory roles, and create Azure role assignments
• Log Analytics Contributor and Monitoring Contributor capabilities used for the custom table and DCR, whether supplied directly or through a broader lab role
• (Optional) Azure Functions Core Tools for local testing

Architecture

Components:

• Access Requestors — Backup Service Principal (NHI), Human Administrator, Durable Timer (auto-revoke)
• ZSP Function Gateway — Validates requests, creates RBAC role assignments, manages Entra group membership, schedules revocation timers, emits audit events
• Target Resources — Key Vault (secrets), Storage Account (blob data)
• Audit Pipeline — Data Collection Endpoint (DCE) + Data Collection Rule (DCR) → Log Analytics ZSPAudit_CL custom table

Quick Start

1. Open the Lab Files

# From a local checkout of this repository:
cd labs/zsp-azure

2. Deploy

Live-mutation warning: Deploy-Lab.ps1 has no -WhatIf mode. It performs live Azure, Microsoft Graph, Entra directory-role, RBAC, Function deployment, and smoke-test operations. Before running it, inspect the active subscription and tenant, review every parameter, confirm the Tier 0 permission boundary, and use only an isolated lab environment.

./scripts/Deploy-Lab.ps1

Or with custom settings:

./scripts/Deploy-Lab.ps1 -ProjectName "my-zsp" -Location "westus2"

The script will:

1. Deploy Azure resources via Bicep (Resource Group, Key Vault, Storage, Function App, Log Analytics, DCE)
2. Create Entra ID objects (ZSP groups, directory role assignments, backup SP)
3. Create the ZSPAudit_CL custom table and Data Collection Rule (DCR)
4. Grant Graph API permissions and RBAC roles to the Function App managed identity
5. Configure Function App settings with Entra object IDs, DCR endpoint, and schedule
6. Deploy Function code
7. Run a smoke test

3. Save the Endpoints

After deployment completes, note the outputs (resource names include a unique suffix):

Function App URL: https://<project>-gw-<suffix>.azurewebsites.net
ZSP Groups:
  Intune Admins:   <group-id>
  Security Reader: <group-id>
Backup Service Principal: <sp-object-id>

Before requesting access, call GET /api/health. HTTP 200 with status: healthy means the audit ingestion dependency is ready. Missing or malformed DCR_ENDPOINT or DCR_RULE_ID settings return HTTP 503 with status: degraded; request admission, scheduled grants, and grant activities all fail closed before changing privilege. Existing deployments must update the ZSPAudit_CL table and DCR schema before deploying this Function version.

Test NHI Access (Primary Use Case)

Grant Service Principal Access

Request temporary Key Vault access for the configured backup service principal:

FUNCTION_URL="https://<project>-gw-<suffix>.azurewebsites.net"
FUNCTION_KEY="<from deployment output>"
BACKUP_SP_ID="<backup-sp-object-id>"
KEYVAULT_ID="/subscriptions/<sub>/resourceGroups/<project>-rg/providers/Microsoft.KeyVault/vaults/<keyvault-name>"

NHI_RESPONSE="$(curl --fail --silent --show-error -X POST "$FUNCTION_URL/api/nhi-access" \
  -H "Content-Type: application/json" \
  -H "x-functions-key: $FUNCTION_KEY" \
  -d '{
    "sp_object_id": "'"$BACKUP_SP_ID"'",
    "scope": "'"$KEYVAULT_ID"'",
    "role": "Key Vault Secrets User",
    "duration_minutes": 10,
    "workflow_id": "manual-test"
  }')"

echo "$NHI_RESPONSE" | jq .
STATUS_URL="$(echo "$NHI_RESPONSE" | jq -r '.statusQueryGetUri')"

Expected HTTP 202 Durable management response (URLs abbreviated):

{
  "id": "b10a200905204d0bb10d54fc4e1a73e0",
  "statusQueryGetUri": "https://.../runtime/webhooks/durabletask/instances/...",
  "sendEventPostUri": "https://...",
  "terminatePostUri": "https://...",
  "purgeHistoryDeleteUri": "https://..."
}

The 202 response means the safety workflow was accepted, not that access is already active. Poll the management URL and wait for customStatus.status to become active:

while true; do
  STATUS="$(curl --fail --silent --show-error "$STATUS_URL")"
  echo "$STATUS" | jq '{runtimeStatus, customStatus}'
  [ "$(echo "$STATUS" | jq -r '.customStatus.status // empty')" = "active" ] && break
  case "$(echo "$STATUS" | jq -r '.runtimeStatus')" in
    Failed|Terminated|Completed) exit 1 ;;
  esac
  sleep 2
done

Only then should the role assignment be used. A failed, terminated, or already completed orchestration means access must not be assumed.

Verify Role Assignment

az role assignment list \
  --assignee "$BACKUP_SP_ID" \
  --scope "$KEYVAULT_ID" \
  --query "[].roleDefinitionName"

Verify Revocation

Wait 10 minutes, then check again:

az role assignment list \
  --assignee "$BACKUP_SP_ID" \
  --scope "$KEYVAULT_ID" \
  --query "[].roleDefinitionName"
# Should return empty list

Test Human Admin Access

The gateway also supports human administrators who need temporary Entra ID role access:

Request Admin Access

ADMIN_RESPONSE="$(curl --fail --silent --show-error -X POST "$FUNCTION_URL/api/admin-access" \
  -H "Content-Type: application/json" \
  -H "x-functions-key: $FUNCTION_KEY" \
  -d '{
    "user_id": "YOUR_ENTRA_USER_OBJECT_ID",
    "group_id": "<intune-admin-group-id>",
    "duration_minutes": 15,
    "justification": "Investigating device compliance issue - ticket INC0012345"
  }')"

echo "$ADMIN_RESPONSE" | jq .
ADMIN_STATUS_URL="$(echo "$ADMIN_RESPONSE" | jq -r '.statusQueryGetUri')"

Poll ADMIN_STATUS_URL with the same lifecycle check and wait for customStatus.status == "active" before attempting administrative work.

Verify Access

az ad group member list --group "<intune-admin-group-id>" --query "[].displayName"

Verify Revocation

Wait for expiry, then check again:

az ad group member list --group "<intune-admin-group-id>" --query "[].displayName"
# Should return empty list

Admin Lifecycle Ownership and Recovery

Human-admin requests for the same user/group pair are serialized through a Durable Entity owner lock. A second lifecycle cannot adopt the membership while another instance owns it. Before compensation or expiry revocation, the orchestrator verifies that the exact same instance still owns the lock; it releases the lock only after the membership has been removed successfully.

If the entity confirms a different owner, status becomes ownership_lost. If the ownership lookup itself fails, status becomes ownership_unverified. Both paths attempt a correlated failed-revoke audit event, retain the owner lock, and refuse to delete the membership. If either status appears, cleanup fails, or a lifecycle fails with its owner lock retained:

1. Stop new requests for that user/group pair and preserve the orchestration ID.
2. Inspect the Durable instance history, Entra audit logs, and current group membership to determine whether the failed lifecycle created the membership.
3. Remove the user manually only after that attribution is confirmed. A Graph group-membership edge has no per-membership owner token, so do not remove a pre-existing or independently managed membership.
4. After confirming the entitlement is absent, repair or purge the matching admin_entitlement_owner Durable Entity state. In this disposable lab, a task-hub reset/redeployment is the fallback if targeted entity recovery is unavailable.
5. Re-run verification before accepting another request.

Never clear the entity first: doing so can allow an overlapping grant while the old membership still exists. For the same reason, do not modify privileged ZSP group memberships manually during an active lifecycle.

Treat the function key and Durable management URLs as credentials. Send the function key only in x-functions-key as shown above, and keep management URLs out of shared logs because they contain access tokens in their query strings.

View Audit Logs

Every new grant, revoke, and ownership-guard failure contains two exact correlation keys: LifecycleId is the Durable orchestration instance ID, and EntitlementId is the deterministic admin ownership key or complete Azure role assignment resource ID. Use both fields together; principal and target alone cannot distinguish repeated lifecycles safely.

Query Log Analytics

WORKSPACE_ID="<log-analytics-workspace-id>"

az monitor log-analytics query \
  --workspace "$WORKSPACE_ID" \
  --analytics-query "ZSPAudit_CL | where TimeGenerated > ago(1h) | project TimeGenerated, EventType, IdentityType, PrincipalId, Target, LifecycleId, EntitlementId" \
  --output table

Sample Queries

All access grants (last 24 hours):

ZSPAudit_CL
| where TimeGenerated > ago(24h)
| where EventType == "AccessGrant"
| project TimeGenerated, IdentityType, PrincipalId, Target, Role, DurationMinutes, LifecycleId, EntitlementId
| order by TimeGenerated desc

Failed access attempts:

ZSPAudit_CL
| where TimeGenerated > ago(24h)
| where Result == "Failed"
| project TimeGenerated, IdentityType, PrincipalId, LifecycleId, EntitlementId, ErrorMessage

Expired grants without an exact successful revoke:

let grace = 15m;
let exact_grants =
    ZSPAudit_CL
    | where EventType == "AccessGrant" and Result == "Success"
    | where isnotempty(ExpiresAt)
    | extend Expiry = todatetime(ExpiresAt)
    | where Expiry < ago(grace)
    | where isnotempty(LifecycleId) and isnotempty(EntitlementId)
    | summarize GrantTime = min(TimeGenerated), LastExpiry = max(Expiry),
        PrincipalId = take_any(PrincipalId), Target = take_any(Target),
        Role = take_any(Role), IdentityType = take_any(IdentityType)
      by LifecycleId, EntitlementId;
let exact_revokes =
    ZSPAudit_CL
    | where EventType == "AccessRevoke" and Result == "Success"
    | where isnotempty(LifecycleId) and isnotempty(EntitlementId)
    | summarize RevokeTime = max(TimeGenerated) by LifecycleId, EntitlementId;
let exact_findings =
    exact_grants
    | join kind=leftanti exact_revokes on LifecycleId, EntitlementId
    | extend CorrelationStatus = "Exact",
        Finding = "Expired lifecycle entitlement with no successful revoke";
let legacy_findings =
    ZSPAudit_CL
    | where EventType == "AccessGrant" and Result == "Success"
    | where isnotempty(ExpiresAt)
    | extend LastExpiry = todatetime(ExpiresAt)
    | where LastExpiry < ago(grace)
    | where isempty(LifecycleId) or isempty(EntitlementId)
    | extend CorrelationStatus = "LegacyUncorrelated",
        Finding = "Legacy expired grant lacks exact lifecycle correlation; review manually";
union exact_findings, legacy_findings
| order by LastExpiry asc

Alert on CorrelationStatus == "Exact". Route LegacyUncorrelated rows to manual review instead of guessing a match from principal and target.

NHI access outside normal patterns:

ZSPAudit_CL
| where TimeGenerated > ago(7d)
| where IdentityType == "nhi"
| where EventType == "AccessGrant"
| summarize count() by bin(TimeGenerated, 1h), PrincipalId
| where count_ > 5

File Structure

The bundled lab is an exact mirror of the pinned upstream revision. Its main surfaces are bicep/, function/, and scripts/; the bundle also includes the upstream validation workflow, dependency pins, unit and contract tests, license, and canonical README. In particular, cleanup is implemented by scripts/Cleanup-Lab.ps1. Use the pinned repository tree as the authoritative inventory instead of copying a second file tree into this page.

Configuration Options

Maximum Access Duration

Edit the -MaxAccessDurationMinutes parameter when deploying:

./scripts/Deploy-Lab.ps1 -MaxAccessDurationMinutes 240

Supported Roles (NHI)

The gateway supports these Azure built-in roles:

Add Custom Roles

Edit function/nhi_access.py to add role definition IDs:

ROLE_DEFINITIONS = {
    # ... existing roles ...
    "Custom Role Name": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
}

Cleanup

Before cleanup, stop new requests, poll every Durable instance, revoke and verify every active group membership and RBAC grant, and confirm the two privileged groups have no direct members. Deleting the Function App while revocation timers are outstanding can strand privilege.

Preview the manifest-recorded exact-ID cleanup first:

./scripts/Cleanup-Lab.ps1 -ConfirmProject "zsp-lab" -WhatIf

The preview performs read-only Azure and Graph lookups and validates the active tenant/subscription, project confirmation, manifest consistency, immutable Entra object IDs, provenance, exact names, group emptiness, application/service-principal linkage, and resource-group ownership tags. It never falls back to display-name discovery.

Remove the exact manifest-recorded Entra groups, application, and service principal:

./scripts/Cleanup-Lab.ps1 -ConfirmProject "zsp-lab"

For full cleanup, explicitly include the exact owner-tagged Azure resource group:

./scripts/Cleanup-Lab.ps1 -ConfirmProject "zsp-lab" -DestroyAzureResources -WhatIf
./scripts/Cleanup-Lab.ps1 -ConfirmProject "zsp-lab" -DestroyAzureResources

Resource-group deletion is asynchronous. Preserve the manifest and rerun cleanup after Azure reports the group absent; only then can the script prove every recorded object is gone and remove the manifest. Never replace this workflow with raw resource-group deletion or Entra deletion by display name.

Troubleshooting

Deployment Fails on Entra ID Objects

Entra ID has eventual consistency and the scripts include retry logic. If a deployment fails, preserve .zsp-deployment.json and rerun the main manifest-aware orchestrator with the same project name:

./scripts/Deploy-Lab.ps1 -ProjectName "zsp-lab"

On a normal rerun the complete identity set is loaded from the manifest. If the manifest is unavailable but the original four immutable Entra object IDs are known, follow the explicit all-four Expected*ObjectId example in the canonical README. Do not invoke Setup-EntraID.ps1 by display name or supply only a partial ID set; both paths fail closed to prevent adopting foreign tenant objects.

Function App Returns 500

Check Application Insights for errors:

az monitor app-insights query \
  --apps "zsp-lab-insights" \
  --analytics-query "exceptions | where timestamp > ago(1h) | project timestamp, problemId, outerMessage"

Graph API Permission Denied

Ensure the managed identity has admin consent:

./scripts/Grant-Permissions.ps1 \
  -FunctionAppPrincipalId "<function-principal-id>" \
  -ResourceGroupId "<resource-group-id>"

Resources

• Blog: Just-In-Time Access for AI Agents
• Microsoft Graph PIM APIs
• Azure Durable Functions
• Bicep Documentation