# Azure Identity Governance Operations

Use this reference for current, source-grounded service behavior and the hard review gates that the lean `SKILL.md` intentionally does not carry.

## What people get wrong

- Treating PIM enablement as proof that privileged access is governed.
- Accepting permanent administrator assignments without activation, approval, expiration, and access-review evidence.
- Creating access packages with no resource owner, stale reviewer, or never-expiring assignment policy.
- Ignoring emergency access accounts until a lockout occurs.
- Claiming tenant compliance from documentation alone.

## Officially grounded service shape

Microsoft Learn evidence says Entra ID Governance covers entitlement management, access reviews, lifecycle workflows, and PIM. The operations guide requires task owners, testing strategy, regular reviews for applications, external identities and privileged roles, emergency access accounts, and entitlement management. Least-privilege guidance points to feature-specific administrative roles and JIT role activation through PIM.

- Identity Governance is a lifecycle control set, not a one-time role cleanup.
- Access reviews apply to groups, applications, role assignments, access packages, and external identities when the right licensing and scope exist.
- PIM supports just-in-time privileged access, but role settings, approvers, MFA, activation duration, and review cadence decide whether it is safe.
- Entitlement management uses catalogs, access packages, policies, approvals, assignment duration, and review settings; each layer needs ownership.
- Emergency access accounts are intentionally exceptional and must be protected, monitored, and periodically tested.

## Non-negotiable design rules

- Inventory standing privileged assignments before praising governance maturity.
- Require owner, reviewer, cadence, action-on-denial, and expiration for each governed access path.
- Prefer eligible JIT assignments for privileged roles and narrow scope before custom exceptions.
- Separate human operator access, workload identity access, external-user access, and break-glass access.
- Label unqueried tenant state as unverified; documentation only proves product behavior.

## Minimal safe implementation flow

- Scope the tenant, administrative planes, critical roles, external access paths, and access-package catalogs.
- Collect documentation-grounded expected controls, then gather sampled current-state evidence if available.
- Compare permanent assignments, PIM settings, access review schedules, owner coverage, and expiration posture.
- Rank gaps by blast radius: Global Administrator, Privileged Role Administrator, subscription Owner/User Access Administrator, external privileged access, and unowned packages first.
- Return blockers, safe next actions, and explicit unknowns without requesting secrets or tenant identifiers in chat.

## High-risk assumptions to kill

- PIM enabled is not governance unless privileged roles have eligible assignment scope, activation controls, approval, MFA, expiration, notifications, and recurring reviews.
- Access reviews are weak evidence when reviewers are unowned, conflicted, never act on denial, or exclude privileged and external access paths.
- Entitlement management is not safe if catalogs, packages, policies, assignment duration, approval, and review settings lack business owners.
- Emergency access accounts are not optional; missing, unmonitored, or routinely used break-glass accounts are governance failures.
- Documentation proves feature behavior, not tenant licensing, configured policies, assignment state, or compliance maturity.

## Safe command/code verification targets

- Inspect exported governance evidence for role assignments, eligible versus active state, assignment source, direct versus group-based grants, and privileged scope.
- Review PIM settings for activation duration, approval, MFA, justification, ticketing, notifications, and access review cadence.
- Check access review definitions for scope, recurrence, reviewers, fallback reviewers, auto-apply behavior, denial action, and last completion result.
- Inspect entitlement-management artifacts for catalog owner, access package resources, policies, approval stages, assignment expiration, and external-user lifecycle.
- Confirm final outputs label Microsoft Learn documentation separately from sampled configured-tenant evidence and unverified licensing assumptions.

## Safe verification targets

- Role assignment inventory distinguishes active, eligible, permanent, group-based, and direct assignments.
- PIM settings show activation duration, approval/MFA requirements, and notification/audit configuration for privileged roles.
- Access reviews have owners, recurrence, scope, reviewer selection, and automatic action behavior.
- Access packages have business owners, assignment expiration, approval policy, and review settings.
- Emergency access accounts are cloud-only, monitored, excluded from risky dependencies only where justified, and tested.

## When to push back

- The user asks for a compliant verdict without role, PIM, review, and owner evidence.
- A design depends on shared permanent administrator groups.
- Reviewers are the same people whose access is being reviewed with no compensating control.
- Break-glass accounts are missing, weakly monitored, or used for routine operations.

# Documentation and Evidence Path

## Preferred evidence order

1. Microsoft Learn documentation through the user's configured documentation MCP for documented Azure behavior.
2. Sampled read-only Azure or Kubernetes evidence, when safely available, for current configured-environment observations.
3. Sanitized user-provided evidence.
4. Clearly labeled inference.

## What each evidence type can prove

- Microsoft Learn documentation can prove documented service behavior, supported concepts, and recommended patterns.
- Sampled read-only evidence can prove the sampled configured state at the time observed.
- Sanitized user evidence can prove only what the snippet shows.
- None of these alone prove broad regional availability, future success, full account posture, or production readiness.

## Safe usage pattern

- State whether each claim is documentation-based, sampled-current-state, user-provided, or inference.
- Use read-only queries before recommending changes.
- Do not include sensitive internal identifiers, tenant identifiers, subscription identifiers, or secrets in committed docs or final findings.
- If no sampled evidence is available, say the review is documentation-based and list the exact evidence still needed.

## Asset guidance

Use Microsoft Learn documentation through the user's configured documentation MCP for documented Entra behavior. Use sampled read-only Azure evidence only for current tenant observations and label it as sampled evidence.

# Official Sources

Use these sources to ground the skill. Microsoft Learn documentation proves documented Azure behavior; it does not prove the user's tenant, RBAC, quotas, deployed resources, or production readiness.

## Primary Microsoft Learn sources

- https://learn.microsoft.com/entra/architecture/ops-guide-govern
- https://learn.microsoft.com/entra/id-governance/scenarios/least-privileged
- https://learn.microsoft.com/entra/id-governance/identity-governance-overview
- https://learn.microsoft.com/entra/id-governance/access-reviews-overview
- https://learn.microsoft.com/entra/id-governance/entitlement-management-overview
- https://learn.microsoft.com/entra/identity/role-based-access-control/best-practices
- https://learn.microsoft.com/entra/identity/role-based-access-control/security-emergency-access
- https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/identity-access

## Grounding notes

- Documentation-based claim: Microsoft Learn evidence says Entra ID Governance covers entitlement management, access reviews, lifecycle workflows, and PIM. The operations guide requires task owners, testing strategy, regular reviews for applications, external identities and privileged roles, emergency access accounts, and entitlement management. Least-privilege guidance points to feature-specific administrative roles and JIT role activation through PIM.
- Current-state claim: requires sampled read-only Azure evidence or sanitized user-provided evidence.
- Inference: allowed only when labeled and tied to observed fields or documented behavior.
- Do not include sensitive internal identifiers or secret material in findings.

## Source use rules

- Prefer Microsoft Learn documentation through the user's configured documentation MCP for current Azure service behavior.
- Use sampled read-only Azure evidence only to validate current configured-environment observations.
- If documentation and sampled evidence appear to conflict, report both and stop short of a production-ready verdict.
- Re-check official sources before changing high-risk guidance, because cloud behavior and feature availability can change.

# Safety Checklist

## Evidence labels

- `documentation-based`: grounded in Microsoft Learn or official Kubernetes documentation where listed.
- `sampled-current-state`: grounded in read-only Azure or Kubernetes observations from the user's configured tools.
- `user-provided`: grounded in sanitized snippets supplied by the user.
- `inference`: reasoned from evidence but not directly proven.

## Mutation boundary

- Default to read-only review.
- Do not perform create, update, delete, rotate, purge, recover, apply, restart, drain, cordon, scale, rollout, role-assignment, policy-assignment, or network changes unless the user explicitly asks and approval is clear.
- Prefer preview, dry-run, status, describe, what-if, list, show, and policy evaluation evidence before any mutation.

## Credential and data boundary

- Never ask users to paste credentials, tokens, tenant IDs, subscription IDs, customer data, private keys, kubeconfig contents, CA requester credentials, secret values, or connection strings.
- Summarize sensitive evidence by field presence, control state, and risk; do not reproduce secret material.

## Risk gates

- Stop on ambiguous target, ambiguous principal, missing approval, missing rollback, or missing owner for high-impact assets.
- Treat broad permissions, permanent privileged access, public exposure, purge authority, destructive operations, and live rollout changes as high-risk.
- Separate documented product behavior from sampled configured-environment evidence.

## Asset-specific hard line

Challenge standing privileged access by default. PIM, access reviews, and entitlement management are not sufficient unless scope, owner, cadence, approval, expiration, and removal behavior are explicit.

# Workflow and Output Contract

## Execution flow

1. Scope the exact asset, environment boundary, owner, and requested decision.
2. Load `official-sources.md`, then the component operations guide for service behavior and risk gates.
3. Gather sampled read-only evidence only when available and safe.
4. Compare observed posture against documented behavior, least-privilege expectations, and operational safety rules.
5. Return a verdict with evidence level, blockers, safe next actions, and open questions.

## Required output

- `verdict`: pass, warn, fail, or blocked.
- `evidence_level`: documentation-based, sampled-current-state, user-provided, inference, or mixed.
- `scope`: what was reviewed and what was not reviewed.
- `blockers`: issues that prevent a safe or production-ready conclusion.
- `findings`: severity-labeled risks with source labels.
- `safe_next_actions`: reversible actions first; mutation only with explicit approval.
- `open_questions`: missing facts that would change the verdict.

## Stress checks

- What assumption would make this recommendation unsafe?
- Which role, policy, network, lifecycle, or rollout action has the largest blast radius?
- What evidence would disprove the claimed readiness?
- Is the answer accidentally treating documentation as tenant-specific proof?

## Response discipline

Use Microsoft Learn documentation through the user's configured documentation MCP for documented Entra behavior. Use sampled read-only Azure evidence only for current tenant observations and label it as sampled evidence.