@raishin/vanguard-frontier-agentic 2.9.0 → 2.11.0

package/skills/cross-functional/identity-to-data-access-protocol/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: identity-to-data-access-protocol
+description: Use this skill when an identity lifecycle event (joiner, mover, leaver) or an access request must be evaluated end-to-end across Microsoft Entra identity, Conditional Access policy, and data access governance under a Zero Trust posture. Orchestrates m365-identity-zero-trust-agent as primary and m365-copilot-readiness-governance-agent for data-layer governance. Gates include access review sign-off and least-privilege validation before any access grant is recommended. Does not approve access; all recommendations require human owner confirmation. Never requests credentials, tenant IDs, or customer data.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-16"
+  category: security
+  lifecycle: experimental
+---
+
+# Identity to Data Access Protocol
+
+## Purpose
+This skill defines how an identity claim — a new hire, a role change, an
+external partner request, or a privileged-role activation — is evaluated
+against Conditional Access policy and data access governance rules before any
+access recommendation is produced. It enforces Zero Trust principles (verify
+explicitly, use least privilege, assume breach) across the full access
+lifecycle. It does not approve access; it produces a structured recommendation
+that a human identity or security owner confirms.
+
+## When to use
+- A joiner, mover, or leaver event requires access provisioning or de-provisioning.
+- An access request must be assessed against Conditional Access policy and
+  least-privilege rules before approval.
+- A periodic access review is due for a group, application, or privileged role.
+- A Privileged Identity Management (PIM) activation request needs risk context
+  before the approver decides.
+- Data access governance must be validated before sensitive content is exposed.
+
+## When NOT to use
+- The access decision is already made and you only need to execute provisioning
+  — use your provisioning runbook, not this protocol.
+- The matter is a security incident requiring incident response — route to your
+  incident response protocol.
+- The identity in question belongs to a non-Microsoft Entra directory — this
+  protocol is scoped to Microsoft Entra ID and Microsoft 365.
+- You need live tenant configuration changes — escalate to the identity owner;
+  this protocol is recommendation-only.
+
+## Participating agents
+- `m365-identity-zero-trust-agent` (primary — Entra identity, Conditional Access, PIM)
+- `m365-copilot-readiness-governance-agent` (secondary — data access governance, sensitivity label compliance)
+
+## Inputs required
+- Identity claim: UPN, identity type (employee, guest, service principal), lifecycle event
+- Requested resource or role with business justification
+- Applicable Conditional Access policies in scope
+- Current group memberships, role assignments, and entitlement packages
+- Data classification of the target resource (if data access is in scope)
+
+## Evidence required
+- Microsoft Entra tenant has Conditional Access policies configured
+- Entitlement management access packages are defined for the relevant resource
+- PIM is configured for any privileged roles in scope
+- Access review schedule is active for the affected group or application
+- Data classification labels (Microsoft Purview) are applied to target resources
+
+## Workflow
+
+1. **Identity verification** — Confirm identity type, lifecycle event, and
+   authentication strength. Verify MFA registration and device compliance
+   before proceeding.
+2. **Conditional Access evaluation** — Map the requested access to applicable
+   Conditional Access policies. Identify any policy gaps or exceptions.
+3. **Least-privilege check** — Enumerate existing assignments. Identify
+   over-privileged roles or group memberships. Flag any permissions not
+   required for the stated business purpose.
+4. **Gate 1 — Access review sign-off** — If the target resource or role is
+   subject to an active access review, confirm the review is current and the
+   identity has been attested. Do not recommend access if attestation is
+   overdue.
+5. **Data governance layer** — Invoke m365-copilot-readiness-governance-agent
+   to assess data sensitivity and confirm that the identity's access scope
+   does not expose over-shared or unlabelled sensitive content.
+6. **Entitlement management** — If access is via an entitlement management
+   package, confirm the package policy (approval workflow, expiry, separation
+   of duties) is satisfied.
+7. **PIM gate (privileged roles only)** — For any privileged role, confirm
+   just-in-time activation is in use, the justification is documented, and the
+   activation window is bounded.
+8. **Gate 2 — Least-privilege validation** — Produce a least-privilege
+   attestation: the recommended access grants only the permissions required,
+   for only the duration required, with no standing privileged access.
+9. **Recommendation** — Produce a structured access recommendation: approve,
+   deny, or reduce-scope. Include the evidence basis, open questions, and
+   do_not_do_list.
+10. **Human confirmation** — Route to the identity owner or security team for
+    final approval. This protocol never approves access autonomously.
+
+## Decision gates
+
+| Gate | Condition | Action |
+|---|---|---|
+| Access review | Review overdue or attestation not current | Block recommendation; flag for review owner |
+| Least-privilege | Requested permissions exceed business justification | Recommend reduced scope; escalate to identity owner |
+| MFA / device | MFA not registered or device non-compliant | Block recommendation; direct user to remediation |
+| Data sensitivity | Target resource contains unlabelled or over-shared sensitive data | Invoke m365-copilot-readiness-governance-agent; hold access recommendation |
+| PIM activation | Privileged role requested without JIT justification | Require JIT activation and documented justification |
+
+## Refusal triggers
+- Stop if the identity cannot be authenticated to the required assurance level
+  — do not produce an access recommendation on an unverified identity.
+- Stop if credentials, session tokens, tenant IDs, or customer PII are
+  requested — refuse and escalate to the security team.
+- Stop if the access request would grant standing Global Administrator or
+  equivalent permissions without PIM — this is unconditionally blocked.
+- Stop if separation of duties would be violated — escalate to the security owner.
+
+## Handoff rules
+- All handoffs carry: identity_id (anonymised), skill_id, skill_version,
+  invoked_by, access_scope, evidence_quality, open_questions, do_not_do_list.
+- Human escalations always include the least-privilege gap statement and the
+  specific Conditional Access policy in scope.
+- Data governance findings from m365-copilot-readiness-governance-agent are
+  attached as a sub-report; they are never discarded.
+
+## KPIs
+- Access review completion rate (% on schedule)
+- Least-privilege attestation pass rate
+- Mean time to access decision (request to human confirmation)
+- PIM just-in-time activation rate for privileged roles
+- Over-privilege remediation rate (flagged vs. resolved)
+
+## References
+- https://learn.microsoft.com/entra/id-governance/scenarios/least-privileged
+- https://learn.microsoft.com/entra/id-governance/access-reviews-overview
+- https://learn.microsoft.com/entra/id-governance/deploy-access-reviews
+- https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-configure
+- https://learn.microsoft.com/security/zero-trust/

package/skills/cross-functional/identity-to-data-access-protocol/metadata.json

@@ -0,0 +1,21 @@
+{
+  "id": "identity-to-data-access-protocol",
+  "name": "Identity to Data Access Protocol",
+  "type": "skill",
+  "provider": "generic",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Zero Trust identity lifecycle protocol spanning Microsoft Entra ID, Conditional Access policy, and data access governance. Covers joiner/mover/leaver events, access request evaluation, least-privilege validation, PIM just-in-time activation, and periodic access review sign-off before any access recommendation is produced. Access decisions are recommendations only and always require human identity or security owner confirmation; this protocol never approves access autonomously.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/entra/id-governance/scenarios/least-privileged",
+    "https://learn.microsoft.com/entra/id-governance/access-reviews-overview",
+    "https://learn.microsoft.com/entra/id-governance/deploy-access-reviews",
+    "https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-configure",
+    "https://learn.microsoft.com/security/zero-trust/"
+  ],
+  "security_notes": "This protocol is a recommendation and orchestration aid only; it is never an authorisation to grant, deny, or modify access. It never requests credentials, session tokens, tenant IDs, or customer PII to evaluate an identity or access request. Standing Global Administrator or equivalent assignments without PIM are unconditionally blocked as a recommendation — escalate to the identity owner. Separation-of-duties violations block any access recommendation and escalate to the security owner. All access recommendations require human identity or security owner sign-off before any provisioning action. Data governance findings from the data-layer agent are always preserved and never discarded. Production identity or Conditional Access configuration changes escalate to the relevant identity admin.",
+  "last_verified": "2026-06-16",
+  "path": "skills/cross-functional/identity-to-data-access-protocol",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/cross-functional/identity-to-data-access-protocol/references/workflow-and-output.md

@@ -0,0 +1,224 @@
+# 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.

package/skills/cross-functional/incident-to-remediation-protocol/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: incident-to-remediation-protocol
+description: Use this skill when a security incident must be triaged, contained, remediated, and reviewed in a Zero Trust assume-breach posture across Microsoft 365 and Dynamics 365 environments. Defines the end-to-end flow from detection through severity triage, containment approval, investigation, remediation, and post-incident review. Applies Zero Trust principles — verify explicitly, use least privilege, assume breach — throughout. Does not serve as an authorization to isolate devices, block users, or make configuration changes; all containment and remediation actions require human approval from the security owner or incident commander. Does not replace a qualified SecOps team or Microsoft Defender XDR specialist.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-16"
+  category: security
+  lifecycle: experimental
+---
+
+# Incident-to-Remediation Protocol
+
+## Purpose
+This skill defines how a security incident detected across Microsoft 365 or Dynamics 365 is triaged, classified by severity, contained, investigated, remediated, and reviewed in a Zero Trust posture. It applies the assume-breach principle throughout: the scope of compromise is always assumed to be larger than initial signals suggest until evidence proves otherwise. It does not authorize containment or remediation actions; those require the incident commander or security owner. It does not replace a qualified SecOps team or Microsoft Defender XDR escalation.
+
+## When to use
+- A security incident has been detected in the Microsoft Defender portal (Microsoft Defender XDR) or reported through another channel.
+- An identity compromise, device compromise, data exfiltration signal, or malicious configuration change is suspected in Microsoft 365 or Dynamics 365.
+- A SecOps team needs a structured workflow for triage, containment approval, investigation, and post-incident review.
+- A cross-workload incident spans Microsoft Defender for Identity, Microsoft Defender for Endpoint, Microsoft Defender for Office 365, and Dataverse environments simultaneously.
+
+## When NOT to use
+- The incident has already been triaged and is in active SecOps investigation — hand off to the active investigation owner.
+- The matter is a vulnerability disclosure rather than an active incident — use the security review path, not this protocol.
+- The incident involves a data breach with regulatory notification obligations — escalate to the privacy owner and legal counsel immediately; this protocol does not cover breach notification timelines.
+- The matter is outside Microsoft 365 or Dynamics 365 scope — route to the appropriate security team.
+
+## Participating agents
+- `m365-identity-zero-trust-agent` — primary: assesses identity signals, Conditional Access coverage, Entra ID risk events, and Zero Trust posture gaps
+- `copilot-governance-maestro-agent` — secondary: assesses Copilot and AI surface area exposure; coordinates cross-workload governance review
+- `microsoft-maestro-agent` — orchestrates cross-workload incident scope; escalation path to Microsoft Defender XDR SecOps specialists (planned: defender-xdr-secops-agent)
+
+## Inputs required
+- Incident ID or alert reference from Microsoft Defender portal
+- Affected entities (users, devices, mailboxes, apps, Dataverse environments)
+- Initial detection source (Microsoft Defender for Identity, Defender for Endpoint, Defender for Office 365, Defender for Cloud Apps, manual report)
+- Reported or suspected incident type (phishing, credential compromise, ransomware, insider threat, misconfiguration exploitation, data exfiltration)
+- Current containment status (not started, in progress, complete)
+
+## Evidence required
+- Incident details from Microsoft Defender XDR portal (alerts, affected entities, attack story)
+- Microsoft Entra ID sign-in logs and risk events for affected identities
+- Audit logs from Microsoft Purview for affected workloads
+- Threat analytics data (if available) from Microsoft Defender portal
+- Prior incident or related-alert history
+
+## Workflow
+
+1. **Detect and ingest** — receive incident signal; record incident ID, detection source, affected entities, and initial classification.
+2. **Severity triage** — classify incident severity using Microsoft Defender XDR severity (Informational, Low, Medium, High, Critical) and assess blast radius (number of affected entities, data sensitivity, production impact).
+3. **Assume breach** — apply Zero Trust assume-breach posture: treat the scope of compromise as larger than confirmed until evidence narrows it; do not wait for full confirmation before containment planning.
+4. **Containment planning** — identify containment actions appropriate to severity and affected entities (disable compromised users, isolate affected devices, block hostile IPs or domains, revoke sessions); do not execute containment without approval.
+5. **Escalation gate: severity triage** — if severity is High or Critical, escalate immediately to incident commander and microsoft-maestro-agent for Defender XDR SecOps coordination; do not proceed to containment without incident commander acknowledgment.
+6. **Escalation gate: containment approval** — require explicit human approval from the incident commander or security owner before executing any containment action; record approval reference.
+7. **Execute approved containment** — execute containment actions per the approval; record each action with timestamp, actor, and affected entity.
+8. **Investigation** — analyze the attack story, affected entities, and alert timeline; identify root cause, initial access vector, lateral movement paths, and data accessed or exfiltrated.
+9. **Remediation planning** — identify remediation actions (credential reset, device re-imaging, configuration correction, policy strengthening); confirm remediation actions are least-privilege and reversible where possible.
+10. **Remediation execution** — execute approved remediation actions; verify each remediation step with evidence of completion.
+11. **Post-incident review** — conduct a structured post-incident review: what was the attack type and impact, what detection and response gaps existed, what configuration or policy changes are needed, and what playbook updates are required.
+12. **Resolve incident** — mark incident resolved in Microsoft Defender portal once all containment and remediation steps are confirmed; document resolution in audit log.
+
+## Decision gates
+
+| Gate | Condition | Action |
+|---|---|---|
+| Severity triage | Severity is High or Critical | Escalate immediately to incident commander + microsoft-maestro-agent; do not proceed without acknowledgment |
+| Containment approval | Any containment action is planned | Require explicit human approval before execution; record approval reference |
+| Breach scope uncertainty | Scope of compromise is not confirmed | Maintain assume-breach posture; treat scope as larger until evidence narrows it |
+| Post-incident review | Incident is resolved | Mandatory post-incident review before closing; update playbooks and policies as needed |
+
+## Refusal triggers
+- A request is made to execute containment (user disable, device isolation, IP block) without recorded human approval — refuse.
+- A request is made to close or resolve an incident without a completed post-incident review — refuse.
+- Credentials, session tokens, OAuth tokens, or personal data are requested to perform investigation — refuse; work from sanitized incident signals and audit log references only.
+- A data breach with regulatory notification obligations is suspected — stop and escalate to privacy owner and legal counsel; this protocol does not cover breach notification.
+
+## Handoff rules
+- Every handoff carries: incident ID, severity, affected entities, containment status, investigation summary, remediation status, escalations fired, open questions, and a do-not-do list.
+- No agent executes a containment or remediation action without recorded human approval.
+- Post-incident review findings are handed off to the security owner for policy and playbook updates.
+
+## KPIs
+- Mean time to detect (MTTD) and mean time to contain (MTTC) per severity tier
+- Percentage of incidents with completed post-incident reviews
+- Number of playbook or policy updates generated from post-incident reviews
+- Percentage of containment actions executed within approved scope (no overreach)
+
+## References
+- [Plan an incident response workflow in the Microsoft Defender portal](https://learn.microsoft.com/unified-secops/plan-incident-response)
+- [Investigate and respond using Microsoft Defender XDR](https://learn.microsoft.com/defender-xdr/pilot-deploy-investigate-respond)
+- [Incident response with XDR and integrated SIEM (Zero Trust)](https://learn.microsoft.com/security/zero-trust/siem-xdr-overview)
+- [Incident response playbooks](https://learn.microsoft.com/en-us/security/operations/incident-response-playbooks)

package/skills/cross-functional/incident-to-remediation-protocol/metadata.json

@@ -0,0 +1,20 @@
+{
+  "id": "incident-to-remediation-protocol",
+  "name": "Incident-to-Remediation Protocol",
+  "type": "skill",
+  "provider": "generic",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Defines the end-to-end security incident lifecycle across Microsoft 365 and Dynamics 365 environments — from detection and severity triage through containment approval, investigation, remediation, and mandatory post-incident review. Applies Zero Trust assume-breach posture throughout: scope of compromise is treated as larger than confirmed until evidence narrows it. Severity and containment gates enforce human approval before any isolate, disable, or block action. Escalation paths route to microsoft-maestro-agent for Defender XDR SecOps coordination.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/unified-secops/plan-incident-response",
+    "https://learn.microsoft.com/defender-xdr/pilot-deploy-investigate-respond",
+    "https://learn.microsoft.com/security/zero-trust/siem-xdr-overview",
+    "https://learn.microsoft.com/en-us/security/operations/incident-response-playbooks"
+  ],
+  "security_notes": "Protocol is recommendation and orchestration only — never an authorization for containment or remediation actions. All actions that isolate devices, disable users, block IPs or domains, or revoke sessions require explicit human approval from the incident commander or security owner before execution. Zero Trust assume-breach posture is mandatory throughout: scope of compromise is never minimized. Never requests credentials, session tokens, OAuth tokens, or personal data to perform investigation; works from sanitized incident signals and audit log references only. Data breach scenarios with regulatory notification obligations must be escalated to the privacy owner and legal counsel; this protocol does not govern breach notification timelines or obligations. Planned escalation target: defender-xdr-secops-agent (not yet built); current escalation routes to microsoft-maestro-agent.",
+  "last_verified": "2026-06-16",
+  "path": "skills/cross-functional/incident-to-remediation-protocol",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}