# Identity to Data Access Protocol — Workflow and Output Contract

## Detailed Workflow

### Phase 1: Identity Verification

**Trigger events**
- Joiner event: new employee or guest requires access provisioning
- Mover event: role change requires access modification
- Leaver event: departure requires access de-provisioning
- Ad-hoc access request: user requests a resource, application, or role
- PIM activation request: user requests a privileged role activation
- Periodic access review: scheduled review of a group, application, or role

**Step 1.1 — Identity claim intake**
Collect the identity claim:
- UPN and identity type (employee, guest, service principal, managed identity)
- Lifecycle event type
- Requested resource, application, or role with business justification
- Requestor's manager or sponsor (for guest access)

**Step 1.2 — Authentication strength check**
Verify MFA registration and device compliance status:
- If MFA is not registered: block and direct the user to MFA registration.
- If device is non-compliant: block and direct the user to device remediation.
- If authentication strength meets Conditional Access requirements: proceed.

---

### Phase 2: Conditional Access Evaluation

**Step 2.1 — Policy mapping**
Map the requested access to applicable Conditional Access policies in the
Microsoft Entra tenant. Identify:
- Which policies apply to this user, resource, and sign-in context
- Whether any policy requires additional controls (MFA, compliant device,
  location restriction, session lifetime)
- Whether any policy exception or exclusion list applies

**Step 2.2 — Gap identification**
If the requested access is not covered by any Conditional Access policy,
flag as a governance gap. Do not recommend access to an unprotected resource
without flagging the gap to the identity owner.

---

### Phase 3: Least-Privilege Check

**Step 3.1 — Existing assignment enumeration**
Enumerate the identity's current:
- Direct role assignments in Microsoft Entra ID
- Group memberships (and inherited role assignments)
- Entitlement management access package assignments
- Application role assignments

**Step 3.2 — Over-privilege identification**
Compare existing assignments against the stated business purpose. Flag:
- Roles or permissions not required for the stated purpose
- Standing assignments to privileged roles that should be JIT
- Group memberships that grant broader access than needed
- Inactive assignments (not used in the defined inactive threshold)

**Step 3.3 — Recommended scope**
Produce a recommended scope: the minimum permissions required for the stated
business purpose, for the minimum duration required.

---

### Phase 4: Gate 1 — Access Review Sign-off

**Step 4.1 — Review currency check**
For the target resource or role, check whether an access review is configured
and whether the identity has been attested in the current review cycle.

- If review is current and identity is attested: proceed.
- If review is overdue: block the access recommendation; flag to the review
  owner. Do not recommend access to a resource with an overdue review.
- If no review is configured for a resource that should have one: flag as a
  governance gap to the identity owner.

---

### Phase 5: Data Governance Layer

**Step 5.1 — Data sensitivity assessment**
Invoke m365-copilot-readiness-governance-agent to assess:
- Whether the target resource contains sensitive content (per sensitivity labels
  or Microsoft Purview DSPM signals)
- Whether the resource is over-shared and the requested identity would receive
  broader effective access than intended
- Whether sensitivity labels are applied to the content in scope

**Step 5.2 — Data governance gate**
If the target resource contains unlabelled or over-shared sensitive content:
- Hold the access recommendation.
- Route the finding to the data owner and m365-copilot-readiness-governance-agent.
- Do not recommend access until the data owner confirms the content is
  appropriately governed or accepts the residual risk.

---

### Phase 6: Entitlement Management

**Step 6.1 — Access package check**
If access is via a Microsoft Entra entitlement management access package:
- Confirm the package policy is satisfied: approval workflow, expiry, and SoD.
- Confirm the requestor is eligible for the package.
- Confirm the package has not expired or been revoked.

**Step 6.2 — Separation of duties**
Check whether granting the requested access would create a SoD conflict with
existing assignments. If yes: block the recommendation and escalate to the
identity owner and security team.

---

### Phase 7: PIM Gate (Privileged Roles Only)

**Step 7.1 — Privileged role detection**
If the requested access includes a privileged role (Global Administrator,
Privileged Role Administrator, Security Administrator, Exchange Administrator,
or any role with equivalent blast radius):
- Confirm that PIM is configured for just-in-time activation.
- Confirm that the requestor has an active, documented business justification.
- Confirm the activation window is bounded (not permanent).

**Step 7.2 — PIM activation assessment**
If standing permanent assignment is requested:
- Block the recommendation unconditionally for Global Administrator equivalent.
- Flag all other standing privileged assignments for PIM migration.

---

### Phase 8: Gate 2 — Least-Privilege Validation

Produce the least-privilege attestation:
- Recommended access: resource/role, scope, duration
- Evidence: Conditional Access policy satisfied, MFA confirmed, device
  compliant, no SoD conflict, data governance confirmed
- Residual risk: any acknowledged gaps accepted by the identity owner
- Open questions: anything not yet confirmed

---

### Phase 9: Recommendation and Human Confirmation

Produce the access recommendation (approve / deny / reduce-scope) with full
evidence basis. Route to the identity owner or security team for human
confirmation. This protocol never approves or denies access autonomously.

---

## Decision Tree

```
Identity claim received
  └── MFA registered + device compliant?
        ├── No  → Block; direct to remediation
        └── Yes → Map to Conditional Access policies
                    └── Policy gap identified?
                          ├── Yes → Flag governance gap to identity owner; hold
                          └── No  → Check existing assignments for over-privilege
                                      └── SoD conflict?
                                            ├── Yes → Block; escalate to security owner
                                            └── No  → Access review current?
                                                          ├── No  → Block; notify review owner
                                                          └── Yes → Data governance check
                                                                        └── Unlabelled/over-shared sensitive content?
                                                                              ├── Yes → Hold; route to data owner
                                                                              └── No  → Privileged role?
                                                                                            ├── Yes → PIM JIT confirmed?
                                                                                            │          ├── No  → Block; require PIM migration
                                                                                            │          └── Yes → Least-privilege attestation
                                                                                            └── No  → Least-privilege attestation
                                                                                                          └── Human confirmation required
```

---

## Output Contract

### Access recommendation record
| Field | Type | Description |
|---|---|---|
| identity_id | string (anonymised) | Internal identity reference (not UPN in transit) |
| skill_id | string | `identity-to-data-access-protocol` |
| skill_version | string | `0.1.0` |
| invoked_by | string | Agent or human who invoked this protocol |
| lifecycle_event | enum | joiner / mover / leaver / ad-hoc / pim-activation / access-review |
| access_scope | string | Resource or role requested |
| recommendation | enum | approve / deny / reduce-scope / hold-pending-data-governance |
| conditional_access_status | enum | satisfied / gap-identified / exception-applied |
| least_privilege_attestation | boolean | Whether least-privilege validation passed |
| access_review_status | enum | current / overdue / not-configured |
| pim_required | boolean | Whether PIM JIT is required for this access |
| sod_conflict | boolean | Whether a SoD conflict was detected |
| data_governance_status | enum | confirmed / hold / risk-accepted-by-owner |
| evidence_quality | enum | high / medium / low |
| open_questions | array | Unresolved questions at handoff |
| do_not_do_list | array | Actions explicitly excluded from this protocol's scope |
| timestamp | ISO 8601 | Protocol execution timestamp |

### Gate verdicts
| Gate | Verdict options |
|---|---|
| Access review sign-off | current / overdue / not-configured |
| Least-privilege validation | pass / fail-over-privilege / fail-sod |

### Refusal record (when triggered)
| Field | Description |
|---|---|
| refusal_reason | Which refusal trigger was hit |
| escalation_target | Identity owner / security team / data owner |
| timestamp | ISO 8601 |

---

## Quality Assurance Notes
- This protocol never approves, denies, or executes access changes. All
  recommendations require human identity or security owner sign-off.
- PIM standing-assignment blocks for Global Administrator equivalent are
  unconditional and cannot be overridden by this protocol.
- Data governance sub-reports from m365-copilot-readiness-governance-agent
  are always preserved as attachments to the access recommendation record.