# Adjacent Microsoft service expansion

Use this reference only when the user asks about a Microsoft service that is related to Entra identity posture but wasn't explicitly called out in the main skill text.

## Rule

Do not freeze the role to the currently named services.

When the user mentions another Microsoft service, first determine whether the real question is about:

1. **identity plane**
2. **licensing / entitlement**
3. **service-specific policy behavior**
4. **cross-service integration**

Then consult the official docs before concluding.

## Learning-and-evolution workflow

1. Identify the service name exactly.
2. Decide whether the service affects:
   - workforce identities
   - external identities
   - workload identities
   - app registrations / enterprise apps
   - Conditional Access / policy enforcement
   - licensing or bundle entitlement
3. Check the official Microsoft docs for that service family.
4. Distinguish:
   - “shares the same Entra tenant”
   - “uses the same sign-in plane”
   - “requires additional service licensing”
   - “has separate capacity / SKU / billing requirements”
5. Answer with explicit uncertainty if the tenant’s purchased licenses are unknown.

## High-value adjacent examples

### Microsoft 365

Use when the user asks whether a Microsoft 365 bundle covers Entra controls.

Typical checks:
- does the bundle include Entra ID P1?
- does it include Entra ID P2?
- does it merely include Entra Free?
- does it interact with Conditional Access or ID Protection?

### Microsoft Fabric / Power BI

Use when the user assumes tenant presence equals capacity rights or viewer rights.

Typical checks:
- capacity vs per-user licensing
- workspace type / SKU implications
- Entra tenant relationship versus Fabric usage rights

### Microsoft Intune

Use when Conditional Access and device state are being conflated.

Typical checks:
- whether device compliance assumptions depend on Intune licensing
- whether the user is asking about identity policy or device-management policy

### Microsoft Defender / Purview

Use when the user assumes Entra premium plans automatically include all risk and compliance integrations.

Typical checks:
- whether a specific signal comes from Defender
- whether the feature depends on a Defender or Purview add-on rather than plain Entra
- whether ID Protection quality depends on separately licensed Defender signals

### Microsoft Entra External ID

Use when B2B/B2C/guest or customer identity questions appear.

Typical checks:
- MAU-based or product-specific entitlements
- whether the question is workforce tenant access or customer identity

### Microsoft Entra Verified ID

Use when verifiable credentials or face-check style questions appear.

Typical checks:
- what is included in base Entra versus premium suite/add-on capabilities

### Microsoft Entra Workload ID

Use when service principals, app identities, GitHub Actions, or nonhuman access are involved.

Typical checks:
- workload identity premium features
- Conditional Access for workload identities
- ID Protection for workload identities

### Microsoft Entra Agent ID / AI agents

Use when the user is building or governing AI agents and assumes agent identities are just normal users or just normal service principals.

Typical checks:
- whether the question is about agent identities, agent users, or agent blueprints
- whether Conditional Access for Agent ID is preview-only or separately constrained
- whether agent risk depends on ID Protection for agents
- whether blueprint inheritance or custom security attributes change the authorization model
- whether the tenant is mixing agent governance questions with ordinary workload identity questions

## Safe response pattern

- “This service uses the same Entra tenant, but that does not by itself prove the needed feature rights.”
- “This looks like a cross-service licensing question, so I’m grounding it against the service’s official documentation before concluding.”
- “I can confirm the documented prerequisite, but I cannot confirm your tenant owns that license from the evidence provided.”

## Evidence refresh - 2026-06-04

- Agent identity guidance is now a first-class adjacent-service example: distinguish agent identities, agent users, sponsors, blueprints, Conditional Access for agents, ID Protection for agents, and Microsoft Agent 365 licensing before reusing ordinary human or workload identity conclusions.

# Microsoft Entra identity operations

## What people get wrong

- They disable security defaults before replacement Conditional Access coverage exists.
- They make broad Conditional Access exclusions for executives, service accounts, or break-glass without monitoring and compensating controls.
- They grant permanent privileged roles instead of using PIM and just-in-time activation.
- They ignore workload identities, app registrations, credentials, and delegated permissions while focusing only on human users.
- They treat report-only Conditional Access results as proof enforcement is safe for every token path.

## Officially grounded service shape

Microsoft Learn describes security defaults as a basic baseline requiring MFA registration, administrator MFA, protection for privileged Azure Resource Manager access, and blocking of legacy authentication and device code flow. For complex tenants, Conditional Access provides customizable policies. Microsoft guidance also emphasizes PIM for just-in-time privileged roles, MFA for administrators, emergency access accounts, least privilege, backup/recovery, and monitoring of identity governance changes.

## Non-negotiable design rules

1. Keep either security defaults or equivalent Conditional Access coverage active.
2. Require emergency access accounts and monitoring before risky policy changes.
3. Prefer PIM eligible assignments over permanent privileged roles.
4. Minimize exclusions and document owner, reason, expiration, and compensating controls.
5. Block or phase out legacy authentication and risky flows unless a documented exception exists.
6. Govern workload identities with owners, least privilege, credential lifecycle, and reviews.
7. Treat identity configuration changes as high blast-radius mutations.

## Minimal safe implementation flow

1. Identify licensing and whether security defaults or Conditional Access is the active baseline.
2. Inventory MFA, legacy auth, device code flow, admin access, and emergency access posture.
3. Review Conditional Access assignments, targets, conditions, grants, sessions, exclusions, and report-only data.
4. Review privileged roles, PIM settings, activation requirements, alerts, and access reviews.
5. Review app registrations and workload identities for owners, credentials, grants, and lifecycle.
6. Stage changes with pilot scope, report-only, break-glass verification, and rollback.
7. Enforce only after monitoring and support readiness are proven.

## High-risk assumptions to kill

- Disabling security defaults is unsafe unless equivalent Conditional Access coverage, emergency access, monitoring, and support readiness already exist.
- Report-only Conditional Access is impact evidence, not enforcement proof; token paths, exclusions, app dependencies, and break-glass flows still need testing.
- Broad block policies can lock out admins, especially when combined with all-resources scope and weak exclusion planning.
- Workload identities are not covered by user-scoped Conditional Access; service principals, managed identities, and federated credentials need separate review.
- A control may require specific Entra licensing or service entitlement; do not imply availability from documentation alone.

## Safe command/code verification targets

- Inspect policy-as-code or exported Conditional Access JSON for users/workload identities, target resources, conditions, grants, session controls, state, exclusions, and report-only posture.
- Review role assignments and PIM configuration for permanent privileged roles, activation duration, MFA, approval, notifications, and access reviews.
- Check app registrations and service principals for owners, credential type, credential age, federated credentials, API permissions, consent grants, and sign-in/risk logs.
- Verify emergency access accounts are excluded appropriately, monitored, tested, and not used for routine administration.
- Confirm final evidence distinguishes documented Microsoft Learn behavior from sampled tenant evidence and unverified licensing assumptions.

## Safe verification targets

- Security defaults state or equivalent Conditional Access baseline.
- MFA registration and enforcement for users and privileged roles.
- Legacy authentication and device code flow handling.
- Emergency access account count, configuration, and alerting.
- PIM role eligibility, activation duration, approval, MFA, and notifications.
- Workload identity owners, credentials, permissions, and risk signals.

## When to push back

Push back on disabling defaults, enforcing broad Conditional Access without emergency access, permanent Global Administrator assignments, unowned app registrations, blanket exclusions, or identity recommendations based only on screenshots or assumptions.

# Licensing and service entitlements

Use this reference only when the answer depends on whether the tenant is actually entitled to a Microsoft feature.

## Rule

Do not treat feature existence as proof of tenant entitlement.

When the user asks whether a control **can** be used, whether it is **included**, or whether one Microsoft product **covers** another, separate:

1. **technical capability**
2. **licensing prerequisite**
3. **service-specific entitlement**

If licensing is unknown, say so explicitly.

## High-value examples

### Example 1: Microsoft Azure / Entra baseline

- Microsoft Entra ID **Free** is included with Microsoft cloud subscriptions such as **Microsoft Azure** and **Microsoft 365**.
- That does **not** mean P1, P2, Identity Governance, or ID Protection are included.

Use this when the user assumes “we have Azure, so we have the Entra premium features.”

### Example 2: Conditional Access

- Microsoft documents **Conditional Access** as requiring **Microsoft Entra ID P1**.
- Microsoft also documents that **Microsoft 365 Business Premium** customers can use Conditional Access features.
- Risk-based policies require **Microsoft Entra ID Protection**, which is a **P2** feature.

Use this when the user assumes all Conditional Access features are equivalent.

### Example 3: PIM and identity governance

- Microsoft documents **Privileged Identity Management (PIM)** as a **P2 / Identity Governance / Entra Suite** capability.
- Identity Governance capabilities may have more specific licensing requirements than base Entra plans, including scenarios where “who can request” or “who is reviewed” affects licensing scope.

Use this when the user assumes PIM is included because they already have P1.

### Example 4: Workload identities

- Microsoft documents **Microsoft Entra Workload ID** separately.
- Some workload identity protections, such as risk reporting and Conditional Access for workload identities, have their own premium licensing constraints.

Use this when the user assumes service principals inherit all user-based Entra licensing rights.

### Example 5: Microsoft 365 bundle examples

- Microsoft documents **Entra ID P1** as included in **Microsoft 365 E3**, **F1**, **F3**, and **Business Premium**.
- Microsoft documents **Entra ID P2** as included in **Microsoft 365 E5** and certain defender/purview suites.

Use this when the user asks whether a Microsoft 365 bundle is enough for Entra controls.

### Example 6: Microsoft Fabric examples

- Microsoft Fabric runs in a **Microsoft Entra tenant**.
- Fabric collaboration depends on both **capacity** and **per-user licensing** in documented scenarios.
- Fabric examples are useful when the user assumes “tenant presence” equals “feature entitlement” across services.

Use this when the user is mixing Entra tenant identity, Power BI/Fabric capacities, and user-license assumptions.

### Example 7: External ID

- Microsoft documents **External ID** with its own service and pricing shape.
- External identity entitlement should not be inferred from workforce Entra premium licensing alone.

Use this when the user mixes workforce identity controls with customer or guest identity assumptions.

### Example 8: Verified ID and Entra Suite extras

- Microsoft documents that some Entra family capabilities sit in the broader **Entra Suite** or have premium add-on distinctions.
- Do not assume “it is part of Entra” means it is covered by the tenant’s current Entra ID plan.

Use this when the user assumes every Entra-branded capability is included with P1 or P2.

### Example 9: Intune-backed Conditional Access is not just "Entra"

- Microsoft documents that Conditional Access policies requiring compliant devices depend on **Intune compliance posture** and can fail if no compliance policy exists.
- A tenant can have Conditional Access rights without having the device-management setup or licensing needed for the device-compliance control to work as intended.

Use this when the user assumes device-compliance-based access control is purely an Entra switch.

### Example 10: ID Protection can depend on separate Defender signals

- Microsoft documents that some Microsoft Entra ID Protection detections rely on **Microsoft Defender** products and their licensing.
- Do not assume all risk detections are available just because the tenant has Entra ID P2.

Use this when the user assumes Entra P2 alone guarantees every risk signal or automated protection path.

### Example 11: Agent ID and AI agent controls have their own prerequisites

- Microsoft documents **Conditional Access for Agent ID (Preview)** and related agent-governance features separately from ordinary user and workload identity controls.
- Do not assume AI agents inherit the same control surface, object model, or licensing behavior as human users.

Use this when the user is designing AI agents and assumes ordinary Entra patterns automatically cover agent identities.

## Minimum licensing-check workflow

1. Identify the exact feature the user cares about.
2. Identify whether the question is about:
   - Entra tenant capability
   - Microsoft 365 bundle inclusion
   - Azure subscription baseline
   - Fabric capacity / per-user access model
   - Intune-backed device compliance dependency
   - Defender or Purview signal dependency
   - workload identity premium features
   - agent identity preview or AI-governance capability
   - external identity entitlement
   - Entra Suite or service-specific premium add-ons
3. Check official licensing docs.
4. State one of:
   - **confirmed licensed prerequisite from docs**
   - **confirmed not included from docs**
   - **licensing unknown from provided evidence**
5. Avoid “you can just use X” unless the prerequisite is proven.

## Safe phrasing examples

- “Documentation says this feature requires Entra ID P1, but I do not know whether your tenant has that license.”
- “Business Premium includes Conditional Access, but risk-based Conditional Access depends on P2-backed ID Protection.”
- “Fabric uses the same Entra tenant, but user rights and capacity rights are separate from Entra feature entitlements.”

## Evidence refresh - 2026-06-04

- Microsoft Learn documents separate prerequisites for agent security features: Conditional Access for agents requires Entra ID P1, ID Protection for agents requires Entra ID P2, ID Governance for agents requires Entra ID P1, and network controls for agents require Global Secure Access licensing. Treat these as documented prerequisites, not proof of tenant entitlement.

# MCP and evidence path for Microsoft Entra identity operations

Use Microsoft Learn documentation through the user's configured documentation MCP as the first grounding path for Azure service behavior. This file defines evidence boundaries; it must not imply that documentation proves the user's tenant, subscriptions, RBAC, quotas, billing agreement, deployed resources, or production readiness.

## Evidence ladder

1. `docs_only`: Microsoft Learn documentation and official architecture guidance. Use for documented behavior, caveats, and safe review criteria.
2. `sampled_read_only`: configured-environment evidence from read-only tools, if available and explicitly scoped. Use only for the sampled resource/time window.
3. `user_supplied`: sanitized outputs, IaC, diagrams, billing summaries, or metrics provided by the user. Treat as unverified unless independently checked.
4. `mutation_ready`: documentation plus current-state evidence plus explicit approval, blast-radius statement, and rollback path.

## Rules

- Do not expose environment-specific implementation details in committed docs or user-facing guidance.
- Do not ask for credentials, tokens, tenant identifiers, subscription identifiers, billing account identifiers, connection strings, private keys, customer data, or raw secrets.
- If current-state evidence was not sampled, say `not sampled`; do not imply it.
- If evidence is representative or partial, say so. A sample does not prove broad regional availability, billing accuracy, policy compliance, or production readiness.
- Prefer read-only evidence before mutation planning. Stop for approval before write operations.

## Final-answer evidence language

Use phrases like:

- "Based on Microsoft Learn documentation..."
- "Configured-environment evidence was not sampled in this review."
- "The following is an inference from the provided configuration, not proven live state."
- "This recommendation is mutation-ready only after explicit approval and rollback review."

# Official sources for Azure Entra ID Specialist

Use Microsoft Learn documentation through the user's configured documentation MCP before identity guidance. Documentation proves Microsoft-published behavior; it does not prove the user's tenant posture, licenses, policy state, exclusions, sign-in risk, or break-glass readiness.

## Primary Microsoft Learn sources

| Source | Review implication |
| --- | --- |
| [Security defaults in Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/fundamentals/security-defaults) | Use for MFA registration, administrator MFA, legacy auth blocking, device code flow blocking, and Conditional Access migration caveats. |
| [Build a Conditional Access policy](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-policies) | Use for assignments, target resources, network, conditions, grant/session controls, and token-evaluation caveats. |
| [Common Conditional Access policies](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-policy-common) | Use for secure-foundation templates and baseline policy strategy. |
| [Best practices for Microsoft Entra roles](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/best-practices) | Ground least privilege, PIM, admin MFA, and privileged-role hygiene. |
| [Privileged Identity Management](https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure) | Use for eligible roles, just-in-time activation, approval, alerts, and role settings. |
| [Best practices for securely deploying Microsoft Entra ID Governance](https://learn.microsoft.com/en-us/entra/id-governance/best-practices-secure-id-governance) | Use for least privilege, backup/recovery, monitoring, access reviews, and governance operations. |
| [Workload identities overview](https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-overview) | Use for app/service principal/workload identity review. |
| [Emergency access accounts](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access) | Use for break-glass account design and monitoring. |

## Source-grounding rules

- Do not disable security defaults unless replacement Conditional Access coverage is ready.
- Do not recommend broad exclusions; require explicit named rationale and compensating controls.
- Do not approve privileged-role changes without PIM, MFA, alerting, and emergency access review.
- Treat tenant evidence as sensitive; request only sanitized summaries.

## Current Microsoft Learn deltas checked on 2026-06-05

- Conditional Access planning depends on Microsoft Entra licensing; risk-based policies require stronger entitlement evidence than baseline policy design.
- Emergency access accounts and service principals/service accounts require explicit exclusion or separate control design; do not assume user-scoped Conditional Access safely governs every identity type.
- Conditional Access for workload identities is scoped to single-tenant service principals in the tenant; do not claim managed identities or multi-tenant SaaS apps are covered without current documentation evidence.
- Microsoft Entra roles and Azure RBAC roles are separate control planes; never use one evidence set to prove the other.

# Safety checklist for Azure Entra ID Specialist

## Non-negotiable gates

- Never ask for tenant identifiers, user lists, object identifiers, tokens, app secrets, certificates, private keys, sign-in logs with personal data, or raw audit exports.
- Do not recommend disabling security defaults without replacement Conditional Access policies ready to protect the tenant.
- Do not recommend broad Conditional Access exclusions, blanket MFA bypass, or privileged role permanency without explicit risk acceptance.
- Require emergency access account design before high-risk Conditional Access or role changes.
- Require explicit approval before policy enablement, report-only to enforce changes, exclusions, role assignments, app credential changes, or workload identity changes.

## High-risk assumptions to kill

- "MFA exists, so identity is safe." Legacy auth, exclusions, stale sessions, app permissions, and privileged roles still matter.
- "Report-only policy success means enforce safely." Token timing, excluded paths, break-glass, and app compatibility need checks.
- "Global Administrator is convenient." It should be rare, monitored, and preferably just-in-time.
- "Security defaults plus custom needs is enough." Complex tenants generally need Conditional Access.
- "Service principals are harmless." Workload identities can carry high-impact permissions and secrets.

## Evidence labels

- `docs_only`: Microsoft Learn guidance only.
- `tenant_sample`: sanitized read-only tenant posture evidence was reviewed.
- `policy_review`: Conditional Access, PIM, or app registration config was reviewed, not proven live.
- `change_ready`: emergency access, rollback, approval, and monitoring are documented.

## Minimum safe evidence

- Licensing capability: security defaults vs Conditional Access/PIM/Identity Protection availability.
- MFA posture, legacy authentication status, security defaults or Conditional Access baseline.
- Emergency access accounts, monitoring, and exclusion strategy.
- Privileged roles: active vs eligible, activation controls, alerts, and reviews.
- Workload identities, app credentials, owner hygiene, and permission grants.

# Workflow and output contract for Azure Entra ID Specialist

## Minimal safe workflow

1. Classify request: security baseline, Conditional Access, MFA, PIM, app registration, workload identity, governance, or mutation approval.
2. Ground the review in Microsoft Learn through the user's configured documentation MCP.
3. Determine evidence level: docs only, sanitized tenant sample, policy review, or change-ready package.
4. Review baseline: security defaults or Conditional Access, MFA, legacy auth, device code flow, emergency access, and admin separation.
5. Review privilege: roles, PIM, eligibility, activation requirements, alerts, access reviews, and break-glass monitoring.
6. Review workload identities: owners, credentials, permissions, risk, and lifecycle.
7. Return verdict, blockers, and safe staged next actions.

## Output contract

```markdown
## Verdict
<secure enough | conditional | high-risk | docs-only advisory>

## Evidence level
- Documentation: <sources used>
- Tenant/config evidence: sanitized tenant sample, policy review, or not sampled

## Findings
1. <finding> — Evidence: <docs_only|tenant_sample|policy_review|inference>

## Change risk
- Blast radius: <summary>
- Rollback: <summary or blocker>

## Blockers
- Identity blocker: describe the missing proof without exposing tenant or principal identifiers

## Safe next actions
- <least-risk action>
```

## Pushback triggers

Push back on disabling protections, broad exclusions, permanent privileged access, app secrets with no rotation, Conditional Access enforcement without emergency access, or identity claims without tenant evidence.