@raishin/vanguard-frontier-agentic 2.11.0 → 2.13.1

package/skills/sap/sap-security-hr-legal-protocol/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: sap-security-hr-legal-protocol
+description: Cross-functional escalation protocol governing handoffs between SAP Security, HR, and Legal when identity misuse, privileged-access anomalies, SoD violations, insider-risk signals, HR-sensitive system access, joiner/mover/leaver lifecycle events, or fraud-sensitive access patterns require coordinated response. Defines decision rights, evidence standards, redaction policy, approval gates, and audit packaging. Never mutates live systems and never bypasses any guarded-mutating gate.
+allowed-tools: Read Grep Glob WebSearch WebFetch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-19"
+  category: compliance
+  lifecycle: experimental
+---
+
+# SAP Security HR Legal Escalation Protocol
+
+## Purpose
+
+This skill defines the cross-functional coordination and handoff contract between SAP Security, Human Resources, and Legal when an identity or access event requires multi-domain response. It establishes which agents hold decision rights at each stage, what evidence must be collected and redacted before sharing across functions, which actions are irreversible and require explicit approval, and what the audit package must contain to satisfy internal audit, external regulators, and employment-law obligations.
+
+This is a governance coordination document. It does not mutate any SAP system, does not trigger any provisioning or deprovisioning action, does not close or approve any GRC access violation, and does not initiate any HR or Legal action. All mutations remain gated behind the relevant guarded-mutating operator agents. No guarded gate is bypassed.
+
+## When to use
+
+Invoke this protocol when any of the following trigger conditions apply:
+
+- **Identity misuse or suspected account compromise**: An active user account shows access patterns inconsistent with job function, time-of-access anomalies, bulk data extraction indicators, or repeated failed authentications from unexpected locations.
+- **Privileged-access anomalies**: A superuser, firefighter (EAM), basis administrator, or SAP\_ALL holder exhibits access outside an approved change window, accesses HR-sensitive or payroll-relevant transactions not included in the original firefighter scope, or fails to complete mandatory post-access log review.
+- **SoD violations with fraud-sensitive transaction pairs**: GRC Access Control raises a critical or high SoD conflict involving procure-to-pay, payroll disbursement, vendor master maintenance, financial period-close journals, or revenue recognition entries — and the conflict involves an active employee (not a system account).
+- **Insider-risk signals**: Security monitoring, DLP, or SIEM surfaces exfiltration indicators against HR data stores (SuccessFactors, HCM), payroll systems, financial master data, or confidential business planning data.
+- **HR-sensitive system access outside authorized scope**: Access to SuccessFactors Employee Central, compensation planning, performance ratings, succession data, or talent profiles by a user whose role does not include HR stewardship.
+- **Joiner/mover/leaver lifecycle gaps**: A leavers process was not completed on the effective date (system access remains active for a departed employee), a mover's previous access was not removed when a new role was granted, or a joiner received access that exceeds the approved role matrix.
+- **Fraud-sensitive access escalation**: Finance or audit identifies a pattern of journal entries, payment runs, or vendor changes executed by a single user without SoD separation, and the pattern warrants investigation that may touch HR employment records or legal hold obligations.
+
+## Participating agents
+
+The following agents operate within this protocol. Each holds a defined role and must not act outside its lane without explicit cross-function approval per the decision rights table.
+
+- `sap-security-iam-grc-sod-reviewer-agent` — Lead for identity and access evidence collection, SoD conflict classification, GRC finding triage, and access risk narrative. Does not modify role assignments or provisioning state.
+- `sap-successfactors-hr-process-risk-agent` — HR-domain specialist assessing SuccessFactors configuration, HR data access policy compliance, joiner/mover/leaver process integrity, and sensitivity classifications for HR data elements. Does not read or share unredacted HR data outside the HR function.
+- `sap-role-assignment-guarded-operator-agent` — The sole agent authorized to execute role assignment or removal actions in SAP systems. All role changes proposed by the protocol must be queued to this agent and require dual approval before execution. This agent is the only guarded-mutating gate in this protocol.
+
+## Required evidence
+
+Before any cross-function handoff is initiated, the following evidence must be assembled by the requesting function:
+
+1. **Identity evidence**: Username, employee ID (if known), system (ECC, S/4HANA, BTP subaccount, SuccessFactors tenant), and access log extract covering the relevant time window. Timestamps must be in UTC.
+2. **Access pattern evidence**: Transaction codes accessed, authorization objects exercised, GRC Access Control conflict report (if available), and EAM firefighter log (if the user held a firefighter ID).
+3. **Role assignment state**: Current role or role collection assignments, last provisioning event date, IPS provisioning job log (if applicable), and GRC user access review status.
+4. **HR lifecycle state**: Joiner date, most recent position change date, effective termination date (if leaver), and HR system-of-record confirmation of current employment status. This evidence is assembled by HR and shared in redacted form per the redaction policy below.
+5. **Business process context**: Which business process is affected (P2P, O2C, payroll, financial close, HR master data), whether the access event coincides with a period-end or approval window, and whether any compensating controls exist.
+
+## Redaction policy
+
+Personal HR data (compensation, performance ratings, disciplinary records, health-related information, succession planning data) must be redacted before evidence is shared outside the HR function. When HR evidence is required by Security or Legal:
+
+- HR provides a **redacted summary** confirming employment status, role, effective dates, and whether the lifecycle event (join/move/leave) was processed on time.
+- Full HR records are shared only with Legal under legal-hold or employment-law obligation, via a controlled document transfer that is logged in the audit package.
+- System access logs that contain HR transaction data are treated as HR-sensitive and are handled by the `sap-successfactors-hr-process-risk-agent`; Security receives a classified summary, not the raw log.
+- No unredacted HR data is included in GRC findings, change tickets, or incident reports visible to operational teams.
+
+## Decision rights
+
+| Decision | Primary authority | Secondary approval required | Notes |
+|---|---|---|---|
+| Classify access event as security incident | SAP Security (sap-security-iam-grc-sod-reviewer-agent) | None for classification | Classification does not trigger any system mutation |
+| Suspend or disable a user account | SAP Security + HR jointly | Legal notification if employment action may follow | Must route through sap-role-assignment-guarded-operator-agent; requires dual approval |
+| Remove role assignments | SAP Security proposes; HR confirms no operational dependency | sap-role-assignment-guarded-operator-agent executes only after dual approval | Irreversible-action gate applies; see below |
+| Place legal hold on access logs | Legal | HR acknowledgment | Triggers evidence preservation; no system mutation by this protocol |
+| Disclose access findings to employee | HR + Legal jointly | — | Security provides classified summary only; HR/Legal manage disclosure |
+| Close GRC access violation | GRC / audit team | Outside scope of this protocol | This protocol does not close GRC violations |
+| Re-grant access post-investigation | HR confirms role legitimacy; Security confirms SoD clearance | Management approval per access matrix | Routes through sap-role-assignment-guarded-operator-agent with all approvals documented |
+
+## Escalation owners
+
+| Scenario | First escalation owner | Second escalation owner |
+|---|---|---|
+| Unmitigated critical SoD conflict involving active employee | GRC / internal audit | Chief Risk Officer |
+| Suspected identity misuse with HR data access | CISO | Chief People Officer |
+| Insider-risk signal with potential fraud impact | Chief Risk Officer | General Counsel |
+| Leavers process gap with post-termination access | HR Operations | CISO |
+| Employment-law or disciplinary dimension | General Counsel | Chief People Officer |
+| Regulatory reporting obligation triggered | Chief Risk Officer + General Counsel jointly | — |
+
+## Irreversible-action gate
+
+The following actions are classified as irreversible or high-consequence and must not proceed without the approvals listed:
+
+- **Account suspension or disablement**: Requires written approval from CISO and VP HR. Approval must be recorded in the audit package before the action is queued to `sap-role-assignment-guarded-operator-agent`.
+- **Role assignment removal in production**: Requires written approval from SAP Security lead and the business process owner of the affected function. If the removal affects payroll or financial-close roles, Finance Controls must also approve.
+- **Permanent account deletion or anonymization**: Requires Legal sign-off confirming no legal-hold obligations attach to the account, plus HR confirmation that the employee lifecycle is fully closed.
+- **Evidence deletion or log purge**: Prohibited during active investigation. Any retention policy execution that would delete relevant logs must be suspended via Legal hold.
+
+This protocol does not execute any irreversible action. It surfaces the required approvals and queues the action to the appropriate guarded-mutating agent once all approvals are documented.
+
+## Approval requirements
+
+All cross-function actions under this protocol require approvals to be documented in writing (ticket, email chain, or signed document) before execution. Verbal approvals are not accepted. The audit package must include the approval record for every action taken.
+
+Minimum approval quorum per action class:
+
+- **Security-only actions** (classification, evidence collection): SAP Security lead sign-off.
+- **HR-touching actions** (leaver processing, role removal for HR data access): SAP Security lead + HR Operations lead.
+- **Legal-dimension actions** (legal hold, disclosure, regulatory reporting): General Counsel or delegate.
+- **Production role mutations**: SAP Security lead + business process owner + (if financial) Finance Controls lead. Executed only via `sap-role-assignment-guarded-operator-agent`.
+
+## Audit package
+
+The audit package for every protocol invocation must contain:
+
+1. **Event summary**: Trigger condition, systems involved, time window, and user identity (anonymized in shared copies per redaction policy).
+2. **Evidence inventory**: List of all artifacts collected (log extracts, GRC reports, role exports, IPS provisioning logs), with source system, collection timestamp, and evidence handler.
+3. **Redaction log**: What was redacted, by whom, and why, for each HR-sensitive document included.
+4. **Decision log**: Each decision taken, who held decision authority, secondary approvals obtained, and timestamp.
+5. **Action log**: Each system action taken (or deferred), the agent that executed it, the approval reference, and the outcome.
+6. **Escalation log**: Each escalation event, who was notified, when, and the response received.
+7. **Legal hold status**: Confirmation of whether a legal hold was placed and which artifacts are in scope.
+8. **Resolution and closure**: Final disposition (access revoked, incident closed, HR action initiated, regulatory report filed), residual risk statement, and any compensating controls put in place.
+
+## Refusal conditions
+
+This protocol and all participating agents must refuse the following requests:
+
+- Executing any role assignment, role removal, account suspension, or account deletion without documented dual approval routed through `sap-role-assignment-guarded-operator-agent`.
+- Sharing unredacted HR data (compensation, performance, disciplinary, health) with Security or operational teams.
+- Closing or approving a GRC access violation — this authority rests with the GRC/audit team only.
+- Disclosing investigation status or findings to the subject of the investigation without explicit HR and Legal authorization.
+- Bypassing the irreversible-action gate on any action listed in that section.
+- Acting on verbal approval alone; written approval is mandatory for all cross-function actions.
+- Initiating any employment action (warning, suspension, termination) — this protocol surfaces risk findings to HR and Legal; employment decisions belong solely to those functions.
+
+## Evidence rules
+
+Label all claims with one of:
+
+- `documentation-based` — grounded in SAP GRC Access Control, SAP SuccessFactors, SAP Identity Authentication, or regulatory guidance (GDPR, SOX, ISO 27001)
+- `user-provided evidence` — access logs, GRC conflict reports, role exports, IPS provisioning logs, HR lifecycle confirmations, or written descriptions provided by the requesting function
+- `inference` — derived reasoning not directly confirmed by official documentation or user-provided evidence; must always be labeled as such
+
+## Response minimum
+
+Every protocol invocation must return, at minimum:
+
+- **Trigger classification**: Which trigger condition(s) apply and which participating agents are activated.
+- **Evidence status**: Which required evidence items are present, which are missing, and which function must supply each missing item.
+- **Redaction confirmation**: Confirmation that HR-sensitive data has been identified and the redaction policy has been applied.
+- **Decision rights mapping**: For each pending decision, who holds primary authority and what secondary approvals are required.
+- **Irreversible-action gate status**: Whether any irreversible actions are pending, what approvals are outstanding, and whether the gate is cleared to proceed.
+- **Audit package status**: Which audit package elements are populated and which are outstanding.
+- **Escalation notice**: If an unmitigated critical SoD conflict or insider-risk signal is present, explicit notice to the escalation owners listed above — this notice must appear before any other recommendation.
+- **Next step**: The single next action the requesting function must take to advance the protocol, with the responsible owner named.

package/skills/sap/sap-security-hr-legal-protocol/agents/openai.yaml

@@ -0,0 +1,11 @@
+interface:
+  display_name: "SAP Security HR Legal Escalation Protocol"
+  short_description: "Cross-functional escalation protocol for SAP Security, HR, and Legal on identity misuse, privileged-access anomalies, SoD violations, insider-risk signals, HR-sensitive access, joiner/mover/leaver lifecycle gaps, and fraud-sensitive access patterns. Defines decision rights, redaction policy, irreversible-action gates, approval requirements, and audit packaging. Never mutates live systems."
+  default_prompt: "Use $sap-security-hr-legal-protocol to coordinate a cross-functional response. Identify which trigger condition applies, map decision rights to each pending action, confirm evidence and redaction status, check whether the irreversible-action gate is cleared, and state the next action with the responsible owner named. Flag any unmitigated critical SoD conflict or insider-risk signal as an immediate escalation before any other recommendation."
+dependencies:
+  tools:
+    - type: "web"
+      value: "https://help.sap.com/docs/sap-grc-access-control/sap-grc-access-control/what-is-sap-grc-access-control"
+      description: "SAP GRC Access Control documentation — primary reference for SoD conflict classification and escalation requirements"
+policy:
+  allow_implicit_invocation: true

package/skills/sap/sap-security-hr-legal-protocol/metadata.json

@@ -0,0 +1,34 @@
+{
+  "id": "sap-security-hr-legal-protocol",
+  "name": "SAP Security HR Legal Escalation Protocol",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Cross-functional escalation protocol for SAP Security, HR, and Legal coordination on identity misuse, privileged-access anomalies, SoD violations, insider-risk signals, HR-sensitive access, joiner/mover/leaver gaps, and fraud-sensitive access patterns. Defines decision rights, redaction policy, irreversible-action gates, approval requirements, and audit packaging. Never mutates live systems.",
+  "source_type": "original",
+  "category": "compliance",
+  "official_docs": [
+    "https://help.sap.com/docs/sap-grc-access-control/sap-grc-access-control/what-is-sap-grc-access-control",
+    "https://help.sap.com/docs/sap-grc-access-control/sap-grc-access-control/emergency-access-management",
+    "https://help.sap.com/docs/successfactors-employee-central/employee-central/data-protection-and-privacy-in-employee-central",
+    "https://help.sap.com/docs/successfactors-platform/successfactors-platform/data-protection-and-privacy",
+    "https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/what-is-identity-authentication",
+    "https://help.sap.com/docs/sap-grc-access-control/sap-grc-access-control/segregation-of-duties",
+    "https://help.sap.com/docs/sap-grc-access-control/sap-grc-access-control/access-risk-analysis",
+    "https://www.iso.org/standard/27001",
+    "https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final"
+  ],
+  "security_notes": "Does not access live SAP systems, GRC Access Control tenants, SuccessFactors instances, or IAM consoles. Accepts only user-provided evidence artifacts. Never accepts or stores HR personal data, compensation records, disciplinary records, or health information. All role mutations must route through sap-role-assignment-guarded-operator-agent with documented dual approval. No guarded-mutating gate is bypassed by this protocol. Verbal approvals are rejected; written approval is mandatory for all cross-function actions.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-security-hr-legal-protocol",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}

package/skills/sap/sap-security-hr-legal-protocol/references/official-sources.md

@@ -0,0 +1,89 @@
+# Official sources — SAP Security HR Legal Escalation Protocol
+
+Use this reference when grounding SoD conflict classification, HR data sensitivity assessment, identity lifecycle governance, GRC emergency access review, and regulatory compliance framing for cross-functional escalations.
+
+**Evidence level**: documentation-based (SAP Help Portal, SAP GRC Access Control documentation, SAP SuccessFactors data protection guidance, NIST SP 800-53, ISO 27001). No live-system evidence is collected by this skill.
+
+## SAP GRC Access Control
+
+- What is SAP GRC Access Control
+  https://help.sap.com/docs/sap-grc-access-control/sap-grc-access-control/what-is-sap-grc-access-control
+  source_owner: SAP SE
+  topic_supported: GRC Access Control capabilities, Access Risk Analysis, Emergency Access Management, Business Role Management, User Access Review
+  why_needed: Primary reference for SoD conflict classification and escalation requirements used throughout this protocol
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Segregation of Duties
+  https://help.sap.com/docs/sap-grc-access-control/sap-grc-access-control/segregation-of-duties
+  source_owner: SAP SE
+  topic_supported: SoD ruleset structure, risk classification levels (critical/high/medium/low), mitigation control assignment
+  why_needed: Defines the SoD conflict risk taxonomy applied when classifying fraud-sensitive access patterns in this protocol
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Access Risk Analysis
+  https://help.sap.com/docs/sap-grc-access-control/sap-grc-access-control/access-risk-analysis
+  source_owner: SAP SE
+  topic_supported: ARA execution model, risk simulation, batch risk analysis, remediation workflow
+  why_needed: Required to understand how GRC generates the SoD conflict reports that serve as evidence in this protocol
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Emergency Access Management
+  https://help.sap.com/docs/sap-grc-access-control/sap-grc-access-control/emergency-access-management
+  source_owner: SAP SE
+  topic_supported: Firefighter ID assignment, session logging, log review workflow, EAM owner and controller roles
+  why_needed: Required to assess privileged-access anomalies for firefighter users — defines logging obligations and log review requirements referenced in this protocol
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP SuccessFactors — HR Data Protection
+
+- Data Protection and Privacy in Employee Central
+  https://help.sap.com/docs/successfactors-employee-central/employee-central/data-protection-and-privacy-in-employee-central
+  source_owner: SAP SE
+  topic_supported: HR data sensitivity classifications, personal data categories in SuccessFactors Employee Central, data subject rights, purpose limitation
+  why_needed: Primary reference for HR data sensitivity assessment and redaction policy — defines which SuccessFactors data elements are personal or sensitive personal data
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Data Protection and Privacy in SAP SuccessFactors
+  https://help.sap.com/docs/successfactors-platform/successfactors-platform/data-protection-and-privacy
+  source_owner: SAP SE
+  topic_supported: SuccessFactors platform-level data protection, consent management, data purge, audit logging
+  why_needed: Platform-level data protection obligations that govern how HR evidence may be collected, shared, and retained under this protocol
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Cloud Identity Services
+
+- What is Identity Authentication
+  https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/what-is-identity-authentication
+  source_owner: SAP SE
+  topic_supported: IAS application model, corporate IdP federation, MFA enforcement, risk-based authentication
+  why_needed: Required to assess identity-layer evidence when evaluating account compromise or access anomaly trigger conditions
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Risk and Control Frameworks
+
+- NIST Special Publication 800-53 Rev 5 — Security and Privacy Controls for Information Systems and Organizations
+  https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
+  source_owner: NIST
+  topic_supported: AC (Access Control), AU (Audit and Accountability), IR (Incident Response), PS (Personnel Security) control families; insider threat program guidance
+  why_needed: Secondary framework reference for insider-risk escalation framing and audit package requirements; NIST AC-5 (Separation of Duties) and PS-4 (Personnel Termination) directly support the leaver and SoD escalation paths in this protocol
+  evidence_level: secondary
+  last_verified: 2026-06-19
+
+- ISO/IEC 27001 — Information Security Management Systems
+  https://www.iso.org/standard/27001
+  source_owner: ISO/IEC
+  topic_supported: Annex A controls for access management, HR security, incident management, and compliance; risk treatment requirements
+  why_needed: Secondary framework providing the ISO 27001 Annex A context for the access control and HR security obligations cited in this protocol's escalation and decision-rights tables
+  evidence_level: secondary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP Help Portal documentation describes the designed capabilities and configuration models for GRC Access Control, SuccessFactors, and Cloud Identity Services. It does not prove which conflicts exist in the user's GRC system, what HR data was accessed, or which lifecycle events were missed. Users must supply GRC conflict reports, access logs, role exports, IPS provisioning logs, and HR-provided lifecycle confirmations for concrete protocol execution.

package/skills/sap/sap-security-hr-legal-protocol/references/safety-checklist.md

@@ -0,0 +1,38 @@
+# Safety checklist — SAP Security HR Legal Escalation Protocol
+
+Use before any cross-function handoff, before any action is queued to a guarded-mutating agent, and before any evidence is shared outside its originating function.
+
+## Non-negotiables
+
+- Do not execute any role assignment, role removal, account suspension, or account deletion without documented dual approval. All role mutations must be queued to `sap-role-assignment-guarded-operator-agent` with approval documentation attached.
+- Do not share unredacted HR data (compensation, performance ratings, disciplinary records, health information, succession data) with Security, operational teams, or any party outside HR without Legal authorization and documented legal-hold or employment-law basis.
+- Do not close, approve, or recommend closing a GRC access violation. GRC violation closure authority rests with the GRC/audit team only.
+- Do not disclose investigation status or findings to the subject of the investigation without explicit joint authorization from HR and Legal.
+- Do not accept verbal approval for any cross-function action. Written approval (ticket, email chain, or signed document) is mandatory.
+- Do not initiate or recommend any employment action (warning, suspension, termination). This protocol surfaces risk findings to HR and Legal; employment decisions are theirs alone.
+- Do not delete or purge evidence logs during an active investigation. Retention policy execution that would destroy relevant logs must be suspended via Legal hold.
+- Do not bypass the irreversible-action gate. Any action listed under that section requires all listed approvals before the action is queued.
+
+## What people get wrong
+
+- **Treating SoD conflict classification as an employment finding**: An SoD conflict report establishes access risk, not misconduct. The HR and Legal functions determine whether any employment action is warranted based on the full investigation. Security's role is to surface the access evidence, not to draw conclusions about intent.
+- **Sharing the full GRC conflict report with HR without redaction review**: GRC reports often contain transaction codes and system access details that, when combined with HR records, could be used to infer sensitive information about other employees or investigations. Review for cross-contamination before sharing.
+- **Assuming a leaver's access lapse is always a Security issue**: JML gaps are often process failures in the HR lifecycle workflow or IPS provisioning chain. Assign root-cause investigation to the correct function before escalating as a security incident.
+- **Skipping the legal-hold decision for post-termination access**: If a departed employee's account was used after the effective termination date, there may be an obligation to preserve logs for employment-law or regulatory purposes before any retention policy purge occurs.
+- **Treating EAM log review as equivalent to access approval**: The existence of an EAM firefighter log does not mean the access was authorized or within scope. Log review must be completed by the designated EAM owner and controller before the access event is considered governed.
+- **Conflating HR-sensitive system access with a personal data breach**: Access to SuccessFactors compensation or performance data by an unauthorized user is a policy violation and potential access control failure. Whether it constitutes a reportable personal data breach under GDPR or equivalent regulation is a Legal determination, not a Security one.
+
+## When to push back
+
+- Push back (and escalate immediately) when an unmitigated critical SoD conflict involving an active employee is found — escalate to GRC/audit and flag the escalation owners before any other action.
+- Push back when any function requests unredacted HR data without Legal authorization — provide a redacted summary instead and require Legal sign-off for full disclosure.
+- Push back when asked to confirm employment status, role legitimacy, or lifecycle event completion from memory — require HR-system-of-record confirmation.
+- Push back when asked to queue a role mutation without all required written approvals in hand.
+- Push back when asked to close a GRC violation — refer to the GRC/audit team.
+- Push back when asked to recommend or initiate an employment action — refer to HR and Legal.
+
+## Evidence labels
+
+- `documentation-based` — grounded in SAP GRC Access Control, SAP SuccessFactors, SAP Cloud Identity Services, NIST SP 800-53, or ISO 27001 documentation
+- `user-provided evidence` — access logs, GRC conflict reports, role exports, IPS provisioning logs, HR lifecycle confirmations, or written descriptions provided by the requesting function
+- `inference` — derived reasoning not directly confirmed by official documentation or user-provided evidence; must always be labeled as such and must not be used as the sole basis for any cross-function action

package/skills/sap/sap-security-hr-legal-protocol/references/workflow-and-output.md

@@ -0,0 +1,65 @@
+# Workflow and output contract — SAP Security HR Legal Escalation Protocol
+
+Use this reference for all trigger classification, evidence assembly, cross-function handoff sequencing, decision rights application, and output formatting.
+
+## Trigger classification table
+
+| Trigger class | Primary signal | Activating agent | HR involvement | Legal involvement |
+|---|---|---|---|---|
+| `identity-misuse` | Anomalous access pattern, bulk extraction, unexpected location | sap-security-iam-grc-sod-reviewer-agent | Required for employment-status confirmation | Required if criminal or employment action may follow |
+| `privileged-access-anomaly` | Firefighter/EAM access outside approved scope; SAP\_ALL outside change window | sap-security-iam-grc-sod-reviewer-agent | Optional (required if HR data was accessed) | Optional (required if disciplinary action follows) |
+| `critical-sod-violation` | Unmitigated critical SoD conflict involving active employee | sap-security-iam-grc-sod-reviewer-agent | Required (employment status + role confirmation) | Required (regulatory and employment-law review) |
+| `insider-risk` | DLP or SIEM exfiltration indicator against HR, payroll, or financial data | sap-security-iam-grc-sod-reviewer-agent + sap-successfactors-hr-process-risk-agent | Required (data sensitivity classification) | Required (legal hold decision) |
+| `hr-sensitive-access` | Access to SuccessFactors compensation, performance, or succession data outside authorized scope | sap-successfactors-hr-process-risk-agent | Required (owns data sensitivity classification) | Conditional (if personal data breach threshold met) |
+| `jml-gap` | Post-termination access; mover retaining previous role; joiner access beyond matrix | sap-successfactors-hr-process-risk-agent | Required (lifecycle event confirmation) | Conditional (if post-termination access was used) |
+| `fraud-sensitive-access` | Single-user execution of incompatible financial transactions | sap-security-iam-grc-sod-reviewer-agent | Required (employment context) | Required (potential fraud investigation) |
+
+## Protocol workflow
+
+### Phase 1 — Triage (SAP Security lead)
+
+1. Classify the trigger condition using the table above.
+2. Identify which participating agents are activated.
+3. Confirm which evidence items are available and which are outstanding.
+4. Issue evidence assembly requests to the responsible function for each missing item.
+5. Apply the redaction policy before any cross-function share.
+
+### Phase 2 — Evidence assembly (multi-function)
+
+1. `sap-security-iam-grc-sod-reviewer-agent` assembles identity evidence, access logs, GRC conflict reports, and role assignment state.
+2. `sap-successfactors-hr-process-risk-agent` assembles HR lifecycle state and provides redacted summary to Security per redaction policy.
+3. Legal is notified if trigger classification indicates a legal dimension; Legal confirms whether a legal hold is required.
+
+### Phase 3 — Cross-function review
+
+1. All functions review assembled evidence within their domain authority.
+2. `sap-security-iam-grc-sod-reviewer-agent` classifies SoD conflicts by risk level.
+3. `sap-successfactors-hr-process-risk-agent` classifies HR data sensitivity and confirms whether HR lifecycle events were processed correctly.
+4. Decision rights table is applied — each pending decision is assigned to the correct authority.
+
+### Phase 4 — Action proposal
+
+1. Proposed actions are documented with the required approvals per the approval requirements section of the SKILL.md.
+2. Irreversible-action gate is evaluated for each proposed action.
+3. Actions requiring `sap-role-assignment-guarded-operator-agent` are queued with approval documentation attached — the operator agent does not execute without confirmed approvals.
+
+### Phase 5 — Audit package assembly
+
+1. All evidence, decision records, approval records, redaction logs, and action outcomes are consolidated into the audit package.
+2. Audit package is made available to internal audit and, where required by legal hold, to Legal.
+3. Residual risk is assessed and documented.
+
+## Output contract
+
+Return, in order:
+
+1. **Trigger classification**: Which trigger class(es) apply; which participating agents are activated.
+2. **Evidence inventory**: Present items, missing items, and responsible function for each missing item.
+3. **Redaction confirmation**: Explicit statement that HR-sensitive data has been identified and the redaction policy status (applied / pending / not applicable).
+4. **Decision rights map**: For each pending decision, primary authority, secondary approvals required, and current status (pending / approved / deferred).
+5. **Irreversible-action gate**: Whether any irreversible actions are pending; approval status for each; whether gate is cleared or blocked.
+6. **SoD conflict summary** (if applicable): Conflict ID or description, risk level, mitigation status, and escalation notice if unmitigated critical.
+7. **HR data sensitivity assessment** (if applicable): Data categories accessed or at risk; classification; redaction applied.
+8. **Escalation notice**: If an unmitigated critical SoD conflict, insider-risk signal, or legal-hold trigger is present, explicit notice must appear before any other recommendation, naming the escalation owners and required action.
+9. **Audit package status**: Populated items and outstanding items.
+10. **Next step**: Single next action with named responsible owner.

package/skills/sap/sap-security-iam-grc-sod-review/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: sap-security-iam-grc-sod-review
+description: Review SAP identity and access management posture: Cloud Identity Services (IAS/IPS), Authorization and Trust Management (XSUAA), role collections, GRC Access Control, and Segregation of Duties. Flags SoD conflicts, excessive privilege, orphaned accounts, and trust misconfigurations. Does not touch live systems.
+allowed-tools: Read Grep Glob WebSearch WebFetch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-19"
+  category: security
+  lifecycle: experimental
+---
+
+# SAP Security IAM GRC and SoD Review
+
+## Purpose
+
+Assess the identity and access management posture of SAP landscapes spanning cloud and on-premise systems. Review SAP Identity Authentication Service (IAS) and Identity Provisioning Service (IPS) configuration for provisioning correctness, group mapping, and lifecycle management. Review Authorization and Trust Management (XSUAA) scopes, role templates, and role collection assignments for privilege excess and least-privilege compliance. Assess GRC Access Control ruleset quality, SoD conflict classification, and mitigation control effectiveness. Flag SoD conflicts, excessive or accumulated privilege, orphaned accounts, misconfigured identity provider trust, and access lifecycle gaps. Does not connect to or mutate any live SAP system.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review SAP Identity Authentication Service (IAS) configuration for application assignments, corporate identity provider federation, risk-based authentication policies, and MFA enforcement,
+- assess SAP Identity Provisioning Service (IPS) connector configuration for user and group synchronization correctness, provisioning rule quality, and transformation script safety,
+- evaluate XSUAA (Authorization and Trust Management Service) application security descriptor (xs-security.json) design: scope definitions, role template construction, role collection granularity, and least-privilege compliance,
+- audit role collection assignments for a BTP subaccount — identifying over-permissive built-in role collections, direct user assignments versus IdP group mappings, and privilege accumulation across multiple role collections,
+- review SAP GRC Access Control ruleset configuration: SoD function and permission entries, risk classification (critical/high/medium/low), and whether the ruleset covers key business processes (FI, MM, SD, HR),
+- assess SoD conflict findings from GRC Access Control, SAP Access Violation Management by Pathlock, or equivalent tooling — classify conflicts, evaluate mitigating controls, and flag unmitigated critical conflicts,
+- identify excessive privilege patterns: access to incompatible transaction pairs, accumulated authorizations from multiple roles, or overly broad authorization object values (e.g., `*` for company code or plant),
+- review identity trust misconfigurations: IAS corporate IdP federation without MFA enforcement, XSUAA trust to external IdPs with insufficient attribute mapping, or IPS provisioning to production systems without approval workflows.
+
+## When not to use
+
+- When the user needs live inspection of a GRC Access Control system, BTP XSUAA tenant, or IAS admin console — this skill accepts only user-provided configuration exports, SoD conflict reports, role lists, or written descriptions.
+- When the request is about BTP account-level structural governance (entitlements, directories, environments) rather than IAM — use `sap-btp-governance-review`.
+- When the request is about ABAP authorization objects directly in an on-premise SAP system without a GRC or cloud IAM layer — this skill focuses on cloud IAM (IAS/IPS/XSUAA) and GRC; direct ABAP auth object review is out of scope.
+- When the request is about integration security (iFlow OAuth, API proxy policies) — use `sap-integration-suite-review`.
+
+## Does not touch live systems
+
+This skill operates on user-provided configuration exports, SoD conflict reports from GRC or equivalent tools, xs-security.json files, role collection exports, IAS application exports, IPS connector configuration descriptions, or written descriptions of the IAM landscape. It does not connect to any IAS tenant, IPS admin console, XSUAA service instance, GRC system, BTP subaccount, or on-premise SAP system. All live inspection is out of scope.
+
+## Lean operating rules
+
+- Classify IAM findings by domain before recommending. Every finding must be assigned to a domain (IAS / IPS / XSUAA / GRC / SoD) before a remediation path is proposed.
+- Least privilege is the baseline. Any role, scope, or role collection that grants access beyond what the business function requires is a finding. Broad authorization object values (`*` for organizational levels) are always flagged.
+- SoD conflicts must be classified by risk level. Not all SoD conflicts carry the same risk. Critical SoD conflicts (e.g., Create Vendor + Approve Payment, Create PO + Approve PO) must be treated as `critical` findings requiring either role redesign or compensating controls with documented approval.
+- Unmitigated critical SoD conflicts block sign-off. An environment with unmitigated critical SoD conflicts (no approved compensating control on record) is not compliant with SOX, ISO 27001, or SAP GRC best practices. Escalate before proceeding.
+- IPS provisioning to production requires approval workflow. Any IPS connector that provisions users or group memberships to a production target system without an approval step in the provisioning flow is a `high` finding.
+- IAS MFA enforcement is required for privileged users. Administrator and privileged application users authenticated via IAS without MFA enforcement (risk-based authentication minimum) are a `high` finding.
+- XSUAA trust to external IdPs must carry attribute validation. XSUAA application trust configured to accept tokens from an external IdP without validating custom attributes (e.g., groups, costCenter) is a privilege escalation vector.
+- Orphaned accounts are a `high` finding. Accounts in IAS, IPS target systems, or BTP role collection assignments that belong to users who have left the organization or changed roles are `high` IAM lifecycle findings.
+- Evidence from user-provided artifacts or official SAP security documentation takes precedence over inference.
+- Load only the reference needed for the IAM domain under review.
+
+## Evidence rules
+
+Label all claims with one of:
+
+- `documentation-based` — grounded in SAP IAS, IPS, XSUAA, GRC Access Control, or SAP security best practice documentation
+- `user-provided evidence` — SoD conflict reports, role lists, xs-security.json files, IAS exports, IPS connector configurations, or written descriptions provided by the user
+- `inference` — derived reasoning not directly confirmed by official docs or user evidence
+
+## Live-environment rules
+
+**This skill does not touch live systems.** There is no IAS API call, IPS REST API invocation, XSUAA service binding access, GRC system RFC call, BTP cockpit session, or on-premise SAP system connection in this skill's execution path. Users must supply configuration exports, SoD conflict reports, role collection lists, or written descriptions of their IAM landscape for this skill to review.
+
+## References
+
+Load only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — IAM finding taxonomy, SoD conflict classification, severity assignment, output format.
+- [Safety checklist](references/safety-checklist.md) — non-negotiables, common IAM review mistakes, when to push back.
+- [Official sources](references/official-sources.md) — SAP IAS, IPS, XSUAA, GRC Access Control, and SoD documentation.
+
+## Response minimum
+
+Return, at minimum:
+
+- **Problem classification**: IAM domain(s) affected (IAS / IPS / XSUAA / GRC / SoD) and specific finding(s) per domain.
+- **Evidence used**: documentation-based / user-provided evidence / inference.
+- **Risk level**: critical (SoD conflict, privilege escalation path, unmitigated access violation) / high (excessive privilege, orphaned account, missing MFA, unapproved provisioning) / medium (governance gap, missing lifecycle review, weak attribute mapping) / low (best practice deviation).
+- **Recommended action**: specific remediation per finding (role redesign, compensating control documentation, IPS approval workflow addition, IAS MFA policy enforcement, XSUAA scope reduction, etc.).
+- **Refusal / escalation triggers**: if unmitigated critical SoD conflicts are found, escalate to GRC / audit team before any further access approval or system change is authorized.
+- **Business impact**: compliance risk (SOX, ISO 27001, internal audit), fraud risk, data breach risk, or access lifecycle debt.
+- **Next verification step**: validate remediation recommendations against current role assignments and GRC ruleset before implementing access changes.

package/skills/sap/sap-security-iam-grc-sod-review/agents/openai.yaml

@@ -0,0 +1,11 @@
+interface:
+  display_name: "SAP Security IAM GRC and SoD Review"
+  short_description: "Review SAP identity and access management posture: IAS/IPS configuration, XSUAA scopes and role collections, GRC Access Control ruleset quality, and Segregation of Duties conflict classification. Flags SoD conflicts, excessive privilege, orphaned accounts, and trust misconfigurations."
+  default_prompt: "Use $sap-security-iam-grc-sod-review to assess the provided SAP IAM and GRC configuration. Classify each finding by IAM domain (IAS, IPS, XSUAA, GRC, SoD), assign a risk level (critical/high/medium/low), and recommend specific remediation actions. Flag any unmitigated critical SoD conflicts for immediate escalation. State evidence level (documentation-based, user-provided, inference) and whether live system access is required to complete the review."
+dependencies:
+  tools:
+    - type: "web"
+      value: "https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/what-is-identity-authentication"
+      description: "SAP Cloud Identity Services documentation — primary reference for IAS and IPS configuration review"
+policy:
+  allow_implicit_invocation: true

package/skills/sap/sap-security-iam-grc-sod-review/metadata.json

@@ -0,0 +1,33 @@
+{
+  "id": "sap-security-iam-grc-sod-review",
+  "name": "SAP Security IAM GRC and SoD Review",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review SAP identity and access management posture: Cloud Identity Services (IAS/IPS), Authorization and Trust Management (XSUAA), role collections, GRC Access Control, and Segregation of Duties. Flags SoD conflicts, excessive privilege, orphaned accounts, and trust misconfigurations. Does not access live systems.",
+  "source_type": "original",
+  "category": "security",
+  "official_docs": [
+    "https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/what-is-identity-authentication",
+    "https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/what-is-identity-provisioning",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/what-is-authorization-and-trust-management-service",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/application-security-descriptor-configuration-syntax",
+    "https://help.sap.com/docs/sap-grc-access-control/sap-grc-access-control/what-is-sap-grc-access-control",
+    "https://help.sap.com/docs/sap-grc-access-control/sap-grc-access-control/segregation-of-duties",
+    "https://help.sap.com/docs/cloud-identity-services/cloud-identity-services/configure-risk-based-authentication-for-application",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/trust-and-federation-with-identity-providers"
+  ],
+  "security_notes": "Does not access live SAP IAS tenants, IPS admin consoles, XSUAA service instances, GRC Access Control systems, or BTP subaccounts. Accepts only user-provided SoD conflict reports, role lists, xs-security.json files, IAS exports, IPS connector descriptions, or written IAM landscape descriptions. Never request or accept IAS admin credentials, IPS technical user passwords, XSUAA client secrets, GRC system logon credentials, or BTP service keys. Unmitigated critical SoD conflicts must be escalated to the GRC or audit team — this skill does not approve or close access violations.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-security-iam-grc-sod-review",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}